Local-Currency Checkout: Which Amount Did the Customer Actually Pay?

A currency selector is not enough to specify international checkout. Decide whether the shopper is only seeing an estimate, choosing an actual payment currency or viewing a separately maintained local price. Then make sure the order record can explain the amount the customer saw and paid, even when your integration records another currency.

Choose the commercial model before the display

A translated page with a local currency symbol does not establish a converted price. In your brief, distinguish three possibilities: an indicative conversion with payment in the original currency, provider-managed conversion during checkout, and fixed prices maintained separately for each currency. These are scope choices, not interchangeable labels for the same feature.

For an estimate, agree the wording and when the payable amount becomes final. For conversion, identify the provider and the supported checkout integration. For separately maintained prices, name the person responsible for updating each list. Do not promise identical behaviour merely because the screens look alike.

Retain both amount-and-currency pairs when needed

The Stripe Adaptive Pricing documentation gives a useful example of the distinction. In its hosted-checkout guidance, Checkout and the underlying PaymentIntent reflect the integration-currency amount. When customers pay in local currency, the documented completion and payment-success events include presentment_details, with presentment_amount and presentment_currency.

Those fields explain why a generic field called “paid amount” can be ambiguous. For a custom order record, ask which pair staff see first, where the other pair remains available and how both relate to the provider's payment reference. Preserve the actual recorded values rather than reconstructing a historical customer payment using today's exchange rate.

This is a record-design recommendation, not a statement that either pair equals the eventual bank payout. Settlement, fees, bookkeeping and tax treatment require their own verified mapping. Do not label a converted customer total “net revenue” simply because it came from a successful-payment event.

Make the fallback an intentional journey

Stripe says unsupported Adaptive Pricing sessions show prices in the original price currency. The documented exclusions include sessions using manual capture. That matters if your business also wants to reserve a payment and charge later: verify the combined feature set rather than approving each feature in isolation.

For your implementation, agree what shoppers see when local conversion is unavailable. The original-currency checkout may be acceptable, but its currency must be clear before confirmation. An earlier estimate must not remain visually attached to a different payable amount. Include a route back to review the order rather than making a failed conversion look like a completed payment.

Avoid promising that any customer can use any currency or payment method. Ask the implementer to identify the current supported combination for your account, customer market and checkout type. This article does not establish a complete eligibility list.

Give support the customer's version of the payment

A shopper may contact staff using the amount visible in their checkout confirmation. The team needs to locate that payment without insisting that the customer quote the integration-currency amount instead. Specify useful search fields, clear currency codes and a provider reference. Restrict access to the payment data according to staff responsibilities.

Also decide what your own confirmation says. Do not turn it into an exchange-rate guarantee, a bank-fee promise or a refund promise without separately verified terms. Refund currency and amount handling need their own provider and business review; the success-event fields alone do not settle them.

Demonstrate the two-currency case

In a provider test environment, complete an eligible local-currency payment and compare the checkout, stored event data, order record and support view. Demonstrate a session falling back to the original currency, plus the manual-capture combination if that is in scope. Confirm that reopening the order does not recalculate the recorded payment.

Put these outcomes in your acceptance criteria before commissioning the checkout integration. The useful result is a payment that both the customer and the team can identify, not a dropdown that changes a currency symbol.