A client in Poland funds an account with 2,000 zloty. The firm keeps its books in US dollars. Between the card being charged and the money arriving in the merchant account, that amount is converted at least once, sometimes twice, and the rate used is not the one the client saw on the deposit page.
Firms negotiate the visible costs hard. Interchange, scheme fees, the processor's percentage and the fixed item fee all get argued over. The conversion is the cost that hides, because it is never billed. It sits inside the rate, so it appears on no invoice line and gets compared against no benchmark.
Where the second conversion happens
Three currencies matter in any card deposit. The cardholder's account currency, the currency the transaction is presented in, and the settlement currency of the merchant account. When all three match, nothing is converted. When they differ, each mismatch is a conversion leg, and each leg belongs to a different party with its own rate source.
| Leg | Who applies the rate | Where it shows up |
|---|---|---|
| Cardholder currency to transaction currency | The card scheme, plus any issuer markup | On the client's bank statement, not yours |
| Transaction currency to settlement currency | Your acquirer or PSP | Inside the settlement amount |
| Settlement currency to your accounting currency | Your bank or EMI | On the bank statement |
Most operators are aware of leg one because clients complain about it. Leg two is the one that leaks quietly. The processor receives an amount in euros, credits your account in dollars, and the rate it used is whatever its treasury desk decided that morning. Leg three is at least visible, and if you are already reading up on currency conversion fees at the banking layer, apply the same discipline one step upstream.
A markup that lives inside the rate
PSP FX pricing is a spread, not a fee. The processor takes a reference rate, moves it in its own favour by a number of basis points, and settles at the moved rate. Fifty basis points on a euro deposit book is half a percent of gross volume, which on many card programmes is larger than the acquiring margin itself.
The only way to measure it is to sample. Take a settlement file, pick twenty transactions, note the applied rate and the timestamp, and compare against a mid-market rate for the same pair at roughly the same time. The gap, expressed in basis points, is your real FX cost. Do it for each currency you accept, because the markup is rarely uniform: a processor may run three basis points on EUR/USD and sixty on a thinner pair.
Dynamic currency conversion at checkout is a separate mechanism. It offers the client a price in their home currency at a rate set at the point of sale, and the margin is shared between parties in the chain. It can improve conversion on some markets and it can also produce complaints when the client compares the charge to their bank's own rate. Treat it as a product decision, not a default.
The gap between authorisation and settlement
Authorisation and settlement are not the same moment. A card is authorised on Tuesday and settles on Wednesday or Thursday. If the processor fixes FX at settlement, the amount credited reflects a rate you did not see when the client's balance was created.
For a trading firm that credits the platform balance instantly, this creates a small open position on every cross-currency deposit. Individually it is noise. Across a large book in a volatile week it is a real number, and it is the reason some firms move to same-currency settlement accounts rather than trying to hedge it. Firms with meaningful exposure sometimes treat it inside a broader currency hedging programme rather than as a payments line.
Refunds make it worse. A refund is converted back at the rate in force on the refund date. If the pair has moved two percent since the deposit, the merchant account is debited two percent more than it was credited, and the difference is yours. Firms with a generous refund policy should track that gap in its own ledger account instead of burying it in processing costs.
Payouts inherit the same problem
The withdrawal side is where clients notice. Someone deposits 2,000 zloty, trades nothing, asks for the money back, and receives 1,930. Nothing was stolen. Two conversions were applied with two markups and the client is looking at the round trip. Support cannot explain it if support has never been shown the mechanism, which is why the FX policy belongs in the client-facing terms and in the internal playbook at the same time.
The cleanest fix is structural: hold balances in the currency the client funds in, and convert once, on your schedule, rather than on the processor's. That means multiple settlement currencies at the PSP and matching accounts on the banking side, which is one of the practical arguments for multi-currency accounts in an operating stack. It costs more in account maintenance and it removes a variable cost that scales with volume.
Reading the FX clause before you sign
Processor contracts almost always contain the answer, usually in a schedule near the back. Six questions are worth asking before signature, and the answers should be in writing rather than in an email from a salesperson.
Which reference rate is used and who publishes it. At what time of day the rate is fixed. What markup is applied, stated in basis points rather than as "market rate". Whether refunds and chargebacks use the original rate or the current one. Whether you may add settlement currencies later and at what cost. Whether the markup is fixed for the contract term or revisable on notice.
If a processor will not put a basis point number in the contract, that is the answer. It does not automatically disqualify them, because approval rates and coverage in a given market may still be worth the spread, but you should then price the FX as an unknown and size the relationship accordingly. Running more than one processor gives you a comparison you cannot get any other way, which is a side benefit of the payment orchestration approach rather than its main purpose.
For most firms the honest answer is that FX at the PSP is the second largest payment cost after the acquiring margin and the first one nobody has measured. Measure it once and the negotiation changes, because you stop asking for a better rate and start asking for a specific number of basis points.
"Ask a processor what their FX markup is in basis points and watch what happens. If the answer is a number, you can work with them. If the answer is a paragraph, you already know what it costs you."
— Roman Onta, Executive Director, SINGUARD
Key Takeaways
- A cross-currency card deposit can be converted twice before it reaches your books, and only one of those legs appears on the client's statement.
- PSP FX is priced as a spread inside the rate, so it never appears as an invoice line and has to be measured by sampling settlement files against mid-market.
- Refunds and chargebacks reconvert at the current rate, so a moving pair turns a returned deposit into a loss or a windfall that belongs in its own ledger account.
- Settling in the currency the client funded in, then converting once on your own schedule, removes a variable cost that grows with volume.
Frequently Asked Questions
How many times is a deposit converted before it reaches the merchant account?
It depends on how many currencies sit in the chain. If the cardholder currency, the pricing currency of the transaction and the settlement currency of the merchant account are all different, the money can be converted twice: once by the card scheme and once by the processor when it settles. If the account settles in the same currency the client paid in, there is no conversion at all.
Why does the FX markup not appear on the processor invoice?
Because it is applied inside the exchange rate rather than billed as a line item. The processor takes a reference rate and moves it in its own favour by a number of basis points. The statement shows the converted amount, not the benchmark it was converted from, so the cost is only visible if you compare the applied rate against a mid-market rate at the same timestamp.
What happens to FX on a refund?
A refund is usually converted back at the rate in force on the refund date, not the rate used on the original deposit. If the pair has moved, the merchant account is debited more or less than it was originally credited, and the difference lands on the firm. Firms that refund often should track this gap separately instead of netting it into processing fees.