--- title: "Local currency pricing at checkout: show, charge, settle" seoTitle: "Local currency pricing at checkout: show, charge, settle" description: "Should you charge shoppers in their own currency? Split it into three decisions: display currency, charge currency, and settlement currency." date: "2026-10-14" updated: "2026-10-14" category: "payments" author: "BlindPay Team" faq: - q: "Should I charge customers in their local currency?" a: "Usually yes for the display and the charge, and not always for settlement. Shoppers convert better when the total they see is the total they pay in their own currency. You can still price in USD and settle in USD: a receiver-side quote turns your USD price into an exact local amount that includes fees and exchange, so the shopper pays reais or pesos and you receive dollars." - q: "What is dynamic currency conversion?" a: "Dynamic currency conversion is a card-world practice where the shopper is offered a conversion into their home currency at the point of sale, usually at a rate set by the acquirer or terminal. It is different from local currency pricing, where the merchant sets or quotes the local price up front. On a bank transfer checkout the shopper pays in the rail's currency, so the conversion sits inside your quote." - q: "Who bears FX risk when I price locally?" a: "Whoever fixes the price carries the risk. If you publish a fixed BRL price and settle in USD, a weaker real costs you margin. If you price in USD and quote the local amount at checkout, the shopper sees a slightly different local number each time and you receive a fixed USD amount. Quote expiry limits the window: a BlindPay payin quote locks the rate for 5 minutes." - q: "Should I settle in USD or local currency?" a: "Settle where your costs are. A US company paying US suppliers and payroll should settle in dollars. A business with Brazilian or Mexican suppliers may want to hold some local currency to avoid converting twice. With BlindPay the shopper pays locally, the merchant receives USDC or USDT, and it can pay suppliers later over Pix, SPEI, ACH, or SWIFT (POBO/COBO) from that balance." - q: "How do live quotes work at checkout?" a: "A live quote converts your price into the shopper's currency at the current rate, adds fees, and holds that number for a short window. On BlindPay a payin quote returns the shopper's amount in minor units and an expires_at timestamp 5 minutes out. Show a countdown, create the payin before it runs out, and request a new quote on the next click if the shopper comes back later." --- 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](/resources/more/what-is-a-global-payments-checkout). For the conversion data behind local methods, read [do local payment methods raise checkout conversion?](/resources/more/local-payment-methods-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](https://stripe.com/resources/more/payment-localization-best-practices-a-guide-for-scaling-payments-worldwide) 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](https://baymard.com/lists/cart-abandonment-rate) 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. | Business type | Display | Charge | Settle | Why | | --- | --- | --- | --- | --- | | Digital goods and apps | Local, rounded | Local rail currency | USD | Low marginal cost, so a fixed USD anchor with local display is simplest | | SaaS subscriptions | Local price list per market | Local rail currency | USD | Shoppers compare monthly prices against local rivals | | Marketplace | Seller's price in buyer's currency | Local rail currency | USD, then pay sellers locally | Sellers often want their own currency, see [the FX gap between sale and payout](/resources/more/fx-gap-between-sale-and-payout) | | B2B invoices | Invoice currency agreed in contract | Invoice currency | USD or local | Terms are negotiated, see [invoicing in BRL or MXN and settling in USDC](/resources/more/invoice-in-local-currency-settle-in-usdc) | | Travel with deferred charges | Local at booking | Local at charge time | USD | The charge happens later, so the rate at booking is not the rate at charge | 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](/resources/more/pass-through-or-absorb-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](https://stripe.com/resources/more/payment-localization-best-practices-a-guide-for-scaling-payments-worldwide) (updated May 22, 2025) and Baymard's [cart abandonment research](https://baymard.com/lists/cart-abandonment-rate) (updated September 22, 2025). Stripe's [Checkout documentation](https://docs.stripe.com/payments/checkout) describes Adaptive Pricing, which lets shoppers pay in their local currency on a card checkout. BlindPay facts come from the [payin quotes](/docs/payin-quotes), [payins](/docs/payins), and [cut-off times](/docs/kb/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](/resources/more/cross-border-quote-screen-fee-disclosure) to five shoppers before you launch.