Multi-currency payment processing: How it works and how to choose the right solution
Payments 101
Updated 7 Sept 2026
12 min
Andrii Kononenko
Head of Merchant Operations, Solidgate
Most businesses display local currency but still route cross-border. Here’s how to build a payment stack that actually converts international traffic.
You’ve localized your checkout. You’re showing euros to German customers, zloty to Polish ones, and pounds to UK shoppers. But your cross-border still lag behind domestic – often by double digits.
The dashboard says multi-currency, but your P&L tells a different story.
That gap exists because most businesses treat multi-currency as a front-end feature – show local prices, check the box, move on. But how does the transaction actually route? Which provider picks it up, and which local payment methods are available to international customers?
That’s infrastructure – and it’s where cross-border revenue is won or lost.
This guide covers how multi-currency payment processing actually works, what it costs, and what to look for when choosing a multi-currency payment solution. So you can evaluate your current setup against what international traffic actually demands.
TL;DR
- Multi-currency payment processing lets you accept payments in your customers' local currency while settling in your base currency.
- Multi-currency processing fees come in two layers: FX spread on any currency conversion, and cross-border fees – interchange and scheme fees – that apply when the acquirer and issuing bank are in different countries.
- Currency display without local acquiring delivers only a fraction of the expected conversion lift. The card network classifies a transaction as domestic or cross-border based on where the acquirer sits – not what currency the customer sees.
- A complete multi-currency payment solution needs four capabilities: checkout localization, local acquiring, APM coverage for markets where cards aren't the default, and consolidated reconciliation and settlement. Solidgate connects to 100+ providers, acquirers, and payment methods via one integration, with smart routing per transaction.
What is multi-currency payment processing?
Multi-currency payment processing lets you accept payments in your customers' local currency while settling funds in your own base currency. The customer sees a familiar price and you receive payments in the currency you operate in. The handles everything in between.
And that "everything in between" is where the complexity actually lives.
A multi-currency payment system involves three distinct layers working together:
Presentment currency – what the customer sees at checkout. This is the display layer: prices in euros, zloty, or pounds, detected from the customer's location or card BIN.
Routing and authorization – which provider handles the transaction and where. This determines whether the card network classifies the payment as domestic or cross-border, which directly affects approval rates and fee structure.
Settlement currency – what currency you receive, when, and at what conversion rate. This is the treasury layer: FX conversion happens somewhere in the settlement chain, and who controls it determines who takes the spread.
What is a multi-currency payment gateway?
A multi-currency payment gateway works like any payment gateway – it processes transactions, handles authorization, and connects your checkout to the payment network.
The difference is settlement flexibility.
A standard gateway force-converts every transaction to your base currency on settlement. A UK business accepting a payment in USD receives GBP – converted at the gateway's rate, with the spread embedded and invisible. A multi-currency gateway removes that step: you accept USD and settle in USD, without a forced conversion on every transaction.
The term is used loosely in the market, which matters when you're evaluating options. Some platforms can call themselves multi-currency gateways because they accept payments in many currencies – but still force-convert everything to your base currency on the backend. A genuine multi-currency gateway lets you settle in your key operating currencies.
For most digital businesses, the gateway alone isn't the decision. The decision is which multi-currency payment platform it sits within – because the gateway's performance depends on what provider network, APM coverage, and settlement infrastructure surrounds it. Multi-currency payment solutions that bundle all of these under one integration can give you more control over routing, cost, and reconciliation.
How multi-currency payment processing works, step by step
A multi-currency card transaction moves through five steps between the customer clicking "pay" and funds landing in your account.
1. Presentment. The customer's browser or app detects their location via IP or card BIN and displays the price in their local currency. The amount is denominated in the presentment currency for the transaction.
2. Authorization. Your payment infrastructure routes the transaction to an acquirer. The acquirer sends an authorization request to the card network (Visa or Mastercard), which forwards it to the customer's issuing bank. The issuer approves or declines based on the card status, fraud signals, and – critically – whether it recognizes the acquirer as local or foreign.
3. Capture. Once authorized, the transaction is captured. For most card-not-present transactions, authorization and capture happen in the same request.
4. Clearing. The card network settles the transaction between the acquirer and the issuing bank. This is where cross-border fees are assessed – if the acquirer and issuer are in different countries, the network applies its cross-border fee schedule.
5. Settlement. Your provider pays out funds to your merchant account, typically in your base currency. If presentment and settlement currencies differ, FX conversion happens here – either by the provider at their rate, or held in local currency if your platform supports multi-currency settlement accounts.
Core insight: A multi-currency transaction moves through five steps – presentment, authorization, capture, clearing, and settlement – and the acquirer chosen at step two determines the fees and approval rate across all of them.
Multi-currency vs. cross-border payments: What's the difference and why it matters
These terms get used interchangeably, but they're not the same thing.
Multi-currency payments involve a transaction processed in a currency different from the merchant's base currency. Geography is irrelevant – a US-headquartered business accepting euros from a German customer is doing multi-currency processing, regardless of where their provider sits.
Cross-border payments involve a transaction where the buyer and merchant are in different countries. Currency may or may not differ – a UK buyer paying a UK-registered merchant in GBP is still classified as cross-border by the card network if their payment provider routes the transaction through an overseas acquirer.
| Multi-currency payments | Cross-border payments | |
| What it means | Transaction in a currency other than the merchant's base currency | Transaction where buyer and merchant are in different countries |
| Geography | Can be within one country | Always involves two or more countries |
| Currency | Always involves at least two currencies | May be single-currency |
| Primary cost | FX spread on settlement | Interchange + scheme fees + higher decline rates |
Core insight: Most cross-border transactions are also multi-currency. Most multi-currency setups exist to serve cross-border customers. In practice, you're usually solving for both at once.
What multi-currency payment processing actually costs
Multi-currency processing has two cost layers. One applies any time currencies differ. The other applies specifically when the routing is cross-border.
FX spread is the core multi-currency cost – present on every transaction where your settlement currency differs from the presentment currency.
When your provider converts euros collected from a German customer into USD for your US account, they apply a conversion rate. The gap between that rate and the mid-market rate is the spread. It isn't shown as a line item – it's embedded in the exchange rate itself, which makes it easy to miss on a statement.
The size depends on who controls the conversion and when it happens in the settlement chain. Platforms that support multi-currency settlement accounts let you hold balances in collected currencies and convert on your own schedule, which gives you control over when and at what rate conversion happens.
Cross-border fees apply when the underlying acquirer and the cardholder's issuing bank are in different countries.
Two components stack on every cross-border transaction:
- – set by and , paid to the issuing bank. For card-not-present transactions in the EEA where the issuer is outside the EEA, interchange runs 1.15%–1.50% depending on card type. The equivalent intra-EEA rate for the same card type is 0.20%–0.30%.
- Scheme fees – charged by the card network on top of interchange for processing cross-border transactions. The exact rate varies by network and transaction type, but cross-border scheme fees typically range from 0.6% to 1.4% per transaction.
Both components exist regardless of your pricing model. Under blended pricing, they're folded into a single flat rate – which means merchants don't see how much cross-border routing is actually costing them. Under pricing, they appear as separate line items in the settlement file, making the cross-border premium visible and attributable.
Core insight: The visible cost of multi-currency processing is the FX spread. The larger cost – interchange and scheme fees on every cross-border transaction – is invisible until you look at where the acquirer sits relative to your customers.
Why showing local currency isn't enough to convert international traffic
Here's what happens when you display local currency but don't change the routing underneath.
A German customer sees a price in euros, enters their card details, and the transaction routes through your US-based provider. From the card network's perspective, that's still a cross-border payment. Two things follow immediately:
The card network applies cross-border interchange and scheme fees. You're paying 1.5%–2.5% more per transaction than you would if it routed domestically – before you count the FX spread on settlement.
Local issuers are more likely to soft-decline a transaction from a foreign acquirer, especially for new customers or higher-value purchases. When that happens, the customer sees a failed payment. They may retry once, but more often they just leave.
Adding local currency display without local acquiring typically delivers only a fraction of the expected conversion lift. The front end looks right, but the back end hasn't caught up. The are a back-end problem – and they don't show up in your localization metrics.
Fixing this requires work across four layers: checkout localization, , alternative payment method (APM) coverage, and the operational infrastructure that holds everything together.
Core insight: Currency display changes what the customer sees. It doesn't change what the card network sees – and the card network's classification is what determines your fees and your approval rate.
What to look for in a multi-currency payment solution
Evaluating multi-currency payment options comes down to four capabilities.
Checkout localization
Currency display is the baseline. What matters is how your checkout determines what to show.
Three signals drive localization:
- IP geolocation
- Browser language
- Card BIN, once entered
A strong checkout cross-references all three to handle edge cases, e.g., a UK cardholder browsing from a German IP.
Language matters as much as currency. A Dutch customer sees prices in euros, but a checkout form in English still hits a snag. The best setups auto-adjust both in the same pass.
Speed matters too. A checkout page that takes three seconds to load will lose customers before they even see your localized prices. Pre-populating fields from previous purchases compounds the effect – less typing means less time to reconsider.
How this looks in practice: a German customer hits your checkout. The page loads in under a second via CDN, detects their location, and renders in German with pricing in euros. Input fields are pre-populated from their last purchase. They confirm and pay in eight seconds.
That same checkout, visited by a Dutch customer, renders in Dutch with euro pricing. No redirect, no separate checkout flow, no dev work per market.
For that to be your case, you need a platform that auto-adjusts currency, language, and payment methods based on location. That's how Solidgate's works, and it's what we'd recommend looking for in any multi-currency setup.
Local acquiring
This is the layer most guides skip entirely. It’s also the one with the biggest impact on your economics.
When a transaction routes through a local acquirer – one domiciled in the same country as the cardholder’s issuing bank – the card network classifies it as a domestic transaction. Three things change at once:
- Interchange rates drop: Cross-border transactions in Europe typically cost 30–50 basis points more than domestic ones once you factor in interchange differentials, scheme fees, and cross-border surcharges. On €1M in monthly volume, that’s €3,000-€5,000/month in unnecessary cost – before you count declined transactions.
- Authorization rates climb: Local issuers trust local acquirers. They’re less likely to soft-decline a transaction that comes from a domestic source.
- Cross-border fees disappear: The surcharge that card networks apply to cross-border transactions goes away when both the acquirer and issuer sit in the same market.
Here’s the connection many teams miss: you can’t do local acquiring without multi-currency processing. If you’re settling everything in USD, you can’t route through a European acquirer.
Merchants on our platform who’ve moved from cross-border-only to local acquiring in key European markets have seen double-digit improvements in acceptance rates. That’s not a display change. It’s an infrastructure change.
→ Read the full
The math is straightforward: higher auth rates mean more revenue per checkout session. Lower interchange means more margin on every transaction that does go through. Local acquiring turns multi-currency from a cost center into a profit lever.
This is how we've built – 100+ global and local providers and acquirers, with logic that picks the best one per transaction based on geography, cost, and historical performance.
See how a travel platform and localized payments to make cross-border travel bookings more accessible.
Alternative payment methods coverage
In key European markets, cards aren’t always the default.
in cross-border checkout averages near 70%, according to . Missing the local “hero” payment method is a big part of why.
In the Netherlands, iDEAL handles the majority of online payments. In Poland, BLIK is the dominant mobile method – customers pay with a six-digit code in seconds. Across Sweden, Germany and Austria, Klarna carries a heavy share.
If your checkout doesn’t surface these options, you’re asking customers to use their second-choice method.
The challenge with APMs is surfacing the right ones. A checkout that shows every available method to every customer creates clutter and confusion. The better approach is to detect the customer’s location, surface the two or three most relevant options, and keep the experience clean.
How this looks in practice: a subscription or e-commerce business selling across the Netherlands, Poland, and Germany manages multi-currency payment options from a single checkout. The Dutch customer sees euros and iDEAL. The Polish customer sees zloty and BLIK. The German customer sees euros and Klarna. Same checkout page, three localized experiences – zero additional dev work.
Note: not every APM supports subscriptions. iDEAL works for through SEPA mandates, while supports recurring payments natively. But some methods are one-time only.
Your payment stack needs to know which methods support card-on-file or mandate-based billing – and filter accordingly, so your checkout never offers a method that works for the first payment but fails on the second.
Look for a platform that surfaces dynamically based on customer location.
Reconciliation, failover, and settlement
Accepting payments in multiple currencies across multiple providers creates an operations problem that doesn't show up until your finance team tries to close the books.
Each provider has its own settlement timeline, reporting format, and currency denomination. Without centralized reporting, reconciliation means manually matching data across three or four dashboards every month.
Failover matters here, too. If a transaction fails on one provider, can your system retry on another – in the same currency, using the same token? Most single-PSP setups can’t. can, but only if tokenization is provider-agnostic. It means the card is stored once and can be charged through any connected provider without re-tokenization.
Payment cascading – automatically rerouting failed transactions to a backup provider – recovers a meaningful share of otherwise-lost revenue. On our platform, we’ve seen recovery rates in the low-to-mid teens as a percentage of initial declines.
add another layer. Instead of retrying immediately on the same provider (which usually fails again), the system waits for the right window based on issuer behavior and time zone, then retries through the most likely path to approval.
For subscription businesses, this is the difference between involuntary churn and a recovered customer.
Then there’re settlement questions:
- Do you convert everything to a single base currency at the day’s exchange rate and absorb the FX spread?
- Or hold local currency balances in different currencies and convert when timing favors your treasury?
Most platforms force one approach.
The better option: hold balances in the currencies you collect, and convert when timing works for your treasury. support EUR, USD, and GBP with unique IBANs, SEPA Instant, and SWIFT – but the broader point is that your payment platform and your treasury shouldn't be separate systems.
For teams managing multi-currency payment processing programmatically, a platform with a full-coverage API – routing decisions, settlement data, and reconciliation reporting in one place – removes the manual ops layer entirely.
Core insight: A multi-currency payment solution needs four capabilities working together – checkout localization, local acquiring, APM coverage, and consolidated ops. A platform that covers only some leaves the gaps that cost you in authorization rates, conversion, and margin.
Your checkout shows local currency – does your stack back it up?
Multi-currency payment processing is a stack-level decision, and currency display is where it starts. Local acquiring, APM routing, failover logic, subscription handling, and centralized reconciliation are what make it actually work.
If you're expanding into new markets, audit your current stack against these four layers:
- Where does your checkout localize?
- Where does the transaction actually route?
- What methods are you missing?
- And who's reconciling all of it?
The answers will tell you whether your multi-currency setup is working, or just looking like it is.
If you're building that stack or rethinking an existing one, to map your current setup and identify where the gaps are.
From zero to 15+ markets – and still expanding
How Nova Post scaled payments across Europe and the US with 95%+ approval rates
Frequently asked questions
Multi-currency payment processing lets businesses accept payments in a customer's preferred currency while settling funds in their own base currency. The payment infrastructure handles currency conversion, routing, and settlement behind the scenes. It covers three layers: what the customer sees at checkout (presentment currency), how the transaction routes and which acquirer handles it, and what currency you receive and at what rate (settlement).
To set up multi-currency payment processing, start with checkout localization – currency, language, and payment methods detected per customer location. Then address routing: local acquiring in your key markets eliminates cross-border interchange and scheme fees, and raises authorization rates.
Add APM coverage for markets where cards aren't the primary method. Finally, set up centralized reconciliation so settlement across multiple providers and currencies doesn't become a manual finance problem.
Local acquiring routes the transaction through an acquirer within the same region as the cardholder's issuing bank. The card network classifies it as an intra-EEA transaction rather than cross-border – which eliminates the cross-border scheme fee and drops interchange. Local issuers are also less likely to soft-decline transactions from regional acquirers, which directly lifts authorization rates.
It all depends on your market footprint and authorization rate targets. A single provider works if you're operating in one or two markets where that provider has strong local acquiring, the right APM coverage, and acceptable authorization rates.
Orchestration becomes necessary when no single provider covers the acquiring relationships you need across all your markets – or when you're losing revenue to declines that a different acquirer in the same market would approve.
Cross-border card transactions carry three cost layers. Interchange runs higher than domestic – 1.15%–1.50% for in the EEA vs. 0.20%–0.30% for intra-EEA routing (Visa and Mastercard). Scheme fees add another 0.6%–1.4% depending on the network.
FX spread is embedded in the settlement rate rather than shown as a line item – and can increase further if dynamic currency conversion (DCC) is enabled at checkout. Local acquiring eliminates the interchange differential and scheme fees; multi-currency settlement accounts give you control over FX timing.
Not necessarily. A multi-currency lets you hold and settle in multiple currencies, but modern payment solutions like orchestration platforms can handle international payments without requiring separate merchant accounts in each market.
They route transactions through local acquirers and process payments in the customer’s local currency while settling to your preferred base currency –or holding balances in local currency through business accounts. The right approach depends on your volume, markets, and treasury needs.
Exchange rate fluctuations can erode margins between the time a customer pays and the time you convert funds to your base currency. For subscription businesses billing monthly in local currency payments, this risk compounds over each billing cycle.
The two main approaches are: convert immediately at settlement and accept the rate you get, or hold balances in multiple currencies and convert strategically when rates favor your position. Platforms with built-in treasury tools give you the flexibility to choose.
The cost depends on how your routing is configured. The base layer is FX spread on any currency conversion. Cross-border routing adds interchange (up to 1.15%–1.50% for card-not-present in the EEA) and scheme fees (typically 0.6%–1.4% depending on the network).
Yes – but with some considerations. The point is that not every payment method supports recurring billing. iDEAL works for subscriptions via SEPA mandates; BLIK supports recurring payments natively. Some methods are one-time only and will fail on the second charge if your checkout doesn't filter them out. Cross-border renewals also carry higher decline rates than domestic ones – which means smart retries and local acquiring directly affect auth rates and involuntary churn.
