The Multi-Currency Problem
Nobody Solves Well

Every payment platform claims to support multi-currency. Most of them mean they'll accept charges denominated in multiple currencies. That's the easy part. What they don't tell you upfront is what happens when your Mexican user pays in MXN, your settlement account is in USD, your accounting system expects EUR, and the FX rate shifts between authorization and settlement.

Multi-currency payment processing is one of those problems that looks solved from the outside and is genuinely hard from the inside. Here's an honest accounting of where it breaks.

Presentment currency vs. settlement currency: the gap nobody explains

Every transaction has two currencies: the presentment currency (what the customer sees on their card statement) and the settlement currency (what ends up in your bank account). These are not always the same thing, and the relationship between them is not straightforward.

If you charge a customer €100 and your settlement account is in USD, your processor converts the €100 to USD at their internal rate at the time of settlement — which may be 1–3 days after authorization. Your authorization record shows €100. Your settlement record shows the USD equivalent at whatever rate your processor applied. Your accounting system now has to reconcile these two figures, and if you're booking revenue in USD at the time of charge rather than at the time of settlement, you have a foreign exchange gain or loss that needs to be accounted for.

This creates three distinct FX timing problems. First, you have exchange rate risk between authorization and settlement (typically 1–2 business days). For most currencies, this is minor — EURUSD rarely moves more than half a percent in two days. For volatile currencies (TRY, ARS, NGN), this can be 2–5% per transaction in bad periods. Second, you have a mismatch between what you invoiced and what you collected that your revenue recognition system needs to handle. Third, your customer-facing reporting (their invoice shows €100) and your internal reporting (you received $108.47) use different numbers for the same transaction.

The FX data latency problem

If you're offering customers the option to pay in their local currency but settle in USD, you're making real-time pricing decisions based on FX data. The question is: how fresh is your FX data and what happens when it's stale?

FX rates update continuously during market hours and are fixed on weekends and holidays. A typical third-party FX data provider refreshes rates every few minutes. If you're using cached rates and your cache update fails, you could be quoting exchange rates that are 30–60 minutes old during a volatile period. For stable currency pairs (GBP/USD, EUR/USD), this is usually immaterial. For currencies that move more aggressively, a 30-minute stale rate during a news event can mean you're quoting 1–2% off current market.

The practical risk: a customer who notices a significant discrepancy between the rate quoted at checkout and what their bank charged them will dispute the transaction. Not necessarily as fraud — sometimes just as "the amount didn't match." These disputes cost you the transaction amount plus a dispute fee, typically $15–25, regardless of outcome.

Stale FX rate handling should: fail closed (show an error rather than quoting an obviously wrong rate), have a maximum staleness threshold after which the rate is considered invalid, and have monitoring that alerts before staleness becomes a customer-facing problem. "Use the last cached rate until something better arrives" is not a sufficient strategy for production payment flows.

Settlement currency configuration is harder than it looks

Most platforms let you configure a settlement currency per merchant or per account. The configuration sounds simple. The edge cases accumulate quickly.

What happens when a customer pays in a currency you have no settlement account for? You can either reject the transaction (bad for conversion), convert to your default settlement currency (adds FX conversion costs), or convert to the nearest related currency (requires a currency mapping table and someone to maintain it).

What happens when a customer's payment method is denominated in a different currency than their billing address country? A UK customer paying with a US-issued credit card denominated in USD wants to buy a subscription priced in GBP. Which currency do you authorize in? The customer's card currency (USD), the subscription price currency (GBP), or the customer's home market currency? These are different authorization amounts, different interchange rates, and different settlement amounts.

The answer varies by processor and by the specific combination of card type, merchant category code, and geographic factors. There's no universal rule here. What there is: a well-defined internal policy your routing logic can apply consistently, and logging detailed enough to reconstruct any transaction's currency handling after the fact.

Reporting across currencies: an unsolved coordination problem

Finance wants to see revenue in USD (or EUR, or whatever your reporting currency is). Product wants to see transaction counts by market. Sales wants to see MRR by region in local currency. Each of these reporting requirements has different data freshness needs and different tolerance for FX approximations.

The mistake most companies make is converting all transactions to a single reporting currency at write time using whatever FX rate was current when the transaction settled. This is fine for current-period reporting but terrible for historical analysis. If USD/EUR moves significantly over a quarter, your historical EUR revenue looks different depending on which exchange rate you use to translate it — the rate at transaction time, the rate at period-end, or a period-average rate.

GAAP and IFRS have specific rules about this for financial reporting purposes. ASC 830 (GAAP) requires specific approaches for measuring and reporting foreign currency transactions depending on whether the underlying currency is "functional" or "reporting." If you have any international revenue and a US entity, your accounting team needs to be involved in how your payment data is stored and surfaced to the general ledger.

The practical advice: store all transactions in both the original transaction currency and a reporting currency conversion using the rate at settlement time. Treat these as separate data points with different update rules. Never overwrite historical FX-converted amounts — they represent what actually happened at that point in time. Period-end translation adjustments belong in your accounting system, not in your payment records.

The currencies that don't behave like currencies

A few currencies require special handling that most multi-currency implementations don't document clearly until you discover the hard way.

Zero-decimal currencies (JPY, KRW, VND) don't use cents. A 1000 JPY transaction is one thousand yen, not ten yen. Payment APIs represent amounts in minor units — for USD that means cents, for JPY that means whole yen. Passing "1000" as an amount means $10.00 in USD and ¥1,000 in JPY. This is documented in every major payment API and still causes bugs regularly when developers write currency-agnostic pricing code that assumes all currencies have two decimal places.

Some currencies have official restrictions on cross-border transfers that affect settlement routing. NGN (Nigerian naira) and ARS (Argentine peso) have had periods where outbound settlement was restricted by local banking regulators. Your payment infrastructure needs to handle "authorization succeeded but settlement impossible" as a distinct failure state, not conflate it with generic payment failure.

Currency codes change. When countries rename currencies, issue new series with different codes, or join currency unions, existing transaction records need to handle the transition. This is rare but not theoretical — the transition from national currencies to the Euro created exactly this problem, and the various ongoing monetary reforms in emerging markets create smaller versions of it periodically.

The PayLoop approach

We support 180+ currencies for presentment and settlement routing across 40+ settlement currencies. The infrastructure handles FX rate management, settlement currency configuration per merchant, and the reporting data model required for multi-currency revenue recognition. What we don't do is pretend it's simple — the edge cases above are real and the implementation reflects that complexity rather than papering over it.