Best App to Receive International Payments as a Freelancer

The distinction matters because the two paths cost very different amounts for the same invoice, and the difference is not in the visible fee. It is in who controls the currency conversion — and in the default path, the answer is a bank with no reason to give you a good rate and no obligation to show you the one it used.

The path of least resistance is to put your normal bank details on an invoice and let the client work it out. Here is what actually happens when a client in another country does that.

1. Their bank sends an international wire, usually over the SWIFT network, and charges them a fee.
2. One or more correspondent banks may handle it in between, each able to deduct a charge from the payment itself. This is why the amount arriving is sometimes less than the amount invoiced, with nothing to explain the gap.
3. Your bank receives a payment in a currency you do not hold, converts it into yours at its own rate, and may charge an inbound fee on top.

Two of those three steps are outside your control and none of them are itemised in a way you can audit. Worse, the conversion — the biggest cost in most cases — is done by the party with the least incentive to do it well. The fee your client sees is not the cost; the rate you get is.

You can see the scale of a conversion margin for yourself with our FX markup checker, which shows the gap between a given rate and the mid-market reference rate.

The middle route is the one worth setting up, and it has a second-order benefit: your client's payment becomes a domestic transfer, which is faster, cheaper for them, and far less likely to fail on a formatting error. Making it easy for a client to pay you is not a small thing when you want to be paid again.

Four things decide whether an account is any good for this, and only one of them is the advertised fee.

• Which currencies you get real local details in. "Supports 40 currencies" usually means it can hold 40. The number that matters is how many you can be paid into locally — typically a much shorter list, and it needs to include your clients' currencies.
• The conversion margin. This is where the money goes. Compare the rate offered against the mid-market rate, not against another provider's advertised rate.
• Whether you can hold the balance. Being force-converted on arrival removes your only real lever: choosing when to convert. It also stops you paying costs in that currency without converting twice.
• Getting it out. A good rate is worth less if withdrawing to your own bank costs a flat fee each time you do it.

Of the business providers we cover, the local-receiving picture differs a lot:

• Wise Business — holds 40+ currencies, with local details in up to nine or ten of them.
• Airwallex — up to ten "Global Accounts", with USD, EUR and GBP available quickly.
• OFX — a Global Business Account across 30+ currencies with local receiving.
• XE Money Transfer — send and receive across 130+ currencies and 190+ countries.
• Mercury — USD-based, pays out in 40+ currencies but is not built for holding foreign balances.
• Currencies Direct — receiving accounts in the major currencies, transfer-led rather than account-led.

The full capability matrix, including what each does for invoicing and payables, is on our business transfers comparison.

Where local receiving actually works — and where it does not

The whole strategy on this page depends on one thing: whether you can get local account details in your client's currency. That is not available everywhere, and the gap is the single most important eligibility check before you restructure how you invoice. Taking Wise as the widest example, it publishes the currencies you can be paid into locally versus the ones it can only send to (Wise help centre, checked September 2026):

• You can receive locally in: AUD, BRL, CAD, CHF, CZK, DKK, EUR, GBP, HKD, HUF, IDR, ILS, INR, JPY, MXN, MYR, NOK, NZD, PHP, PLN, RON, SEK, SGD, THB, TRY, UAH and USD. If your client pays in one of these, they can pay domestically and the conversion stays under your control.
• Send-only — no local receiving details: AED, ARS, BDT, CLP, CNY, COP, CRC, EGP, GEL, GHS, KES, KRW, LKR, MAD, NGN, NPR, PKR, TZS, UGX, UYU, VND and ZAR.

That second list is the one that matters, and it is where most of the advice written on this subject quietly stops applying. If you are a freelancer in Nigeria, Pakistan, Kenya, Egypt or South Africa, you generally cannot give a client local details in your own currency through this route. Your realistic options are to receive in a currency you can hold — usually USD, EUR or GBP — and convert on your own terms when you withdraw, or to use a provider with a domestic payout licence in your country. Receiving in a hard currency and converting yourself is still far better than letting a correspondent chain do it, but it is a different plan from the one above, and the withdrawal step is where your cost now sits. Check that step before you commit.

A common workaround is to form a US LLC so clients can pay a US business account. The company is the easy part; the account is not. Mercury, listed above, does not open accounts for founders who live in Pakistan or Nigeria (Mercury's prohibited countries, checked October 2026), and several US business accounts accept only owners who live in the US. Global Solo's Banking Access Index records, for founders living in eight countries including Pakistan and India, which US business accounts publish an acceptance, which publish a restriction and which say nothing, with a link to each provider's own page. Check your country there before you pay to form the company.

Two things to verify for your own situation, because they vary by the country your account is registered in rather than by the currency: whether local details are offered to residents of your country at all, and whether receiving them requires identity or business verification you can complete. Both are decided at signup, so test with a small payment before you send a client new details on an invoice.

This is the decision that costs freelancers the most and gets the least thought. There are only two sensible answers and they are not equivalent.

Invoice in your client's currency if you can receive it locally and hold it. You remove all friction for them, you avoid their bank's conversion, and you keep control of yours. This is the right default for most freelancers with repeat international clients.

Invoice in your own currency if you cannot receive theirs, or if you need certainty about the exact amount landing. You are then transferring the currency risk and the conversion cost to the client, which is legitimate — but expect it to be priced into what they will pay, and expect the amount arriving to vary if correspondent fees are deducted.

What you should not do is invoice in a third currency neither of you uses, which guarantees two conversions.

If you are paid through a marketplace or payroll platform, much of this is decided for you: the platform holds the funds and pays you out, usually converting on the way at a margin it does not present as a margin.

Where a platform lets you nominate a receiving account, nominating a multi-currency account in the platform's payout currency rather than your local bank account often keeps the conversion in your hands instead of theirs. Where it does not offer the choice, the conversion cost is simply part of the platform's take, and the only lever left is the platform you work through.

Worth being straight about the limits of our own data here, because it changes how much weight to put on any figure you read on this subject.

Every cost figure we publish — the Remittance Cost Index, the Provider Consistency Index, cost by amount — is measured on the sending side: real quotes for someone sending an amount abroad, every six hours, across 80+. We do not measure what a freelancer loses on an incoming payment, because that depends on the payer's bank, on correspondent deductions we cannot observe, and on the receiving account's conversion margin at the moment you convert.

So treat the reasoning above as structural rather than a cost table: the mechanism of who converts is what determines your cost, and that mechanism is well established even where we cannot put a percentage on your specific case. Where a provider does the conversion, our send-side markup measurements are a fair indication of how it prices currency — but they are not a receiving-cost figure, and we will not present them as one.