Local currency pricing at checkout: show, charge, settle

Charge shoppers in their local currency at the moment they pay, but treat it as three separate decisions: the currency you display, the currency you charge, and the currency you settle in. Most cross-border checkouts in 2026 display and charge in local currency and still settle in USD. A live quote connects the three.

This guide is part of the series on what a global payments checkout is. For the conversion data behind local methods, read do local payment methods raise checkout conversion?.

Key takeaways

• Stripe's localization guide says to show prices in the buyer's currency throughout the flow, including the final charge, and to charge in that currency where possible.
• In Baymard's research, 12% of US shoppers abandoned a purchase because they couldn't see or calculate the total cost up front.
• A receiver-side BlindPay payin quote with fees covered by the sender keeps your USD price fixed and shows the shopper an exact local amount, fees and exchange included.
• BlindPay payin quotes expire 5 minutes after creation, so the checkout needs a countdown and a quiet re-quote.
• MXN, COP, and ARS amounts settle in whole units, so the local price you show should have no centavos.

What are the three currency decisions at checkout?

Display, charge, and settlement are separate choices, and mixing them up causes most pricing bugs. Pick each one on purpose.

• Display currency is what the shopper reads on the product page and in the order summary.
• Charge currency is what leaves the shopper's account. On a bank transfer rail it is fixed by the rail: Pix moves reais, SPEI moves pesos, ACH moves dollars.
• Settlement currency is what lands in your account after conversion and fees.

Stripe's payment localization guide recommends showing the buyer's currency throughout the flow, including the final charge, so the shopper never meets a surprise on the bank statement. That covers the first two decisions. The third one is about your treasury, not the shopper.

Should I charge customers in their local currency?

Yes for the display and the charge on local rails, because the rail decides the charge currency anyway. A shopper paying by Pix pays in BRL whether your catalog is priced in BRL or USD.

The real question is where the price is anchored:

• Anchored in local currency. You publish R$ 249. The shopper always sees R$ 249. Your USD revenue moves with the exchange rate.
• Anchored in USD. You publish US$ 45. At checkout a quote converts it, and the shopper sees an exact BRL amount for the next few minutes. Your USD revenue stays fixed.

Baymard's checkout research lists "extra costs too high" as the top abandonment reason at 40%, and 12% of shoppers left because they couldn't see the total up front. Either anchor works if the number shown before the pay button is the number the shopper pays.

Which pricing model fits which business?

The right setup depends on how your costs, refunds, and timing work. This table is a starting point, not a rule.

The deferred-charge row is the trap. If a deposit is charged weeks after booking, the local amount you promised and the amount a fresh quote returns will differ. Decide in your terms who absorbs that gap.

How do you price in USD and show an exact local amount?

Use a receiver-side quote with fees covered by the sender. You fix what you receive, and the quote computes what the shopper pays.

On BlindPay, a payin quote with currency_type set to receiver and cover_fees set to true means the merchant receives exactly request_amount in stablecoins, and sender_amount is the shopper's local amount including fees and exchange. A stablecoin here is a digital dollar token such as USDC or USDT. The flow looks like this:

1. Your backend sends the cart total in USD cents as request_amount, plus the shopper's rail (pix, spei, transfers, pse, ach, wire, or rtp).
2. The quote returns sender_amount in the shopper's currency, minor units, and expires_at 5 minutes out.
3. The page shows the local amount large, with "includes fees and exchange" under it.
4. The shopper confirms, and your backend creates the payin from the quote within the window.
5. If the window closes, the next click requests a fresh quote instead of showing an error.

With cover_fees set to false, the fee comes out of what the merchant receives instead. That suits a business that wants a round local price and accepts a variable USD result. Pass-through vs absorbed FX costs covers that pricing choice in depth.

How do rounding and whole units change the price you show?

Some currencies only settle in whole units, so the price you show must match. Round before you display, not after.

BlindPay settles MXN, COP, and ARS payins in whole units. A sender-denominated request in those currencies must be a multiple of 100 minor units, and a computed sender amount is rounded down to a whole unit. So MXN 823 is a valid amount and MXN 823.40 is not. Show "MXN 823", not "$823.40". Prefix the ISO code too, since several Latin American locales print pesos with a bare "$" that a shopper could misread as dollars.

Price psychology still applies on top. If you anchor in local currency, round to the prices people expect in that market. If you anchor in USD, the local amount will look precise, and that's fine: precision reads as honesty when the label says fees are included.

How do you avoid converting twice?

Settle in the currency you spend. Every conversion adds a spread, so a BRL sale settled in USD and then converted back to BRL for a Brazilian supplier pays for two trips.

Three patterns help:

• Settle in USD and spend in USD. Payroll, cloud bills, and US suppliers stay in dollars.
• Hold a stablecoin balance and pay out locally later. The balance sits in USDC or USDT, and a payout converts it once, at the moment a Brazilian or Mexican supplier is paid.
• Match flows by currency. If you collect BRL and owe BRL, net them in planning before you convert anything.

How does BlindPay handle local currency pricing at checkout?

BlindPay is the money layer behind the checkout you build. You keep your catalog in USD, and every payment starts with a payin quote for the shopper's rail: Pix in Brazil, SPEI in Mexico, Transfers 3.0 in Argentina, PSE in Colombia, or ACH, wire, and RTP in the US.

A receiver-side quote with cover_fees set to true returns the exact local amount the shopper pays, fees and exchange included, while the merchant receives the full USD price as USDC or USDT. The quote locks the rate and fees for 5 minutes, enforces minimum and maximum amounts per currency, and settles MXN, COP, and ARS in whole units. Fees vary by rail and appear in the live quote before you create the payin. BlindPay does not publish a static flat rate card, so read the fee breakdown from each quote.

When the merchant needs local currency later, a payout quote converts the balance once and pays a supplier over Pix, SPEI, ACH Colombia, Transfers 3.0, SEPA, or SWIFT (POBO/COBO). Platforms can add their own margin with a partner fee on the same quote.

Methodology and sources

Pricing guidance comes from Stripe's payment localization guide (updated May 22, 2025) and Baymard's cart abandonment research (updated September 22, 2025). Stripe's Checkout documentation describes Adaptive Pricing, which lets shoppers pay in their local currency on a card checkout. BlindPay facts come from the payin quotes, payins, and cut-off times docs, as of October 2026. The table above is a starting point; test prices with your own shoppers.

What to do next

Write down your display, charge, and settlement currency for your top two markets. Then open a BlindPay development instance, create a receiver-side payin quote for one cart, and put the returned local amount on your checkout page with a 5-minute countdown. Show the quote screen to five shoppers before you launch.