Multi-Currency Refunds Without the Shortfall

A customer pays 100 EUR, returns the item, and receives 96 EUR back. Nothing was deducted, no restocking fee applied, and your ledger shows a full refund. The four euros disappeared into the gap between the exchange rate on the day of purchase and the rate on the day of refund, and the customer will read it as a deduction you made on purpose.

This is one of the most common causes of returns disputes in cross-border retail, and it is almost entirely a systems design question rather than a policy one.

Where the Shortfall Comes From

There are three separate places a currency gap can open. The processor may settle in your account currency and convert back at refund time. The customer's card issuer may apply its own conversion, which you never see and cannot control. And your platform may hold the order value in one currency and issue the refund in another.

The first and third are yours to fix. The second is not, which makes explaining it to the customer part of the design rather than an afterthought. Payment platform documentation such as Stripe's refunds guide sets out how the original charge currency governs the refund, and the same principle applies across processors.

Refund in the Currency You Charged

The single most effective rule is to refund in exactly the currency the original charge was made in, for exactly the minor-unit amount that was captured. Do not recompute the value from your base currency, do not re-derive it from an order total in another currency, and do not apply a current exchange rate.

This sounds obvious and is broken surprisingly often, usually because the returns system reads the order value from a normalised reporting field rather than from the payment record. The fix is architectural: the refund must be driven by the payment transaction, not by the order, and the two are not the same object. Merchants with a clean returns data model usually have this separation already.

Partial Refunds Are Where Rounding Bites

Full refunds are easy because you return the captured amount. Partial refunds require allocating a portion of the charge, and if you compute that portion by percentage in a different currency you introduce rounding at exactly the point a customer is checking arithmetic.

Work in minor units and allocate at line level rather than by percentage of the total. Where an order had shipping, tax and a discount spread across lines, the allocation rule needs to be explicit and consistent, otherwise two partial refunds of the same order can sum to more or less than the original charge. This is the same discipline needed for partial returns and split payments.

• Store the charge currency and minor-unit amount on the order at capture.
• Drive refunds from the payment record, never from a normalised order total.
• Allocate partial refunds at line level in minor units.
• Never apply a live exchange rate to a refund.
• Reconcile refunded totals against captured totals per currency, not in aggregate.

The customer does not see an exchange rate. They see that they paid one number and got a smaller one back.

What You Cannot Control, Explain

If the customer's card was issued in a different currency from the charge, their bank applies its own conversion on both the payment and the refund, at different rates on different days. You will refund the exact amount you captured and the customer will still see a difference on their statement.

The only workable response is to say so before it happens. A short line in the refund confirmation explaining that the amount refunded matches the amount charged in the original currency, and that their bank may apply a different conversion rate, converts a suspected deduction into an understood exchange effect. It costs one sentence and removes a recurring support category, in the same way clear returns notifications remove uncertainty elsewhere in the flow.

Store Credit Sidesteps the Problem

Store credit issued in the customer's original currency has no conversion step at all, which is a genuine advantage rather than only a retention play. For merchants with meaningful cross-border volume, this is a real argument for making credit an attractive option, though it must remain a choice rather than a default where a refund is a statutory right. The wider trade-off is covered in store credit versus refund.

Fees, Tax and Reconciliation

Processor fees on the original charge are frequently not returned when you refund, which means a refunded order costs you the fee twice in effect. That is a real cost and belongs in your unit economics, but it is not a deduction you can pass to the customer in most consumer contexts.

Tax adds a further wrinkle in cross-border cases, because the rate applied at sale depends on the destination and must be reversed at the same rate rather than the current one. Reconciling refunds per currency and per tax jurisdiction rather than in aggregate is what makes these errors visible before period end, and it pairs with the invoicing discipline in cross-border VAT and duty on returns.