FX and Cross-Border Settlement Architecture: Where Conversion Actually Happens

Ask an operator where their FX cost comes from and most can quote a markup percentage. Ask where in the transaction chain that conversion actually happened, and fewer can answer. The two questions are not the same, and the gap between them is where money leaks without a name attached to it.

A single cross-border card transaction can be converted at up to four separate points between the moment a customer taps their card and the moment cash lands in the merchant's operating account — issuer, scheme, acquirer, and merchant treasury — and each point has a different owner, a different visibility, and a different cost. FX markup is the economics of the one point merchants actually pay for and can negotiate. Multi-currency treasury is the architecture for what happens to money after it lands. This piece is the connective layer between them: the currency-role stack that gets conflated, the four conversion points and who bears the spread at each, and what settlement timing, refunds, and chargebacks do to a transaction that has already been converted once.

The Currency-Role Stack: Same Chain, Different Vocabulary

A cross-border transaction moves through a chain of currency roles, and the confusion operators run into is less about the concept and more about the fact that PSPs don't use the same words for the same points in the chain.

Transaction currency is the currency the card scheme records the purchase in for interchange, scheme-fee, and cross-border assessment purposes. It's set by how the merchant's pricing and checkout are configured, not by the cardholder's card.

Presentment currency is Stripe's own term for the currency the customer is actually charged at checkout — Stripe's documentation defines it precisely as "the currency of the charge." This is the currency the cardholder authorizes and the amount that appears on their statement (before their own issuer applies any conversion on their end).

Processing currency is the term Adyen's platform documentation uses for what is, in a standard two-party merchant-acquirer relationship, the same conceptual point: "the currency in which the customer pays." In a straightforward checkout, processing currency and presentment currency are the same hop described by two different vendors. Where they can genuinely diverge is in platform, marketplace, or multi-acquirer architectures, where the currency a PSP's acquiring rail clears a transaction in isn't guaranteed to be identical to what the customer saw at checkout — which is exactly the scenario Adyen's platform documentation is written for.

Settlement currency is a term every major PSP uses consistently: the currency that actually lands in the merchant's bank account. Stripe defines it as "the currency accepted by your destination bank account or debit card." If the transaction/presentment currency differs from settlement currency, a conversion happens somewhere before the money reaches the merchant — the question this whole article is about is where.

Merchant functional (base) currency is the one role on this list that isn't a payments-scheme concept at all — it's an accounting concept. It's the currency a merchant's books, P&L, and financial reporting are denominated in. A merchant can hold settlement accounts in five currencies and still report a single functional currency to its board and auditors. Settlement currency and functional currency are routinely the same for a single-currency operator and routinely different for one running multi-currency settlement — which is precisely the operational decision the treasury layer exists to manage.

The practical takeaway: when you read a PSP's documentation and it uses "presentment" where another PSP's documentation uses "processing," they are very likely describing the same point in the chain, not a genuinely separate fifth layer. The two junctures that are always operationally distinct, regardless of vendor vocabulary, are settlement currency (what the PSP pays out) and functional currency (what the merchant's finance team reports in). Conflating those two — assuming that because you're being settled in USD your accounting exposure ends at USD — is the conflation that actually costs money, because it hides the conversion your own treasury still owes once the PSP's job is done.

Where Conversion Actually Happens: Four Points, Four Owners

Given that chain, currency conversion itself can happen at up to four distinct points, and they are not interchangeable — each has a different owner bearing the spread.

Issuer FX. If nobody else converts the transaction, the cardholder's own issuing bank converts it at settlement, using the card network's daily wholesale rate. Visa publishes daily FX rates across 180-plus currencies that VisaNet uses to authorize and settle transactions — this is the rate an issuer conversion is built on, before the issuer layers its own foreign-transaction fee on top. This point is entirely cardholder-borne. It does not touch merchant economics at all, and it's worth naming explicitly because it's the default outcome whenever a merchant's checkout does nothing special — no multi-currency pricing, no DCC, just a domestic-currency price charged to a foreign card.

Scheme conversion. Whenever the acquirer and the issuer settle a transaction in different currencies — which happens on cross-border transactions independent of what currency the merchant priced in — Visa or Mastercard perform their own wholesale conversion between the two banks, using the same daily rate infrastructure referenced above. This is a bank-to-bank settlement mechanic, not a line item a merchant negotiates or even typically sees. Its cost is embedded in the interchange and cross-border assessment economics between the schemes and the banks, not exposed as a separate merchant-facing FX spread. Operators frequently assume "scheme fees" and "FX markup" are the same cost category because both involve currency crossing a border somewhere in the chain — they aren't, and the next section is specifically about untangling that.

Acquirer/PSP conversion. This is the point that actually shows up in merchant economics. If a merchant hasn't configured multi-currency settlement, the PSP converts every transaction to the merchant's settlement currency at the point of transaction — Stripe's own documentation states this plainly: before incoming currencies settle to a merchant's account, Stripe "automatically converts them into the default currency of your home country" unless additional settlement currencies are explicitly enabled. The rate applied here embeds a spread, typically 1.5-3.0% above mid-market on unnegotiated PSP terms, and this spread is the entire subject of FX markup economics — where it comes from, how to measure it, and how to negotiate it down. The merchant bears it, on every transaction, whether or not it's visible on the statement.

Merchant treasury conversion. If a merchant instead configures multi-currency settlement — receiving EUR, GBP, and USD balances directly rather than everything auto-converting at transaction time — conversion moves downstream, to whenever the merchant's own treasury function chooses to convert accumulated balances into functional currency. The merchant bears this cost too, but on its own schedule, at rates it can shop across banks and specialist platforms rather than accepting whatever the PSP applies per-transaction. This is where treasury architecture takes over, and the full decision framework — when to convert, when to hold, when to hedge — is covered in the multi-currency treasury piece linked below rather than repeated here.

The operator-relevant pattern: only two of these four points are merchant-borne (acquirer/PSP conversion and merchant treasury conversion), and only one of those two is a cost the merchant actively controls the timing of. Issuer FX and scheme conversion happen regardless of anything the merchant does, and neither is a lever the merchant pulls.

Multi-Currency Settlement vs Like-for-Like vs Single-Currency Settlement

These three settlement architectures get used interchangeably in conversation and describe genuinely different things.

Single-currency settlement is the default: every transaction, regardless of the currency it was priced or charged in, converts to one settlement currency before it reaches the merchant. This is what happens automatically unless a merchant deliberately configures otherwise — Stripe's documentation is explicit that incoming currencies convert to the account's default currency by default. One conversion point, one settlement feed, one reconciliation format. It is also the architecture where the acquirer/PSP conversion spread above applies to the full volume of cross-currency transactions, with no exception.

Multi-currency settlement means the PSP settles transactions in more than one currency to the merchant, rather than forcing everything through a single conversion. Adyen's documentation describes this directly: merchants can configure multiple payout currencies per merchant account, each requiring its own payout account, with any transaction currency lacking a configured payout account falling back to auto-conversion into the primary settlement currency. This is the architecture that unlocks the treasury-side FX savings — bulk conversion at 0.05-0.30% above mid-market rather than 1.5-3.0% at the transaction level — but it's not automatically like-for-like on every currency; it depends on which payout currencies the merchant has actually configured.

Like-for-like settlement is the specific case, inside multi-currency settlement, where the settlement currency for a given transaction is literally the same currency the transaction was made in — a merchant selling in EUR and being paid in EUR, no conversion at all for that flow. Both Adyen and Checkout.com use this exact term, and Adyen's documentation is precise about the condition: like-for-like settlement is available for a given currency only where that currency is also configured as a payout currency for the merchant account. A merchant can run multi-currency settlement broadly while still not achieving like-for-like on every currency it accepts, if the payout account for a specific currency hasn't been set up — the gap between "we do multi-currency settlement" and "we're actually settling like-for-like on our top corridors" is exactly the kind of assumption worth verifying against the PSP configuration directly rather than the sales description.

The practical sequencing for most operators: single-currency settlement is correct until cross-currency volume in a specific corridor is material enough to justify a second settlement account, at which point multi-currency settlement targeting like-for-like on the highest-volume corridors captures most of the available saving without requiring like-for-like coverage on every currency accepted.

Cross-Border Assessment Fees vs FX Cost: Two Different Triggers

These two cost categories get conflated constantly because both involve money crossing a border somewhere in the chain, and the conflation is expensive because it hides which lever actually moves which line item.

A cross-border scheme assessment fee is triggered when the issuer's country differs from the acquirer's country — full stop, regardless of what currency the transaction settles in. Visa's International Service Assessment applies whenever a merchant accepts a card issued in a different country from its acquiring bank, running roughly 1.0-1.4% for US-acquired transactions depending on settlement currency, plus a separate International Acquirer Fee of 0.45% (0.9% for certain higher-risk categories). Mastercard's equivalent cross-border assessment runs 0.6% on transactions settled in US dollars, rising to 1.0% when settled in another currency. A Canadian cardholder buying a USD-priced item from a US-acquired, USD-settling merchant still triggers this fee — no currency conversion happens anywhere in that transaction, and the fee still applies, because the trigger is issuer country versus acquirer country, not currency.

FX markup, by contrast, is triggered when the transaction currency differs from the settlement currency — regardless of issuer or acquirer country. A domestic cardholder in a single-currency market paying for an item priced in a foreign currency (a common pattern for digital goods, subscriptions, or marketplace listings) can trigger FX markup with zero cross-border assessment fee, because issuer and acquirer are in the same country the whole time.

The two triggers are orthogonal, which means all four combinations are real and show up on real processing statements: domestic issuer, domestic currency (neither fee applies); domestic issuer, foreign currency (FX markup only); foreign issuer, domestic currency (cross-border assessment only); foreign issuer, foreign currency (both apply, and they compound). The MDR stack breaks down where each of these sits in a full processing statement, layer by layer, alongside interchange and acquirer margin — worth reading in full if the goal is decomposing an actual statement rather than understanding the mechanism. The operational consequence of keeping the two separate: cross-border assessment is a network-set fee, effectively non-negotiable below very high scale, while FX markup is PSP margin, negotiable well before that scale is reached and the subject of a dedicated negotiation playbook in the FX markup piece linked above.

DCC: A Different Chain Entirely

Dynamic Currency Conversion doesn't sit inside the four-point conversion chain described above — it replaces it, at the point of checkout, before the transaction currency the merchant's own settlement economics operate on is even fixed. When a merchant or ATM offers DCC and the cardholder accepts, the conversion happens immediately, using the DCC provider's own rate rather than the scheme's or the issuer's, and the transaction subsequently flows through the merchant's normal settlement chain already converted, denominated in the cardholder's home currency rather than the merchant's.

Visa's own consumer disclosure rules are explicit about the structural requirement: DCC must be presented as a genuine choice, with the exchange rate and any additional fees or markup clearly displayed, and the cardholder must be able to decline it without any impact on completing the purchase. That structural framing is the important operator takeaway here — DCC is a separate transaction-currency decision made at the moment of sale, not a variant of the merchant's own settlement-currency conversion economics. Because DCC sits outside the merchant's normal FX chain, it also sits outside the merchant's normal FX negotiation: the rate, the markup, and who captures it are set by the DCC provider relationship, not by the PSP contract governing everything else in this article. The full economics of DCC rebates, provider markup ranges, and the reputational case against merchant-initiated DCC are covered in the FX markup piece linked throughout this article; this section exists only to place DCC correctly in the architecture — as a fork before the chain starts, not a fifth conversion point inside it.

Settlement Timing and Rate Locking

A question operators underweight: when, exactly, is the rate struck relative to when funds actually land? The answer is not "at the moment of purchase" in most architectures, and the gap matters more as settlement cycles lengthen.

At the scheme level, Visa applies its daily rate — one of 180-plus currency pairs updated once per business day — based on the date VisaNet processes the transaction, which is not necessarily the date of purchase. A transaction authorized on a Friday evening in a market where the merchant doesn't batch and submit until Monday can pick up Monday's rate rather than Friday's, particularly across a weekend or a public holiday when rates don't update. This is a scheme-level mechanic that predates and sits underneath whatever the PSP does on top of it.

At the PSP level, the acquirer/PSP conversion described earlier is generally applied at the point the PSP processes the transaction into the merchant's settlement currency — which for most PSPs means at or near the time of capture, not necessarily authorization, and the exact timing is architecture-specific per provider. The rate is not locked at the moment the customer completes checkout in most default configurations; it is locked whenever the PSP's own conversion step executes against that transaction. For operators running high-value cross-currency transactions where even a few hours of rate movement is material, this is worth confirming directly against the specific PSP's settlement mechanics rather than assuming a uniform standard — the "rate locked at checkout" experience some merchants offer customers (Stripe's Adaptive Pricing and comparable localized-pricing products) is a feature the PSP has to explicitly build and price for, not a default behavior of underlying card-network conversion.

The operational implication either way: because the rate is struck at processing time rather than purchase time, and because processing time can trail purchase time by hours to days depending on batching and settlement cadence, the effective FX rate applied to any given transaction carries a timing component that neither the merchant nor the customer directly controls, on top of whatever spread the PSP or scheme applies. This is a source of small, unavoidable variance separate from the negotiable markup — worth distinguishing when reconciling why two seemingly identical cross-currency transactions on the same day settled at slightly different effective rates.

Refunds After FX Movement: What the Merchant Eats

A refund on a cross-currency transaction is not simply "give the money back." It's a second conversion, struck at a second point in time, and the two conversions do not have to agree.

Stripe's own documentation states the mechanic directly and without ambiguity: if a currency-converted payment is refunded, the amount deducted from the merchant's balance is converted back to the presentment currency at the exchange rate current at the time of the refund — not the rate that applied at the time of the original sale. Stripe's worked example makes the exposure concrete: a 60 USD payment converted at 0.88 EUR per USD settles as 52.80 EUR to a merchant with a EUR settlement currency; if the rate has moved to 0.86 EUR per USD by the time that payment is refunded, only 51.60 EUR is deducted from the merchant's balance to fund a refund of the same 60 USD. The customer is refunded their exact original amount, in the currency they originally paid — the entire variance, in either direction, lands on the merchant's settlement-currency balance.

Two things follow from this mechanic that operators should build into their own FX accounting rather than discover during a reconciliation exercise. First, the variance can run either way — a merchant can come out ahead on a refund if the rate has moved in its favor since the original sale, exactly as easily as it can come out behind. This isn't a hidden fee extracted by the PSP; it's a genuine market-rate exposure the merchant is carrying, unhedged, on every cross-currency transaction between the moment it's charged and the moment it might be refunded. Second, the size of the exposure scales with two things a finance team can actually measure: the refund rate on cross-currency volume, and the average time-to-refund. A subscription or marketplace business with a high cross-currency refund rate, or one operating in a period of elevated currency volatility, is carrying materially more of this exposure than a low-refund-rate business selling a single high-value item — and because it never appears as a labeled fee anywhere on a statement, it is one of the more commonly untracked components of cross-border FX cost, sitting adjacent to but distinct from the markup the FX markup itself covers.

Chargebacks and Exchange-Rate Effects

Chargebacks compound the refund mechanic with a longer and less predictable timeline. A refund is initiated by the merchant and typically processed within days; a chargeback is initiated by the cardholder's issuer, and the gap between the original transaction date and the date the chargeback is actually debited from the merchant's account can run weeks to months, depending on the scheme's dispute timeline and how far the case progresses before resolution.

The same reconversion mechanic that applies to refunds applies to chargebacks — the disputed amount is converted at the rate in effect when the chargeback is processed against the merchant, not the rate that applied when the original sale settled. Because the elapsed time between sale and chargeback is typically much longer than the elapsed time between sale and refund, the currency-movement window is correspondingly larger, and so is the potential variance on any given case. A merchant with a meaningfully cross-currency chargeback rate is carrying a larger and more volatile version of the same unhedged exposure described in the refund section above, compounded by chargeback fees themselves, which are typically charged flat, in the merchant's settlement currency, regardless of the disputed transaction's original currency or the FX variance on the reversed amount. None of this changes chargeback prevention or representment strategy — it's a reason to include FX variance as a line item when calculating the true cost of a chargeback in a cross-currency corridor, rather than assuming the disputed amount plus the flat chargeback fee is the full cost.

Reconciliation Implications of Multi-Currency Settlement

Every settlement architecture choice above has a reconciliation cost that scales differently, and it's worth pricing explicitly before choosing.

Single-currency settlement produces the simplest reconciliation: one settlement currency, one conversion point, one rate to explain any given day's variance against. The cost is entirely on the FX-spread side, not the operational side.

Multi-currency and like-for-like settlement invert that tradeoff. Each additional settlement currency is an additional payout account, an additional line in the settlement report, and — critically — an additional currency in which the finance team now needs to track its own FX exposure against functional currency, separate from whatever the PSP already converted. A merchant settling in five currencies against a single functional currency has effectively taken on five parallel FX positions that didn't exist under single-currency settlement, each moving independently, each needing its own conversion decision on its own schedule. This is exactly the treasury workload the multi-currency treasury piece linked above and below covers in full — the point worth making here is that it is a direct consequence of the settlement-architecture choice, not a separate problem that appears later. Choosing multi-currency settlement without a treasury process to manage the resulting balances just relocates the FX exposure from the PSP's spread to the merchant's own unmanaged currency drift, which is very often a worse outcome, not a better one.

The refund and chargeback reconversion mechanics described above add a further wrinkle specific to multi-currency settlement: because refunds and chargebacks reconvert at a different rate than the original sale, a three-way reconciliation match — internal ledger, PSP settlement report, and bank statement — now has to account for FX variance as its own reconciling item on every affected transaction, not just track amounts. On single-currency settlement this variance is buried inside the PSP's overall spread and rarely itemized separately; on multi-currency settlement with several active payout currencies, the variance shows up as small, currency-specific discrepancies that a reconciliation process built for single-currency operations will not automatically explain. Budget for this specifically rather than discovering it the first month multi-currency settlement is live.

Local Acquiring vs Cross-Border Acquiring: Where FX Sits in Each

Local acquiring changes where in this chain conversion happens without eliminating the need for conversion altogether — a distinction worth being precise about, because "go local to avoid FX" is an oversimplification that undersells what local acquiring actually does.

Under cross-border acquiring — a single acquirer outside the customer's market handling the transaction — the acquirer/PSP conversion point described earlier applies in full: the transaction converts to the merchant's settlement currency at the point of transaction, at whatever spread the PSP applies, and the merchant typically also picks up the cross-border scheme assessment fee described above, since acquirer and issuer sit in different countries by construction.

Under local acquiring, the transaction is acquired by an entity licensed in the customer's market and settles in that market's local currency — which avoids the cross-border scheme assessment fee (issuer and acquirer are now in the same country) but does not, by itself, avoid FX conversion. It moves the conversion decision downstream: instead of the PSP converting at the point of transaction, the merchant now holds or converts that local currency itself, on its own schedule, through whatever treasury process it has in place. This is structurally the same shift described in the "merchant treasury conversion" section above — local acquiring is one of the paths that gets a merchant there, not a distinct fifth mechanism. The FX cost doesn't disappear; it moves from an embedded per-transaction PSP spread to a bulk conversion the merchant controls the timing and provider of, which is very often cheaper, but only if the merchant actually has a treasury process ready to receive and convert the resulting local-currency balances rather than letting them sit unconverted and exposed.

When Centralised Conversion Becomes Operationally Expensive

Single-currency settlement — one PSP conversion point, everything centralized to one functional currency — is the right default for most operators, and it stays right longer than the FX-spread math alone suggests, because the operational simplicity has real value that a pure cost comparison misses.

It stops being right, specifically, in three situations. First, when the embedded PSP spread on a specific high-volume cross-currency corridor is clearly larger than the incremental reconciliation and treasury overhead of adding one settlement currency for that corridor — this is a corridor-by-corridor decision, not an all-or-nothing switch, and the highest-volume corridor is almost always where the case is strongest first. Second, when refund and chargeback volume in cross-currency corridors is high enough that the reconversion variance described above becomes a reconciliation burden in its own right, independent of the headline FX spread — at that point, a merchant is paying twice: once in embedded markup, and again in the unmanaged variance on every reversal. Third, when treasury has reached enough scale — in practice, once cross-currency volume clears the threshold where a specialist treasury platform or bank FX desk's bulk-conversion pricing beats the PSP's per-transaction rate by a wide enough margin to justify the operational build, covered in full in the treasury architecture piece linked throughout this article.

Below all three thresholds, the honest recommendation is to stay centralized. Multi-currency settlement without a treasury process behind it, or added prematurely to chase a spread saving that doesn't yet outweigh the reconciliation cost, is a common and avoidable mistake — it trades a known, bounded PSP cost for an unbounded and frequently unmanaged currency exposure. The architecture question this piece has walked through — where conversion happens, who bears it, and what refunds and chargebacks do to it after the fact — is the diagnostic that should precede the decision to decentralize, not follow it.

What to Read Next

The two pieces this article sits between:

FX Markup Economics: How Cross-Currency Acceptance Quietly Eats Margin — the negotiation depth on the acquirer/PSP conversion point covered here: measuring your spread, DCC economics in full, and the negotiation paths by volume.

Multi-Currency Treasury Architecture for Payment Operators — the decision framework for what happens after settlement: where to hold balances, when to convert, when to hedge, and where virtual IBANs and specialist platforms fit.

Adjacent statement and acquiring mechanics:

The MDR Stack: Reading Your Processing Statement Line by Line — where scheme fees and FX markup sit among the other layers of the processing statement, and how to decompose your own.

Local Acquiring vs Cross-Border Acquiring: The Operator Reference — the full framework for when local acquiring is worth pursuing, including the operational changes to settlement and reconciliation it brings.

PSP Reconciliation Failure Runbook — the break types and escalation checklist for when a multi-currency settlement feed stops matching the ledger.