Multi currency travel booking website: where margin leaks
A sub-agent in Riyadh asks why your site quoted SAR on the search page and your invoice says AED. You check. Both numbers are right. The fare was priced by the supplier in one currency, shown to the traveller in another, and settled in a third when the card cleared. Nobody made a mistake, and you are still short. That gap is where a multi currency travel booking website quietly loses money, and it is almost never the exchange rate doing the damage. It is the rounding rule underneath it, and the unanswered question of who is carrying the risk between the quote and the settlement.
Two currencies, and only one of them moves money
Any storefront selling across a border runs two currency systems at once. Treating them as one is the root of most of the mess.
The display currency is what the traveller reads. It is a presentation layer. On this platform each white-label site picks its own default currency and the list it offers, and prices convert client-side from a per-tenant rate table. That detail matters more than it sounds: the number on screen is derived. It is your rate applied to the supplier's price at the moment the page renders, not a price anybody has agreed to hold.
The settlement currency is the one the money actually moves in — what the supplier bills you, what the gateway captures, what lands on the bank statement, what the refund goes back out in. There is usually one per supplier and one per gateway, and they are not always the same one.
When an agency says "we sell in AED, SAR and USD", it almost always means it displays three and settles in one. That is a perfectly good way to run a shop; most shops run that way. It stops being fine the moment something downstream treats a displayed price as a commitment — a refund, a sub-agent statement, a dispute — because the displayed price was never a commitment. It was a rendering.
Who carries the FX risk on a multi currency travel booking website
Between the traveller seeing a price and the money settling, someone is exposed to a rate that can move. The question is never whether that exposure exists. It is who owns it, and whether they know they own it.
There are three honest answers. The supplier carries it when you have contracted net rates in your own currency and they absorb the conversion. The traveller carries it when you charge in the supplier's currency and their card issuer converts — cleanest for you, and the one travellers complain about, because the amount on the statement is not the amount on the confirmation. Or you carry it, which is what a rate table means: you have fixed a rate, and the difference between your rate and the real one on settlement day is yours, in either direction.
All three are defensible. The one to avoid is the accidental fourth, where nobody has decided, the rate table is updated whenever somebody remembers, and the position is discovered in reconciliation a quarter later. If you cannot name the owner and the update cadence in one sentence, you are in the fourth case.
Rounding is a pricing decision, not a formatting one
Most engines default to a rounding step of 0.01 because that is what a decimal currency looks like. It is the wrong default for travel, for four separate reasons.
The first is that not every currency has a minor unit. Japanese yen and Korean won do not; a price rendered with two decimals in those markets reads as a software artefact, and a rounding step of 0.01 on a currency with no cent is arithmetic on a unit that does not exist.
The second is that converted prices look converted. AED 1,236.47 announces itself as the output of a multiplication. A traveller reading it knows there is another number behind it, and the natural next move is to go find that number somewhere else. A price that lands on a round step reads as your price.
The third is direction. Rounding to the nearest step is symmetric: your errors cancel over volume and your margin is unaffected. Rounding up always adds a sliver, and rounding down always gives one away. Each is a policy, and each is fine if it was chosen. The failure is choosing it accidentally, in the wrong direction, and then wondering why gross margin in one market sits a little under the others.
The fourth is order of operations, and it is the one that actually bites. Convert, then apply markup, then round — once, at the end. An engine that rounds the net fare on conversion and rounds again after markup has rounded twice, and the second rounding is applied to a number that already lost its remainder. Multiply that across a fare, taxes and ancillaries priced as separate components and the total no longer equals the sum of its parts, which is a reconciliation problem before it is a pricing one.
Round per component or round the total, but do not do both, and make sure whatever an invoice shows adds up when a sub-agent puts it in a spreadsheet. They will.
Three ways to actually run it
The models below are not feature tiers. They are three different answers to "what do you promise the traveller", and they carry different work.
| Display conversion | Per-market price lists | Settle per market | |
|---|---|---|---|
| What it is | One settlement currency; a rate table renders the rest | Prices set by hand per market, not derived | A gateway and a bank account per currency |
| Who carries FX | You, between rate update and settlement | You, until you re-price | Mostly nobody — you hold each currency |
| Refunds | Need the sale-day rate stored, or you eat the difference | Clean: same number back | Clean |
| Price control | Weak. Psychology is whatever the rate produces | Total. You choose every price point | Total |
| Accounting | One ledger, easy | One ledger, easy | Several ledgers, real work |
| When it is right | Most agencies, most of the time | A market you actually compete in on price | You have staff, volume and a bank in that country |
Almost everyone should start in the left column and move a single market to the middle one when it earns the attention. The right column is an operations decision wearing a technology costume; if nobody in the building reconciles two ledgers today, adding a third currency will not be the thing that starts.
What it costs you if you get it wrong
The refund is the classic. A booking is sold at one rate, cancelled six weeks later, and refunded at today's rate because that is what the engine had to hand. If the rate moved in the traveller's favour you have paid the difference; if it moved the other way the traveller believes you shorted them, and they are not entirely wrong. Store the rate used at sale, on the booking, and refund against it.
The quieter one is credit. Sub-agent credit limits and settlement invoicing exist here as first-class things rather than a spreadsheet — which is only an advantage if the limit is denominated in the currency that sub-agent actually sells in. A limit in USD against an agent selling in SAR drifts every time the rate does, and the drift is discovered at the worst moment, which is when the limit blocks an issuance at the airport.
Then the slow one. A stale rate table does not throw an error. It sells. For weeks it can look like unusually good volume in one market, right up until the month closes and the volume turns out to have been a discount you did not know you were giving. This is the argument for putting a date and an owner on the rate table rather than a cron job nobody reads.
Before you switch a market on
None of this needs a project. It needs decisions written down, in this order, before the currency appears in the picker:
- Name the settlement currency for that market, and the supplier and gateway it applies to. One sentence.
- Name who updates the rate table and how often, and put the last-updated date somewhere a human sees it.
- Choose a rounding step per currency, not one global step, and check the zero-decimal currencies separately.
- Confirm the order is convert, mark up, then round once — and that component prices still sum to the total on the invoice.
- Confirm refunds use the stored sale-day rate, not today's.
- Check that sub-agent credit limits and settlement invoices are in the same currency as the statements those agents read.
Then turn it on, sell into it for a fortnight, and reconcile that fortnight by hand once. The first market is the one that teaches you which of the six above you got wrong.
Currency behaviour is the part of a storefront that is easiest to demo and hardest to audit, so it is worth seeing the actual settings before you design around them. If you want to look at what a site ships with — the currency list, the rate table, the admin the markups live in — start one from the wizard; it provisions on a platform subdomain and does not ask for a card. If you are still deciding whether to run someone else's engine at all, the build-versus-white-label comparison is the argument underneath this one, and what a white label actually gets you covers the rest of the surface.
The exchange rate is public information. Your rounding rule, your refund rate and your update cadence are not, and they are the three places the margin on a cross-border booking is actually decided.