Currency conversion at checkout and who pays for it

A Malaysian store that sells to Singapore, Indonesia or further afield ends up with prices in one currency, a payment in another and a bank credit in a third. Somewhere in that chain a rate was applied, and a margin was taken on it.

The question worth answering is where, because that determines whether the cost lands on your customer, on your gateway's spread or on your gross margin.

Four places a rate can be applied

In your price list. You set a foreign price manually, or the store converts from a base currency using a rate you control. The rate is your decision and your risk, and it moves only when you change it.

At checkout by the store. The platform presents a converted price using a rate it maintains, often with a markup, and the customer sees a familiar currency. Convenient for conversion rate, and the spread is usually not disclosed to you line by line.

At the card issuer. The customer is charged in your currency and their own bank converts it. You are unaffected — you receive what you charged — and the customer bears a rate you never see. This is the cleanest arrangement for your books and the least transparent for them.

At settlement by your gateway. The transaction happened in one currency and your payout arrives in another, converted by the gateway at its own rate on its own date. This is the one that surprises people, because the amount you receive differs from the amount you charged for a reason that appears nowhere in your order data.

Most stores are running two or three of these at once without having decided to.

Who bears the spread

Trace it and the answer is usually plain.

If the conversion happens at the issuer, the customer bears it. If it happens in your price list, you bear it — you fixed a price and the rate moved underneath you. If it happens at checkout with a platform markup, the customer pays the markup and you may or may not see any of it.

If it happens at settlement, you bear it and you find out afterwards. The order says one number, the payout says another, and the gap is a real cost of sale that has no invoice attached to it.

That last case is the one to establish before you sell across a border, and the question to ask your gateway is narrow: in which currency will you be paid, at what rate, applied on which date, and is the rate shown on the settlement report? A provider that cannot answer the last part is one whose spread you will never be able to measure — see gateway API or settlement file.

The reporting consequence

Multi-currency selling breaks two reports that most stores rely on.

Revenue by product becomes ambiguous, because the same unit sold in two currencies converts at two rates, and if the conversion is applied at reporting time rather than at transaction time the history moves every time rates do.

Gross margin becomes unstable, because cost is almost always in one currency and revenue in several. A product can look more profitable this month purely because a rate moved, which is information about the currency market rather than about your business.

The discipline that fixes both is recording the transaction currency, the amount in it, the rate applied and the base-currency amount, all four, on every order. Then a report can be built either way and neither is a reconstruction. Most systems store two of the four — see multi-currency accounting with AI.

Recording a converted sale properly

Book revenue at the rate on the transaction date. Not today's rate, not the month-end rate. The sale happened at a point in time and that is the rate that describes it.

Treat the settlement difference as its own thing. The gap between the transaction-date value and what actually arrived is a foreign exchange difference, not a discount and not a fee. Coding it to either hides a real and separately controllable cost.

Keep the gateway's fee and the conversion spread apart. They are different costs with different remedies. A gateway can be cheap on fees and expensive on conversion, and a blended figure lets that go unnoticed.

Hold foreign balances as foreign balances if you keep any. Revaluing them is a distinct exercise from recording sales, and mixing the two produces movements nobody can explain — see importing and foreign currency.

The refund asymmetry nobody plans for

A refund converts again, at a later date, at a different rate.

So a fully refunded foreign-currency sale does not net to zero on your books. It nets to a small gain or loss, in either direction, created purely by the interval between the two conversions. On a handful of orders this is noise. On a store with a meaningful return rate and a volatile pair it is a line item.

Whether the original fee comes back is a separate question with its own answer — see what happens to the fee when you refund. The two effects compound, and a refunded cross-border sale can cost you more than the margin it originally earned.

Common questions

Who pays for currency conversion on an online sale?

It depends entirely on where the rate is applied. If the customer's own card issuer converts, the customer bears it and you receive exactly what you charged. If your platform converts at checkout, the customer pays whatever markup is built into that rate. If your gateway converts at settlement, you bear it, and you discover the amount only when the payout arrives.

Why does my payout differ from the order total on a foreign sale?

Usually because the gateway converted the transaction into your settlement currency at its own rate on its own date, which is not the rate or the date on the order. That difference is a genuine foreign exchange cost of sale and needs recording as such, separately from processing fees, because the two are controlled in different ways.

What rate should a foreign-currency sale be recorded at?

The rate applicable on the transaction date, not the current rate or a month-end rate. The sale occurred at a point in time and that rate describes it, which keeps historical revenue stable instead of moving every time exchange rates do. The subsequent difference on settlement is then recorded separately as an exchange difference.

Does a refunded foreign-currency sale net to zero?

No. The refund converts at a later date and therefore at a different rate, so the pair leaves a small exchange gain or loss behind. Combined with a processing fee that may not be returned, a refunded cross-border order can end up costing more than the margin the original sale produced.

Related: multi-currency accounting with AI · what happens to the fee when you refund · importing and foreign currency