Handle multi-currency pricing display vs settlement correctly in travel bookings

Verified steps

1. Determine the display currency (what the user sees) vs the settlement currency (what is actually charged) early in the flow — these may differ, especially when booking across borders.
2. Most travel APIs return prices in a base currency defined by the content source (e.g. Amadeus returns in the currency of the point-of-sale or the fare currency); request the user's preferred display currency explicitly if the API supports it, otherwise convert client-side.
3. Use a reliable FX rate source (e.g. European Central Bank daily rates, Open Exchange Rates) for display conversion; clearly label converted prices as 'approximate' and show the base currency price too for transparency.
4. At checkout, pass the settlement currency to the payment processor — do not pass a display-converted amount; let the payment processor or the API handle the definitive currency conversion to avoid double-conversion errors.
5. Store the booked price in both the API's returned currency and the user's display currency with the exchange rate and timestamp — you will need this for refund calculations and customer service.
6. Be aware that airline ticket prices are often filed in USD internally (especially IATA BSP settlements) and converted to local currency by the GDS — a small rounding difference between displayed price and charged price is normal and should be disclosed.