Short answer: separate three currencies in your design - the supplier's currency, the display currency the customer shops in, and the settlement currency you actually charge and receive. Convert supplier prices to display prices with a managed rate plus a small buffer, round to price points that look natural in each currency, charge in a currency your gateway genuinely supports, and always refund in the currency and amount originally charged. Most disputes trace back to mixing those layers up.
The three currencies in every booking
A single hotel booking on an international portal can involve a property that prices in euros, a customer who shops in US dollars and a merchant account that settles in Indian rupees. Confusing these layers produces the classic failure: a site that converts prices for display with one rate, charges with another, and refunds with a third, leaving either the customer or the business short.
| Layer | Whose currency | Decided by |
|---|---|---|
| Supplier currency | The airline, bed bank or hotel's contract currency | Your supplier agreement; often EUR, USD or GBP for wholesale content |
| Display currency | What the shopper sees while searching and comparing | Your site: geolocation default plus a manual currency switcher |
| Settlement currency | What the card is actually charged in and what lands in your account | Your gateway and merchant account configuration |
Display and settlement can be the same currency, and for a single-market site they usually should be. The complexity starts when you sell into several markets from one platform, which is standard for B2B portals serving agents in different countries.
Display currency: shopping without surprises
Shoppers compare prices in the currency they think in. Detect a sensible default from country or locale, let the user override it with a visible switcher, and persist the choice. Two honesty rules keep you out of trouble. First, if the charge will happen in a different currency, say so before payment: "You will be charged INR X; the USD amount shown is indicative." Second, keep one conversion rate per session or per day rather than re-fetching mid-funnel, so the price the user saw on the results page is the price on the checkout page. A price that drifts between steps looks like a scam even when it is only an FX refresh.
Settlement currency: what you actually charge
Charging in the customer's own currency, sometimes called multi-currency processing or like-for-like presentment, is the cleanest experience: no conversion fees on their statement, no surprise amounts. It requires a gateway and acquiring setup that supports each presentment currency, and the funds are typically converted to your account currency at settlement. The alternative - charging everyone in your home currency - is simpler to operate but pushes conversion costs and uncertainty onto the customer, whose bank applies its own rate.
A related but different mechanism is dynamic currency conversion (DCC), where a transaction that would naturally be in your currency is offered to the cardholder in theirs at a marked-up rate. Card schemes publish strict disclosure rules for DCC, and consumer advice from networks such as Visa generally notes the cardholder's own bank rate is often better. If you enable it, treat it as an explicit customer choice, never a default.
Rounding and psychological pricing
Raw conversion produces ugly numbers: EUR 118 becomes INR 12,067.43. Rounding rules make prices legible, but in travel they must respect one constraint - your total must still cover the supplier cost after every fee. Practical patterns:
- Round to currency-appropriate points. Charm endings differ by market: 9,999 reads naturally in India, 99 endings in the US, round hundreds are common for premium positioning. Zero-decimal currencies such as JPY need integer handling in both display and gateway calls.
- Round the sell price, not the cost. Convert the supplier cost precisely, add your markup, then round the final figure upward to the nearest chosen point so rounding never eats margin.
- Keep taxes and fees consistent. If the fare breakdown is shown, the rounded components must sum to the rounded total; travellers do check.
FX buffers and rate management
Between the moment you quote and the moment the supplier invoices you, rates move. Sites handle this with a small conceptual buffer: the conversion rate used for pricing is the market reference rate adjusted by a margin of a percent or two, refreshed on a schedule (daily is common for cached content, per-search for live fares in volatile pairs). The buffer absorbs normal drift; it is not a profit centre, and setting it too high makes you uncompetitive on every metasearch comparison. Decide, and document, which rate source you use - central bank reference rates and commercial FX APIs are the usual options - and log the rate applied on each booking so finance can reconcile later.
What payment gateways support
Gateway capability decides what is feasible. The questions to ask any provider: which presentment currencies can we charge in; which settlement currencies can we receive; what conversion rate and margin applies between them; are zero-decimal and three-decimal currencies handled correctly; and do refunds convert at the original rate or today's? Global gateways document long currency lists; domestic gateways may charge international cards while settling only in local currency. For Indian businesses there are additional regulatory dimensions - export transactions, international card acceptance and gateway options are covered in our guide to payment gateways for travel agencies in India.
Refunds across currencies
The rule that prevents most disputes: refund in the currency and amount originally charged. Gateways generally process refunds this way by default, but the FX layer means the customer may see a slightly different figure in their own currency than they originally paid, because their bank converts at today's rate, not the booking-date rate. Say this in your refund policy in plain words: "Refunds are issued for the amount charged in the original currency; your bank's exchange rate on the day of the refund may differ from the rate on the day of booking." For partial refunds - common in travel where airline penalties apply - calculate the penalty in the supplier's currency, convert with the booking-date rate you logged, and show the customer the arithmetic. Ad-hoc conversions done at refund time are where money quietly leaks.
Implementation notes for travel platforms
- Store money as integers in minor units (paise, cents) with an explicit currency code on every amount field; never floats.
- Record four values per booking: supplier amount and currency, applied conversion rate, charged amount and currency. Reconciliation is impossible without them.
- Convert once, at a defined point in the funnel, and reuse that quote through checkout.
- Test zero-decimal and high-value currencies (JPY, IDR, KWD) end to end, including gateway calls and invoices.
- Show one currency per page. Mixing display currencies across components on the same screen is the most common multi-currency bug we see in portal audits.
- Agree supplier settlement terms. BSP, consolidator and bed-bank invoices arrive in their currencies on their schedules; your margin report must convert consistently with your pricing engine.
Multi-currency support is one of those features that is cheap to design in and expensive to retrofit. If you are scoping a new build, decide the currency model alongside supplier selection, not after launch - it shapes the database, the portal architecture and the gateway contract. The same layering applies whether you run a B2C site or a multi-country B2B platform where each agent may hold a wallet in a different currency.
This article is general information about travel technology and online marketing. It is not legal, tax or financial advice, and advertising platform policies change often. Check the current policy documents and take professional advice for your own situation.