Stripe Moved Settlement Currency Into the API on October 28. The Foreign Bank Account Was the Real Blocker, Not the Toggle.

If you run a Connect platform and a connected account gets paid in a currency it didn't ask for, Stripe has been quietly converting that money for them the whole time — into whatever currency the account's primary balance happens to be. That's the default, and it's been the default since multi-currency settlement existed. What changed on October 28 isn't the feature. It's who can turn it on, and what they need to have ready before they do.

That same Visa/PCMI research found unfavorable foreign exchange rates sitting among the top handful of complaints sellers raise about getting paid on a platform, behind only high transaction fees. For a vertical SaaS product that processes payments for its own merchant customers — the pattern we've covered before in platform defensibility and Balance Pay's payout timing — that's not an abstract pain point. It's a reason a merchant quietly moves their processing to a competitor that doesn't force every payout through a currency conversion they never asked for.

What actually shipped on October 28

Stripe added two fields to the payments hash on the Balance Settings object: settlement_currencies, a map of ISO 4217 currency codes to one of three states, and default_settlement_currency, which reports the account's current default. A platform can now call the Balance Settings API directly to enable or disable a settlement currency for a connected account, instead of relying on the account holder to do it themselves through a Dashboard they may not even have access to.

Multi-currency settlement itself isn't new — it's been a Dashboard toggle for a while, letting an account accrue a balance in up to 18 currencies instead of Stripe auto-converting everything on arrival. The gap was in who could reach it. An account with full Stripe Dashboard access could add a settlement currency themselves by clicking into their Balances page. An account without that access — the common setup for a vertical SaaS platform that onboards merchants through its own product rather than handing them a Stripe-branded dashboard — had exactly one path: the platform attaches an external bank account for that merchant in that specific currency. No bank account, no settlement currency, full stop, even if the merchant never intended to withdraw the money and just wanted to hold it, convert it, or pay a supplier with it.

Why "just convert it automatically" was the expensive default

Presentment currency and settlement currency are different things, and the gap between them is where the money leaks. A customer can pay a merchant in EUR — the presentment currency, what the customer sees and authorizes — while that merchant's Stripe balance settles in USD, their default. Stripe's standard behavior converts the EUR payment to USD the moment it settles, at Stripe's rate, whether or not the merchant ever wanted USD. If that merchant's own costs — supplier invoices, refunds back to EUR customers, payroll in a EUR-denominated country — are also in EUR, they just paid a conversion fee to turn EUR into USD, and they'll pay another one converting it back.

Multi-currency settlement breaks that cycle by letting the balance stay in the currency it arrived in. Stripe still charges its own multi-currency settlement fee when funds settle into a non-primary currency — it isn't free, and it shows up on the Dashboard and in reporting labeled exactly that — but it's a single, disclosed fee instead of two conversion spreads stacked on top of each other. The October 28 change doesn't touch that pricing. It touches who's actually able to configure the currency in the first place, which for most vertical SaaS platforms was the actual blocker, not the fee.

Why this mattered more for the accounts that needed it most

The accounts least likely to have Stripe Dashboard access are exactly the ones a vertical SaaS platform is built to serve — merchants who signed up for the platform's own product, not for a Stripe account, and who may not have a business bank account outside their home currency to begin with. Before this release, giving one of those merchants a EUR settlement currency meant the platform had to either get the merchant to open a EUR bank account somewhere, or build an entire embedded-finance detour just to park the balance. Most platforms did neither. They left the default conversion running, ate the complaints, and lost the occasional merchant to a competitor that handled it better — the same mechanism we described from the sub-merchant side in our piece on Stripe's account rejection codes: a platform's own customer leaving for a reason that never shows up on a churn dashboard labeled as churn.

That last row matters as much as the API access does. restricted_by_application means a platform can scope exactly which currencies it's willing to support, account by account, instead of an all-or-nothing switch. A platform serving merchants across the EEA, UK, Switzerland, Singapore, Hong Kong, Australia, and the US — the regions where multi-currency settlement is actually available — can enable EUR for its EEA merchants and GBP for its UK ones without opening every one of the up to 18 supported currencies to accounts that will never touch most of them.

The constraint that doesn't go away: region matching

None of this removes Stripe's region rule. An account must be in the same region as the platform to use multi-currency settlement at all — not the same country, but the same region, so an EEA-based platform can enable it for connected accounts anywhere in the EEA, and a US platform can enable it for US accounts. A platform operating across regions it doesn't itself have a presence in still can't extend this feature to those accounts, API or not. It's worth checking that constraint before promising a merchant in a new market that this fixes their FX problem, because in some cases it structurally can't.

What to actually do with this

• Pull settlement_currencies and default_settlement_currency for your existing connected accounts now. You'll likely find a meaningful share of international merchants sitting on auto-conversion by default, purely because nobody at your platform had a self-serve path to fix it before.
• Segment by whether an account's presentment currency matches its settlement currency. That gap is a reasonable proxy for who's paying conversion fees on money they probably don't need converted.
• Decide your currency policy before you flip settlement_currencies to enabled. Use restricted_by_application deliberately, matched to the regions and currencies your support and compliance teams actually want to handle, rather than opening all 18 and dealing with the edge cases later.
• Price the multi-currency settlement fee into your own take rate if you're on a buy-rate model, the same way you'd price any other pass-through cost, so the fix doesn't quietly compress your platform margin instead of the merchant's.

This is a narrower fix than Stripe's bigger currency plays — it doesn't touch what a subscriber sees at checkout, and it isn't the dynamic FX repricing we covered in Adaptive Pricing. It's specifically about what happens to money after a payment already succeeded, for a merchant who processes payments through your platform rather than a customer who pays into it. But for a vertical SaaS business, that merchant's retention is the actual revenue line, and losing one to a payout experience you could have fixed with an API call is a cancellation your own churn report will never correctly label. Run the math on what a lost connected account is worth using our churn calculator before deciding this is a "someday" ticket — and whether it's a merchant leaving your platform over FX friction or a subscriber leaving yours over a confusing cancel page, CancelFlow exists for the same reason this release does: the people who leave over a fixable problem rarely tell you that's why.

Frequently asked questions

Stop losing subscribers today

One script tag. One function call. A live cancellation flow in under 10 minutes.