Cross-Border FX Runs on Three Routing Decisions, Not One Fee

On 17 August Stripe announced two currency upgrades: multi-currency settlement expanding to more markets, and instant currency conversion — the ability to hold and convert funds between currencies directly in the Stripe Dashboard, by API, or on mobile. Stripe frames the problem as a "double foreign exchange trap": businesses pay to convert incoming payments into their home currency, then pay again to convert funds back out for payroll, vendors, or operating expenses in foreign currencies.

The announcement is worth more than a pricing note, because it names a structure most small cross-border sellers have never modelled. Your real FX cost is not one fee. It is the product of three independent routing decisions: presentment (which currency the buyer pays in), settlement (which currency accrues in your payment balance), and conversion/payout (how and when money leaves the system). Each leg has its own fee surface, its own timing, and its own failure modes. Until last week, the third leg lived outside Stripe — in bank settlement windows, manual transfers, and rate markups you could not audit. Instant conversion pulls it into the same ledger as the first two, which changes what a small operator can measure, schedule, and automate.

The repeated angle to avoid

The ten most recent posts here covered MCP traffic detection, ECH and certificate evidence, deployment-level authentication, Shopify checkout fields, agent-plugin trust, agent context copies, Turnstile and lead quality, server-side agent conversion tracking, AI work receipts, and prototype exits. Older overlapping posts covered AI spend measurement and spend-capable agents, but nothing here has covered payment routing.

The weak version of this article is the old X needs Y formula: cross-border sellers need to cut FX costs, so enable the new Stripe features. That version treats FX as a single line item and reaches for a toggle. The sharper thesis is that FX cost is set by routing decisions made at three separate moments — one at checkout, one at settlement configuration, one whenever money exits — and the announcement matters because it makes the third decision programmable and auditable instead of manual and opaque. An operator who enables conversion without revisiting the first two legs optimises the cheapest leg and leaves the double conversion in place.

Fresh evidence and background context

The source map separates this week's announcement from the current implementation documentation:

Source	Freshness	What it contributes
Stripe: new currency capabilities to cut FX costs	17 August 2026	The double-FX-trap framing, settlement expansion to 37 markets by end of 2026 (up to 18 currencies), instant conversion across 15 currencies, pricing claims (real-time rates, 24/7, no embedded markups or weekend surcharges), and conversion-cadence data
Multi-currency settlement docs	Current primary documentation	Default conversion behaviour, the up-to-18-currency cap, current availability locations, the presentment prerequisite, per-currency bank account matching, and per-currency payout minimums
Settle in additional currencies docs	Current primary documentation	Where fees land: processing fees applied in the settlement currency, payout fees for non-primary and non-domestic payouts, and the forced-conversion behaviour for unbanked currency balances
FX Quotes API in Connect	Current primary documentation	Rate locking with lock_duration, quote attachment to PaymentIntents and transfers, fee pass-through choices, and the two embedded conversions in Connect direct charges
Supported currencies guide	Current primary documentation	The 135+ presentment currency range, and issuing-region fee variation for EEA cards driven by cross-border fees and exchange rates

The new information surplus sits between these sources: the blog explains what changed and why, the settlement docs explain where fees actually land, and the FX Quotes docs reveal the second conversion that marketplace platforms inherit by default. None of them assemble the three-leg routing map an operator needs before touching any setting.

The three legs, and what each one costs you

Follow one customer payment through the system. A buyer in Germany pays an Australian store. The money crosses three decision points, and at each one a configuration choice was made — deliberately or by default.

buyer card         -> presentment currency  (leg 1: what they pay in)
  -> acquiring fees, issuing-region effects
Stripe balance     -> settlement currency   (leg 2: what accrues)
  -> per-currency processing fees
exit               -> payout or conversion  (leg 3: how money leaves)
  -> conversion pricing, payout fees, timing
  -> supplier, payroll, vendor, or home bank

Leg 1 — presentment. This is the currency the charge is made in. Stripe supports charging in over 135 currencies, and the choice is not free in either direction. Present in your home currency and the buyer's bank or wallet does its own conversion — a worse rate and a known friction point for international checkout. Present in the buyer's currency and the acquiring cost varies with the card's issuing region: Stripe's currency guide notes that EEA-issued cards can incur different fees depending on the transaction currency because of cross-border fees and exchange rates. The fee surface here is per-currency acquiring pricing, and the failure mode is optimising conversion rates while quietly paying more per transaction — or losing the sale at checkout.

Leg 2 — settlement. By default, Stripe converts all incoming funds into your default currency before they settle. That default is the first half of the double trap: euros earned from German customers become Australian dollars on arrival, and any euro-denominated supplier invoice now needs a second conversion. Multi-currency settlement changes the routing: balances accrue — and can pay out — in up to 18 supported currencies, which Stripe documents as a way to pay suppliers, process refunds, and avoid FX fees. The mechanics carry three constraints an operator must plan around:

• You cannot just decide to hold a currency. To accrue a balance in a currency, you must first accept payments in that currency — presentment enables settlement, not the other way round.
• Each settlement currency needs its own bank account, currency-matched, before payouts in that currency will flow.
• Processing fees for non-primary settlement currencies are applied in that currency, not your reporting currency — which matters for reconciliation and for margin maths on small balances.

Leg 3 — conversion and payout. This is the leg that historically escaped. Funds had to reach a bank before anyone converted them, so businesses stitched Stripe to a bank or FX provider, waited out settlement windows, and accepted whatever arrived. The announcement changes this: businesses accepting multiple currencies can now hold and convert between 15 currencies with real-time rates, around the clock, with no markups embedded in the rate or weekend surcharges, and additional currencies planned. The fee surface here is the conversion pricing itself plus payout fees — payouts in a currency other than the primary currency of the recipient bank's country incur a fee, and certain payouts to non-domestic bank accounts also incur fees.

Leg	You decide	Fee surface	Timing	Failure mode
Presentment	Currency shown at checkout	Per-currency acquiring; issuing-region variation	Instant	Buyer-side conversion friction, or higher per-transaction costs than expected
Settlement	Which currencies accrue in your balance	Processing fees applied in settlement currency	With payout schedule and per-currency minimums	Default auto-conversion re-creates the trap; unbanked currency balances force conversions
Conversion/payout	When and how money exits	Conversion pricing; non-primary and non-domestic payout fees	24/7 instant conversion; payouts on schedule	Ad-hoc conversions at random moments; paying twice for one obligation

Conversion is becoming a scheduled operation

The most under-discussed number in the announcement is behavioural: Stripe reports that 50% of businesses convert on multiple occasions within 60 days of their first conversion, averaging a conversion every 25 days — a cadence consistent with payroll cycles and month-end close.

That statistic reframes what the feature is. Conversion is not an occasional rescue operation triggered when a balance looks uncomfortably large. It is a recurring operational step that tracks the business's foreign-currency obligations. The right control model is the one payroll already uses:

1. List recurring foreign-currency obligations — contractors, suppliers, ad spend, subscriptions, inventory — with amounts and dates.
2. Present and settle in the currencies those obligations actually use, so revenue funds them directly where volume justifies it.
3. Convert on a schedule matched to the obligation calendar, sized to the obligation — not to a view about where the exchange rate is going.
4. Review the routing quarterly: which currencies crossed a volume threshold where enabling settlement or attaching a bank account pays for itself.

Treating conversion as market timing is the failure mode; treating it as obligation matching is the operating discipline. The API makes the scheduled model automatable, and Stripe notes platforms can use the conversion API to distribute currency management to their merchants — relevant if you run a marketplace or billing product on top of Stripe.

Failure modes the documentation already warns about

The docs encode several traps that bite exactly when someone half-configures the system:

• The forced conversion. If you accumulate a balance in a currency with no matching bank account and create a manual payout in that currency, a conversion occurs. You settle in euros, never attach a euro account, then pay out — and the routing you configured gets silently undone at the exit.
• The presentment prerequisite. Enabling a settlement currency does not create a balance. Without charges in that currency, the balance stays empty and the configuration is decorative.
• The minimum-payout threshold. Multi-currency payouts follow a currency's minimum payout amount. A low-volume currency can accrue indefinitely below its threshold — fine if you are accumulating toward an obligation, a surprise if you expected cash.
• Fees in the wrong currency for your books. Processing fees applied in the settlement currency mean your reporting currency totals understate costs unless reconciliation groups balance transactions by currency.
• The embedded marketplace double conversion. For Connect direct charges, funds are converted to the connected account's default currency, and the application fee is then converted to the platform's default currency — two conversions inside one charge. The FX Quotes API exists to manage this: lock a rate with lock_duration, attach the quote to the PaymentIntent or the transfer, and decide explicitly whether fees pass through to the customer.

A decision table by seller profile

Profile	Leg 1	Leg 2	Leg 3
AU store, mostly US customers, costs in AUD	Present USD	Settle USD	Convert USD→AUD on a schedule sized to payroll and supplier dates; keep a USD buffer for US subscriptions
UK seller paying EU contractors	Present EUR to EU buyers where volume justifies	Settle EUR with a matched EUR bank account	Pay contractors from the EUR balance — zero conversions instead of two
Marketplace on Connect	Buyer's local currency, quoted with a locked rate	Multi-currency settlement on connected accounts where supported	Quote the transfer leg too; decide fee pass-through explicitly rather than inheriting two embedded conversions
Occasional cross-border sales	Home currency	Default settlement	Accept the single conversion; revisit when foreign-currency obligations become recurring rather than incidental

The enabling decision rule: enable a settlement currency when recurring obligations in that currency are large enough that the conversions they replace cost more than the operational overhead of another currency balance, bank account, and reconciliation line. Below that threshold, the default single conversion is honest and cheap to audit.

A five-question FX audit

Run this against last month before changing any setting:

1. Which currencies did we present, and what did acquiring cost per currency — including issuing-region variation?
2. For each currency we accepted, where did it settle — which balance did it land in, and was any of it auto-converted at the door?
3. How many conversions did an average customer payment take before it paid a real obligation?
4. Do we hold balances in any currency without a matched bank account — and has a manual payout ever triggered a forced conversion?
5. Are processing fees booked in the currency they were charged in, or absorbed invisibly into reporting-currency totals?

If question 3 returns "two or more" for a meaningful share of revenue, the double trap is live, and the fix starts at legs 1 and 2 — not at the conversion screen.

What changes, and what does not

The announcement makes the third leg programmable: conversion becomes a schedulable, auditable operation inside the same system that accepts the money, with an API and pricing that is at least inspectable in real time. Expansion to 37 markets by the end of 2026 — Australia, Hong Kong, and Singapore among them — extends the option beyond the currently listed availability locations.

What it does not change: acquiring costs still vary by currency and issuing region, payouts to non-domestic banks still carry fees, presentment still gates settlement, and Connect flows still embed their own conversions unless you quote them explicitly. The operator's job is unchanged in kind but newly tractable in practice: route each currency deliberately through the three legs, measure the fees at each leg separately, and let the obligation calendar — not the exchange rate — decide when money moves.