Paying Merchants in SEK, PLN and CZK Instead of Euros
The short answer
A marketplace that pays every seller in euros forces a Stockholm, Warsaw or Prague seller through a retail FX conversion on their statement — a spread they can see, and a reason to question the platform. Paying in SEK, PLN and CZK natively removes that spread and keeps the seller's margin (and loyalty) on the platform.
What one currency for a continent costs
When payouts settle in EUR, the seller's bank does the final leg: EUR → their local currency, at a retail rate, with a fee. The marketplace never sees that cost — the seller does, on the statement, every cycle. Multiply by thousands of sellers and it's a quiet tax on the whole network.
| Settle in EUR | Settle natively | |
|---|---|---|
| Seller receives | EUR, converts at retail | SEK / PLN / CZK directly |
| FX spread | Taken by seller's bank | Kept on platform or quoted |
| Seller experience | "Why am I losing on FX?" | "Paid in my currency" |
Why marketplaces default to EUR
Because adding a payout currency used to mean a banking relationship and a local entity per market. So the platform picks one and pushes the conversion downstream. Understandable when rails were expensive — less so when a layer gives you 35 currencies from one integration.
The seller doesn't care about your banking relationships. They care that the number on their statement is right.
What changes when you settle natively
Sub-account per seller, payout in their own currency, one record across all of them. The FX you'd have handed to the seller's bank becomes a quoted rate you control — or a spread you capture. Either way, the seller stops eating a conversion they didn't choose.
The bottom line
Paying in the seller's currency is cheaper to build than it used to be and more sticky than it looks. The EUR default is a legacy of expensive rails, not a constraint anymore.
We'll tell you honestly whether we can move it — including when the answer is no.
Get a demo