A cross-currency payment has a question at its centre that has nothing to do with mandates, signatures, or rails: who performs the conversion, and at what rate? Whoever converts sets the price, and the gap between the best and worst answer on the same purchase is routinely a few percent — larger than most of the fees anyone argues about. Human buyers rarely get to choose; they are handed a converted number at a terminal and accept it. An agent is in a different position. It can request quotes before it commits, compare delivered amounts rather than headline rates, decline a bad conversion offer without feeling awkward, and record exactly which rate backed the amount the user approved. This piece is about using that position well.
Four places a conversion can happen
Before arguing about rates, locate the conversion. There are typically four candidates, and only one is usually under your control.
| Where | Who sets the rate | When it is fixed |
|---|---|---|
| At the agent or wallet | You, via a chosen FX provider | Before the payment is initiated |
| At the PSP or acquirer | Your processor | At capture or at payout |
| At the merchant (DCC) | A DCC vendor, merchant, acquirer | At checkout, before the network sees it |
| At the network and issuer | Scheme rate plus issuer markup | At clearing, after authorization |
These are mutually exclusive for a given leg of money: if the agent converts euros to dollars and then pays a dollar-priced merchant in dollars, the network has nothing left to convert. Choosing the row deliberately, rather than inheriting it from whichever integration was easiest, is the highest-leverage decision in the flow.
Quote sourcing, the spread, and the fees beside it
The mid-market rate — the midpoint between the best bid and offer in the interbank market — is the number search engines show and the number nobody transacts at. What you deal on is mid-market plus a spread, the provider’s margin, covering their dealing costs, inventory, and the risk of committing to a price at all. Sources are not interchangeable: streaming prices from a liquidity provider are tradable, while central-bank reference rates and daily fixings are authoritative for accounting but are snapshots, not offers. Spreads widen for thin pairs, outside the main trading sessions, during volatility, and the longer the provider must hold the price.
Two other costs ride alongside and are not the same thing. A conversion fee is an explicit charge for doing the conversion. A cross-border fee is charged for the transaction being international at all, and can apply when no conversion happens whatsoever — a euro card paying a euro-priced merchant whose acquirer sits abroad. Ordering matters too: converting and then applying a percentage fee does not equal applying the fee and then converting. So the only honest comparison between offers is the all-in delivered amount for the same input.
Validity windows and the agent that deliberates too long
Every firm quote carries an expiry, and quote lifetimes were designed around human checkout: a person sees a total and clicks within seconds. Agents break that assumption. An agent may fan out to five merchants and compare, wait on a push notification for confirmation, or re-plan after a stock check fails. Deliberation measured in minutes is normal, not pathological.
So the quote often dies before authorization, not between authorization and capture. Three bad responses follow. A hard failure sends the agent back to re-quote at an unknown price. A silent re-quote charges an amount the user never saw. Settling on the stale rate hands the market move to whoever was not paying attention. The fixes are unglamorous: request the firm quote just in time, immediately before commitment rather than at the start of shopping; size the window against your measured p95 deliberation latency; and carry the quote identifier and expiry in the mandate, so the approved amount is provably the charged one.
Guaranteed versus indicative rates — and who carries the move
Two kinds of rate look identical in a JSON payload and mean entirely different things. An indicative rate is information: roughly what this would cost, committing nobody. A guaranteed rate is a contract: the provider will convert at this rate until this timestamp regardless of the market. That guarantee is a real product with a real cost, which is why longer windows carry wider spreads.
The distinction is simply who owns the market risk in the interval. Under a guarantee, the provider does, and has priced it. Under an indicative rate, you or the user do, whether or not anyone said so. This bites in AP2 because a cart mandate naming an exact amount is, to the user, a promise about that amount — and if the number came from an indicative feed, somebody absorbs the difference when it moves. Use indicative rates for comparison and guaranteed rates for the committed leg, and state what tolerance the platform absorbs and what size of move sends the agent back for fresh consent.
Dynamic currency conversion: the offer an agent should decline
Dynamic currency conversion is the offer to bill you in your home currency at a foreign merchant. The mechanics decide the verdict: conversion happens on the merchant side, by the merchant, their acquirer and a DCC vendor, before the transaction reaches the card network. The issuer therefore never converts, the scheme rate never applies, and the margin is set by and shared among the parties who benefit from your saying yes — and the user has no way to compare it against the rate their own issuer would have applied.
Scheme rules require DCC to be a genuine, informed choice: offered rather than imposed, with the rate and the margin over a reference rate disclosed, and the merchant-currency option still available. People accept anyway, because a familiar-currency number feels certain and the terminal is waiting. An agent has neither reflex. It can carry decline DCC by default as standing policy, detect the offer from its tell — a total in the home currency with a merchant-side rate attached — and log both figures so the choice is auditable.
Minor units and rounding: a worked example
Currency amounts are integers of minor units, never floating-point numbers, and the number of minor units varies: US dollars, euros and pounds sterling use two decimal places, Japanese yen and Korean won use zero, Kuwaiti and Bahraini dinars use three. Conversion moves between these conventions, so rounding is not a formatting step — it is where money appears or disappears.
A worked case with an illustrative rate: convert EUR 49.99, stored as the integer 4999, to yen at 171.4382. The exact product is 8,571.13… yen; yen has no minor unit, so the payable figure is 8,571 JPY and roughly 0.13 JPY of residue must be assigned to somebody. Three rules keep this reproducible. Convert once, directly from the integer amount, and never round the rate and then the amount, because two roundings compound. Fix the rounding mode — half-even avoids the bias half-up introduces — and name the beneficiary of the residue. Store the exact rate at full precision beside the result, so the same inputs regenerate the same output in a dispute.
Multi-currency balances, natural hedges, and forwards
If a platform pays out in dollars every day, the cheapest conversion is the one it does not do. Holding a multi-currency balance in the currencies you actually owe is a natural hedge: it removes the euro-to-dollar-and-back round trip that pays two spreads for no economic change. Netting extends the idea — convert only the net exposure at the end of a period rather than each transaction gross.
Where exposure is large and predictable, a forward contract fixes a rate now for a later delivery date. Its price is not a fee but forward points, reflecting the interest-rate differential between the two currencies, and they can favour either side. A forward replaces rate uncertainty with an obligation you must fulfil, so over-hedging a volume you fail to hit is its own problem. Hedge large, forecastable flows and leave small ones alone. And remember an idle foreign balance is itself an open position, not a neutral parking spot.
When the settled amount differs from the authorized amount
On card rails a cross-currency payment has a built-in reason for the final figure to move. The merchant’s amount never changes: the acquirer submits in the merchant’s currency. The conversion to the cardholder’s currency is applied by the network at clearing, using the scheme rate for the processing date — not the authorization date. If the two are a day apart and the market moved overnight, the posted amount differs from the authorized one and nothing has gone wrong. On top of the scheme rate the issuer may apply its own markup, a separate component frequently conflated with the scheme rate.
Systems built for single-currency payments read that difference as a break. Cross-currency systems must distinguish it: an explicit tolerance for FX-caused variance, judged against the movement in the relevant pair, kept separate from a genuine mismatch signalling error or fraud. The receipt should record the authorized figure, the currency of each figure, and the rate basis. Differences beyond tolerance belong in an exception queue, never a silent write-off.
A currency policy an agent can actually execute
Everything above compresses into a short set of standing decisions an agent can apply without asking a human each time.
| Question | Policy |
|---|---|
| Where will the conversion happen? | Prefer a party whose rate you can see and compare |
| Do I need a firm number yet? | Indicative while comparing; guaranteed only at commit |
| How long must the quote live? | At least your measured p95 deliberation latency |
| Was DCC offered? | Decline by default; log both figures |
| Does the mandate name an exact amount? | Back it with a guaranteed quote |
| Settled amount differs? | FX tolerance band, then an exception path |
None of this needs exotic infrastructure. It needs treating conversion as a pricing decision made on the user’s behalf rather than a unit change applied on the way out the door. An agent that quotes just in time, converts once with a documented rounding rule, and records the rate backing the authorization will deliver more of the user’s money to the merchant.