Multi-currency pricing and FX in travel booking platforms

A multi-currency booking platform buys in one currency, sells in another and often settles in a third. A hotel priced by a bedbank in euros, sold to an agent in US dollars and paid out to the supplier from a local-currency account involves three amounts, two conversions and several chances for rounding to drift. Getting currency right is less about clever maths than about storing the right facts at the right moment.

Three currencies, one order

Name the currencies explicitly in the data model:

• Supplier (net) currency — what the supplier charges.
• Selling currency — what the customer or agent sees and pays.
• Settlement currency — what money actually moves in, between your bank accounts, card acquirer and suppliers.

Every price component on an order — base fare or room rate, taxes, fees, markup, discounts — should record its amount and currency. Totals are derived, never the only stored value.

Store money correctly

The basics prevent most bugs:

• Never use floating-point numbers. Use integers in the minor unit, or a fixed-precision decimal type in the database.
• Always store the currency code next to the amount, using ISO 4217.
• Do not assume two decimal places. Japanese yen has no minor unit in common use, while currencies such as the Kuwaiti dinar and Bahraini dinar use three. Keep the exponent per currency in configuration, not in code.
• Use one money type across the codebase, with arithmetic that refuses to add two different currencies.

These rules are cheap on day one and painful to retrofit, which is why they belong in the MVP of any platform that might ever sell internationally.

Snapshot the exchange rate

Exchange rates change continuously. A platform needs one rate per currency pair that is fixed for the life of an offer:

1. Fetch rates from a chosen provider on a schedule and store each set with its timestamp and source.
2. When pricing a search result, convert with the current snapshot and record which snapshot was used.
3. Carry the rate with the offer into checkout, and store it on the order.

If checkout converts again with a newer rate, the customer sees the price move for no visible reason. If the offer has expired, re-price explicitly instead of quietly applying a different rate.

Many businesses also apply an FX buffer — a small margin on top of the market rate — to cover movement between the sale and paying the supplier. That buffer is a commercial decision; the platform should make it configurable and visible in reports, not hide it inside the conversion.

Markup, then round — in a defined order

Pricing pipelines go wrong when the order of operations is implicit. Decide and document it, for example:

1. Take the supplier net amount in supplier currency.
2. Convert to selling currency at the snapshot rate.
3. Apply markup rules — percentage, fixed amount per booking or per passenger.
4. Apply taxes or fees that are calculated on the sold amount.
5. Round to the selling currency’s precision, then apply any display rounding such as whole units.

Round once, at a defined point, with a defined rule, and record any rounding difference. Rounding each component separately and then adding them produces totals that do not match the sum of the lines, which finance teams will notice.

Agent markups in B2B platforms add a layer: each account may add its own margin on top of the platform’s price. Keep each layer as its own line so commissions and invoices can be reconstructed exactly.

Airline fares have their own currency logic

Airline fares are not simply converted at a market rate. Fares between countries are traditionally constructed in a neutral unit, the Neutral Unit of Construction (NUC), and converted into the currency of the point of sale using IATA’s published rates of exchange. Taxes are often in yet another currency. A booking platform should take the airline’s or GDS’s priced total in the selling currency rather than re-deriving it, and store the full pricing response for reference.

Refunds, changes and cancellations

Refunds are where FX policy becomes visible to customers:

• refund in the currency the customer paid,
• base the calculation on the amounts recorded at sale, not today’s rate,
• record the supplier refund separately, in supplier currency — the difference between what you recover and what you return is a real gain or loss that finance needs to see.

Changes and upgrades raise the same question in the other direction: price the difference with a new snapshot and show it clearly.

Make FX exposure visible

Between selling a booking and paying the supplier, the business holds a position in another currency. Over thousands of bookings that becomes material. The platform should report, by currency:

• outstanding supplier liabilities not yet paid,
• the rate used at sale versus the rate at settlement,
• realised FX gains and losses per period.

This is reporting, not trading — but without it, a business can be profitable on every booking and still lose money on currency.

Test with awkward currencies

Unit tests in a single two-decimal currency catch little. Include currencies with zero and three decimal places, conversion paths in both directions, very small and very large amounts, partial refunds, and totals that must equal the sum of their lines. Property-based tests are useful here: for any set of components, the stored total should equal the rounded sum under your documented rules.

Summary

Treat supplier, selling and settlement currencies as separate facts. Store money as integers or fixed decimals with a currency code and the right precision, snapshot exchange rates and carry them with the offer, apply markup and rounding in a documented order, refund from what was recorded at sale and report FX exposure explicitly. None of this is complicated, but all of it has to be decided deliberately.