Why Travel Payments Are Uniquely Complex
Travel is one of the hardest verticals for payment infrastructure. Not because individual transactions are technically difficult — but because the ecosystem around those transactions creates complexity that most payment setups can't handle.
A travel platform might process a booking where:
The customer pays in GBP
The airline settles in USD
The hotel settles in EUR
The transfer company settles in THB
Each supplier mandates a different payment processor
The booking was made over the phone, so the card was captured via voice
The customer later modifies the booking via the website and pays a supplement via payment link
That's one booking. Now multiply by thousands per day across dozens of markets.
Most SaaS platforms start with a single PSP — Stripe or Adyen — and it works until it doesn't. In travel, "until it doesn't" arrives fast.
The Three Problems Travel Platforms Face
1. Supplier and Partner PSP Mandates
Airlines, hotel chains, cruise lines, and tour operators are enterprise businesses with established payment infrastructure. They don't switch processors because a booking platform asks them to.
When an airline says "we settle through Worldpay" or a hotel group says "our treasury is set up with Barclays," your platform needs to route payments through those processors. With a single-PSP architecture, the answer is "we can't do that." With a multi-PSP setup, it's a configuration change.
This is the same enterprise PSP mandate pattern that affects every vertical selling into large organisations — but travel hits it earlier and harder because the supplier base is dominated by enterprises with existing acquiring relationships.
Common PSP mandates in travel:
Airlines — often require specific acquirers aligned with IATA BSP settlement
Hotel chains — treasury-mandated processors (Worldpay, Adyen, Global Payments)
Tour operators — regional acquirers for domestic card processing
Car rental companies — fleet-level acquiring contracts
Cruise lines — specialist high-value transaction processors
A travel platform that can only process through Stripe loses deals with any supplier that mandates a different gateway. The first mandate is an inconvenience. The fifth is a structural problem.
2. Multi-Currency and Cross-Border Complexity
Travel is inherently cross-border. A UK customer books a hotel in Japan, a flight on a US airline, and a transfer with a Thai company. Each transaction involves currency conversion, cross-border acquiring fees, and potentially different interchange rates depending on the card's issuing country.
The cost differences are significant:
Domestic acquiring (card and acquirer in the same country): lowest interchange, highest approval rates
Cross-border acquiring (card in one country, acquirer in another): higher interchange, lower approval rates, additional scheme fees
Multi-currency pricing (DCC or MCC): the customer pays in their currency, but the merchant settles in theirs — fee structures vary by provider
A single-PSP setup means every transaction routes through one acquirer, regardless of geography. A multi-PSP setup lets you route each transaction through the acquirer that offers the best rates and approval rates for that specific card-country-currency combination.
For a travel platform processing £10M annually, the difference between domestic and cross-border acquiring on a significant portion of transactions can mean tens of thousands in unnecessary fees — and measurably lower authorisation rates on international cards.
3. Payments Happen Across Multiple Channels
Travel customers don't just pay through a checkout page. They pay:
Online — website or app checkout for direct bookings
Over the phone — calling to book, modify, or pay supplements. Travel has one of the highest phone booking rates of any vertical
Via payment links — sent by email or SMS after a phone enquiry, for balance payments, or for booking modifications
Through AI agents — voice bots handling rebooking, cancellations, and payment collection
Via B2B channels — travel agents booking on behalf of clients, paying on account or by card
Each channel needs PCI-compliant card capture, and ideally routes through the same PSP configuration so that reconciliation, refunds, and reporting work consistently.
With a single-channel payment setup (web checkout only), everything else becomes a manual process — call centre agents taking card details over the phone (PCI risk), finance teams chasing bank transfers for B2B payments, separate systems for payment links.
What Travel Platforms Actually Need
Multi-PSP Routing
Your platform connects to multiple payment processors. Each supplier, market, or transaction type routes to the appropriate PSP:
UK domestic bookings → UK acquirer (best interchange rates)
US airline settlements → US processor (airline's mandate)
Southeast Asian hotels → regional acquirer (local cards, local payment methods)
High-value bookings → processor with highest approval rates for that card type
Adding a new PSP is a configuration change, not an engineering project. When a new supplier mandates a specific processor, you configure it — not build an integration from scratch.
Multi-Currency Settlement
Suppliers settle in their local currency. Customers pay in theirs. The payment infrastructure handles the conversion, routing each leg of the transaction through the appropriate currency path.
This isn't just about displaying prices in different currencies. It's about acquiring in the right currency to minimise fees and maximise approval rates — a distinction that matters enormously at travel transaction volumes.
Multi-Channel Payment Capture
Every payment channel — web, voice, payment links, AI agents — uses the same underlying infrastructure:
Same PSP configuration — a card captured over the phone routes through the same processor as a card entered online
Same tokenisation — a card token from a voice payment can be used for a subsequent online charge (modification, supplement, no-show fee)
Same reporting — all transactions, regardless of channel, appear in one reconciliation view
**Same PCI compliance** — the payment layer carries PCI DSS Level 1 for all channels. Your platform's PCI scope stays minimal
Refunds, Modifications, and Partial Charges
Travel bookings change. Flights get cancelled. Hotels get upgraded. Itineraries shift. Your payment infrastructure needs to handle:
Partial refunds — refund the hotel portion but keep the flight
Supplements — charge an additional amount for a room upgrade or date change
Card-on-file charges — no-show fees, damage charges, or balance payments using the card captured at booking
Split payments — portion paid by card, portion by bank transfer, portion by voucher
These aren't edge cases in travel — they're standard operations that happen on a significant percentage of bookings.
How Travel Agencies and TMCs Fit In
Travel agencies and travel management companies (TMCs) have an additional layer of complexity: they're intermediaries.
The agency collects payment from the traveller but isn't the merchant of record for the underlying services. Depending on the commercial model:
Agent model — the airline or hotel is the merchant. The agency facilitates but doesn't process the payment.
Merchant model — the agency is the merchant. They process the payment and settle with suppliers separately.
Hybrid — some components are agent model, some are merchant model, within the same booking.
Each model has different PSP requirements, different settlement flows, and different PCI obligations. A payment infrastructure that handles only one model forces agencies into workarounds for the others.
B2B travel payments add another dimension. Corporate travel bookings are often paid on account, by invoice, or via lodge cards (centralised corporate cards). The payment system needs to support these alongside consumer card payments — through the same reporting and reconciliation.
The Build vs Buy Decision for Travel Platforms
Travel platforms that build payment infrastructure in-house face a specific set of challenges:
**Multiple PSP integrations.** Each airline, hotel chain, or regional market that mandates a different processor means a new API integration. Five PSPs means five sets of webhooks, five error code mappings, five reconciliation formats. This is engineering capacity that should be building your travel product, not maintaining payment plumbing.
PCI compliance across channels. Web checkout, phone payments, payment links — each channel has PCI requirements. Building PCI-compliant voice payment capture alone is a major infrastructure project. Maintaining compliance across all channels, annually, is a permanent cost.
Multi-currency acquiring logic. Routing a transaction to the right acquirer based on card issuing country, settlement currency, and cost optimisation requires routing intelligence that's non-trivial to build and maintain.
Refund and modification complexity. Travel refund flows (partial refunds across suppliers, multi-currency refunds, refund-and-rebook) require careful handling at the PSP level. Getting this wrong means reconciliation nightmares.
A payment layer solves all four by providing multi-PSP routing, multi-channel capture, multi-currency support, and refund management through a single integration. The platform integrates once. The payment layer handles the PSP complexity underneath.
Choosing a Payment Solution for Travel
What to prioritise
PSP flexibility. Can you add a new processor when a supplier mandates it? If adding Worldpay means a 3-month integration project, your solution isn't flexible enough.
Geographic coverage. Does the solution support acquirers in the markets you operate in? Southeast Asia, Latin America, and the Middle East need local processors for competitive rates on domestic cards.
Channel coverage. Can the same solution handle web checkout, phone payments, and payment links? Or do you need separate infrastructure for each channel?
Multi-currency support. Can you acquire in multiple currencies and settle in different currencies per supplier?
Tokenisation. Can a card captured in one channel (phone) be charged in another (web) without the customer re-entering details?
Refund handling. Can you process partial refunds, multi-currency refunds, and card-on-file charges without manual intervention?
What to avoid
**Single-PSP lock-in.** A solution that only routes through one processor will become a bottleneck as you add suppliers with PSP mandates. See when platforms outgrow single-PSP solutions.
Web-only payment capture. If your solution only handles checkout, you'll need separate infrastructure for phone payments and payment links — doubling your integration and compliance burden.
**Building from scratch.** The cost of building payment infrastructure in-house is well-documented: 12+ months, significant PCI investment, ongoing maintenance that consumes 20-30% of engineering capacity. In travel, where the multi-PSP, multi-currency, multi-channel requirements are more demanding than most verticals, the build cost is higher still.
FAQ
Do travel platforms need PCI compliance?
If your platform handles card data in any form — web checkout, phone payments, card-on-file — you have PCI obligations. The scope depends on your architecture. Using a payment layer that handles card capture across all channels means your platform never touches card data, keeping your PCI scope at the minimum level (SAQ A or equivalent).
What about IATA BSP and ARC settlement?
IATA's Billing and Settlement Plan (BSP) and Airlines Reporting Corporation (ARC) have specific settlement processes for ticket sales. Your payment infrastructure handles the customer-facing payment collection. BSP/ARC settlement between the agency and the airline is a separate financial process. Both need to reconcile, which is why unified reporting across all PSPs matters.
Can travel platforms monetise payments?
Yes. Platforms can earn revenue share on payment transactions flowing through their system — a commercial model that turns payment infrastructure from a cost centre into a revenue stream. See how platforms monetise payments for the full breakdown.
What about alternative payment methods?
Different markets prefer different payment methods. iDEAL in the Netherlands, Bancontact in Belgium, Klarna in Scandinavia, PIX in Brazil, Alipay and WeChat Pay for Chinese travellers. A multi-PSP payment layer supports these through the PSPs that offer them — without the platform needing to integrate each payment method individually.
How long does integration take?
A single integration with a payment layer typically takes 2-4 weeks. This covers all PSPs, all channels, and all currencies. Compare that to building individual PSP integrations (months each) plus voice payment infrastructure (months more) plus payment link capability (more engineering time).
Related Reading
Payment Links for Hotels & Holiday Accommodation — deposit, no-show, and upsell collection via payment links
AI Voice Payments for Hotels & Travel — voice-based payment capture for booking and modification calls
PSP-Neutral vs Single-PSP — the architectural decision for multi-supplier platforms
Enterprise PSP Mandates — why airlines and hotel chains require specific processors
When Your SaaS Outgrows Stripe Connect — migration playbook for travel platforms hitting single-PSP limits
How Platforms Monetise Payments — turning travel payments into platform revenue
Gateway vs Orchestrator vs PayFac vs Payment Layer — understanding the four categories of payment infrastructure
How to Get Payments Off Your Product Roadmap — reclaim engineering capacity from payment maintenance
Building a travel platform?
Shuttle gives travel platforms multi-PSP routing, multi-currency settlement, and multi-channel payment capture — web, voice, payment links, and AI agents — through a single integration. Each supplier uses their mandated processor. Your platform earns revenue share. PCI DSS Level 1 compliance included.