Nigerian freelancers receive international payments through platform payouts, foreign-currency receiving accounts, bank transfers, domiciliary accounts, payment providers, or stablecoins. Which one works depends on the client's country, currency, transfer rail, and payer type — not just on what currency your account holds. This matters more here than in most markets: PayPal's Nigerian personal accounts have been send-only since 2014, and Wise suspended USD transfers into Nigeria in November 2022. A US, UK, and EU client should not be given the same bank details by default.
Key takeaways
US clients typically pay via USD account details using ACH or wire.
UK clients may use Faster Payments, Bacs, or CHAPS.
EU clients typically use SEPA transfers to an eligible IBAN.
The account must support the specific incoming rail, not just the currency.
The beneficiary name and invoice reference must match what the receiving account expects.
A stablecoin payment needs its own instructions: token, network, address, and transaction record.
Which route fits which client?
Client location | Common currency | Possible rail | Client will likely need | Main failure point |
United States | USD | ACH, FedNow (where explicitly supported), domestic or international wire | Account holder name, routing number, account number, account type | Wrong routing method, unsupported payer type, name mismatch |
United Kingdom | GBP | Faster Payments, Bacs, CHAPS, international transfer | Account name, sort code, account number, reference | Selected method not accepted by the receiving account |
EU / SEPA area | EUR | SEPA Credit Transfer, SEPA Instant (where supported), SWIFT | Beneficiary name, IBAN, BIC if requested, reference | Non-SEPA account, wrong currency, name mismatch |
Any region | USD, GBP, EUR | SWIFT | Beneficiary and receiving-bank details, SWIFT/BIC | Intermediary fees, longer chain |
Any region, crypto-ready payer | USDT, USDC | Blockchain transfer | Token, network, wallet address | Wrong network, unsupported token, no transaction record |
These are categories, not guarantees. The provider issuing your receiving details decides which currencies, rails, countries, and payer types it actually accepts — the table tells you what to ask for, not what you're entitled to.
The PayPal, Payoneer, Wise, and stablecoins for freelancers guide compares providers broadly. This one covers what to actually send to clients.
Receiving from a US client
US finance teams prefer a route that behaves like a domestic payment: ACH, a domestic wire, or whatever rail your account explicitly supports. An ACH credit is a push payment — the client's bank sends the funds — but your provider still has to support incoming ACH credits and the client's payer type. A working routing number doesn't guarantee every ACH transfer clears. (Federal Reserve)
Details a US client may need: exact beneficiary or account-holder name, routing number, account number, account type if requested, receiving-bank name and address if required, invoice number, payment purpose, and wire instructions if ACH isn't supported.
ACH fits routine payments when the client can pay through their own online banking or payroll, the amount is within your provider's limits, and the invoice timeline allows for standard settlement. If your provider specifies wire-only details, don't offer ACH instructions instead.
FedNow is an instant rail available only where both institutions participate. Don't ask a client to use it just because your account has a US routing number — confirm your provider explicitly supports incoming FedNow payments first.
Domestic wire can suit larger or time-sensitive payments, but check whether your account accepts wires at all, whether the wire routing number differs from the ACH one, and who absorbs the wire fee.
International wire is the fallback when a client can't use a local US route. Expect correspondent banks, extra fields, and deductions before the money lands.
Example instruction:
Payment currency: USD
Payment method: ACH credit
Beneficiary name: [Exact account name]
Routing number: [Number]
Account number: [Number]
Account type: [Checking, if specified]
Reference: INV-2026-048
Amount: USD 2,000
Fee instruction: Sender covers bank charges
Important: Do not send by wire unless separate wire instructions are provided
Receiving from a UK client
A UK client may prefer GBP details supporting Faster Payments, Bacs, or CHAPS. Faster Payments usually settles almost immediately when both institutions participate directly, though Pay.UK notes some payments can take up to two hours or longer. Actual speed still depends on the provider issuing your account. (Pay.UK)
Details a UK client may need: account-holder name, sort code, account number, payment reference, invoice number, and confirmation the account accepts third-party business payments.
Faster Payments suits one-off invoices and recurring transfers — confirm your sort code and account product are eligible before assuming coverage.
Bacs is common for payroll and batch payments but runs on a longer processing cycle. A client running contractor payments through payroll may default to it; your account needs to support Bacs credits specifically.
CHAPS typically handles high-value or time-sensitive UK payments, usually at a higher fee. Use it only when your provider supplies CHAPS-compatible details.
Example instruction:
Payment currency: GBP
Payment method: Faster Payments
Account name: [Exact account name]
Sort code: [XX-XX-XX]
Account number: [Number]
Reference: INV-2026-049
Amount: GBP 1,500
Important: Use Faster Payments only. Do not convert to USD before sending.
If the client offers an international transfer instead, compare conversion and intermediary costs first — a GBP payment converted twice can end up worse than a direct USD route.
Receiving from an EU client
An EU client paying in euros will usually expect an IBAN on a SEPA-compatible route. The ECB defines an instant SEPA credit transfer as one available in the payee's account within ten seconds — but only when both the payer's and payee's providers support the instant scheme. (European Central Bank)
Details an EU client may need: exact beneficiary name, IBAN, BIC if requested, beneficiary address if required, bank name, euro amount, and invoice reference.
SEPA Credit Transfer is the standard route — but an IBAN-shaped account number doesn't confirm eligibility. It doesn't tell you whether the account accepts third-party business payments, whether it accepts your client's country or the invoice amount, whether it's active for incoming SEPA transfers, or whether minor variations between your legal name and the beneficiary name will be rejected.
SEPA Instant can settle in seconds, but don't promise that speed to a client unless your provider explicitly confirms it for your account status.
SWIFT from Europe applies when the receiving account sits outside SEPA, the currency isn't EUR, or the client's bank can't route locally. Expect intermediary fees and a longer chain — ask if a local euro route exists before defaulting to SWIFT.
Example instruction:
Payment currency: EUR
Payment method: SEPA Credit Transfer
Beneficiary name: [Exact account name]
IBAN: [IBAN]
BIC: [If required]
Reference: INV-2026-050
Amount: EUR 1,800
Fee instruction: Sender selects the option that delivers the agreed invoice amount
Important: Send EUR only. Do not use a non-SEPA wire without confirmation.
Where IBAN-style accounts fit
An IBAN can simplify the conversation with a client who already thinks in bank transfers. The walllet.com IBAN Account provides eligible users with IBAN-formatted receiving details for supported incoming payments — the exact currencies, rails, countries, fees, limits, and review rules depend on what's currently shown on the account, so check the IBAN Account guide before quoting details to a client.
This matters for a specific reason: an IBAN feature and a self-custodial crypto wallet are different financial layers with different risk profiles. Self-custody is about who holds the signing keys for a crypto asset. A bank-transfer receiving feature is about a provider, its account structure, its review rules, and its withdrawal terms. Treating every balance inside one app as equally "self-custodial" hides which parts of your money are under your direct control and which depend on a provider's operational status.
See current walllet.com availability →
When to route through a platform instead
A platform payout makes sense when the work originated there or the platform requires payment to stay inside its system. It gives you contract records, escrow or milestone handling, invoicing, dispute procedures, and integrated withdrawal — at the cost of platform fees, payout fees, withdrawal restrictions, and possible account review.
Don't move a client off-platform just to save a percentage point on fees without checking the platform's terms first — an account suspension costs more than the fee you were trying to avoid.
When a client should pay in USDT or USDC
Use a stablecoin route when the client already holds the asset, the payment is allowed under their contract and internal policy, you control a wallet supporting that exact asset and network, and the client can send a small test payment first. Skip it if their finance team prohibits crypto, they've never sent an on-chain payment, you're unsure of the network, or you need something reversible.
The stablecoin payment checklist covers what to confirm before the first transfer. Verify the exact network using the supported chains guide before sharing an address.
Example instruction:
Asset: USDC
Network: Base
Wallet address: [Address]
Invoice reference: INV-2026-051
Test payment: 5 USDC
Remaining amount: Send only after test confirmation
Network fee: Paid by sender
Proof: Transaction hash required
What to actually send a client
One complete instruction block attached to the invoice — not a fragmented email thread.
Invoice: INV-2026-052
Amount: [Currency and amount]
Due date: [Date]
Beneficiary name: [Exact verified name]
Payment currency: [USD / GBP / EUR]
Payment rail: [ACH / Faster Payments / SEPA / wire]
Account details: [Exact provider-generated details]
Reference: INV-2026-052
Fee instruction: [Sender covers fees / shared / agreed arrangement]
Unsupported methods: [List if required]
Payment contact: [Email]
The reference ties the invoice to the payment notification, your account statement, and any support case you might need to open later. "Consulting" as a reference is unreconcilable months later; "INV-2026-052" isn't.
The beneficiary name matters because providers often check it against your verified identity. A brand nickname instead of your legal name can trigger a return or a review — use the account name exactly as issued.
Comparing routes before you commit
Criterion | Question |
Client effort | Can they pay through normal company banking? |
Eligibility | Is the account active for your country, payer type, and transaction purpose? |
Currency | Does the route receive the invoice currency without forced conversion? |
Total cost | What's left after receiving, conversion, and withdrawal fees? |
Timing | When does the payment typically clear, and what can delay it? |
Review risk | What documents might be requested? |
Proof | What reference or transaction hash confirms payment? |
Support | Who owns the case if the money is returned or held? |
After receipt | Can you hold, convert, spend, or withdraw as needed? |
Fallback | What can the client use if this route fails? |
What to keep on file
For each recurring client, keep the contract or scope, the invoice, the client's legal name and billing address, the agreed currency and fee terms, proof the client initiated payment, the payment reference, the resulting statement or transaction record, and any support correspondence. These records are what a provider will ask for if it questions the source or purpose of funds — without them, a payment, an invoice, and a bank line item can all exist without anyone being able to connect them.
If a payment is delayed or returned
First, confirm the client used the correct instruction — currency, rail, beneficiary name, account number or IBAN, routing details, and reference.
Then get verifiable proof. For a bank payment: transfer confirmation, reference, date, amount, sending institution, and trace number if available. For a stablecoin payment: the transaction hash, checked against the block explorer guide.
Check the actual status. Pending, under review, rejected, returned, and confirmed-on-chain are different states with different next steps — don't treat them interchangeably.
Open one support case, not several. Give it the account identifier, invoice, payer name, amount, date, reference, and proof document in one submission — splitting the same issue across multiple tickets slows resolution rather than speeding it up.
Update the client with what's confirmed, what's still unknown, who's checking it, and when you'll follow up — before assuming they failed to pay.
The freelance payments held, reviewed, or delayed guide covers why this happens more often than it should.
The workflow for a new client
Identify the client's legal entity and country.
Confirm the invoice currency.
Ask which rails their finance team can actually use.
Match that against your available receiving options.
Compare final usable money, timing, and documentation — not just the advertised fee.
Test the route with a small amount first.
Send one complete instruction block.
Keep the invoice, reference, and proof of payment.
Review the route after the first payment clears.
Keep a second verified option in reserve.
Use walllet.com when an eligible receiving route or stablecoin workflow fits the client, and confirm the currency, rail, fees, limits, and review rules currently shown on the account before making it part of your recurring income:
