The Travel Payment Problem
Travel payments are unlike anything else in digital commerce.
A customer in Tokyo books a hotel in Barcelona, pays in British pounds, and the hotel's acquirer settles in euros. The platform takes a commission in US dollars. One transaction. Four currencies. Three parties. Multiple regulatory regimes.
Now multiply that across airlines, hotels, car rentals, transfers, and experiences — each with their own PSP requirements, settlement terms, and compliance mandates. Add pre-authorisation holds, partial captures, multi-leg itineraries, and a refund rate that makes other industries look simple.
This is the payment reality for every travel platform operating at scale.
Online travel agencies, tour operators, booking engines, and travel management companies all face the same fundamental challenge: travel payment flows are multi-party, multi-currency, multi-PSP, and multi-channel — by default.
Most travel platforms handle this in one of three ways:
Build everything custom. Multiple PSP integrations, in-house currency handling, bespoke settlement logic. Works eventually. Takes 18+ months and a dedicated payments team.
Standardise on a single PSP. Use Stripe or Adyen for everything. Works for simple OTAs with limited geography. Breaks the moment an airline mandates a specific acquirer or a hotel chain requires a regional processor.
Use a payment layer. A single integration point that routes to the right PSP per region, handles multi-currency, supports pre-authorisation flows, and covers voice and link channels alongside embedded checkout.
Option 1 is expensive and slow. Option 2 works until it doesn't. Option 3 is how scaled travel platforms are solving this without turning payments into a multi-year infrastructure project.
Why Travel Is Different from Standard E-Commerce
Standard e-commerce is a cart, a checkout, and a single payment. Travel is not that.
Pre-Authorisation and Delayed Capture
Hotels take deposits at booking and capture the full amount at check-in — or later. Car rental companies pre-authorise a hold that exceeds the booking value (for damage deposits) and capture a different amount at return. Airlines may pre-authorise at the point of booking and only capture once the ticket is issued.
These aren't edge cases. They're the default flow. Any travel payment infrastructure that doesn't support pre-auth, incremental auth, partial capture, and delayed settlement is fundamentally incomplete.
Multi-Party Settlement
A single travel booking can involve multiple suppliers. An OTA sells a package: flight from one airline, hotel from a chain, airport transfer from a local operator, and travel insurance from an underwriter. Each party needs to be settled separately, in different currencies, on different timelines.
The platform takes its commission. The airline settles through BSP (Billing and Settlement Plan). The hotel settles net of commission. The transfer operator settles weekly. One booking. Four settlement streams.
Payment infrastructure that only handles simple one-to-one merchant settlement can't support this.
Currency Complexity
Travel is inherently cross-border. A French customer booking through a UK-based OTA for a Thai hotel involves at least three currencies. The customer expects to pay in euros. The platform reports in pounds. The hotel settles in baht.
Currency conversion happens at multiple points — and each conversion point is either a cost centre or a margin opportunity. Competitive FX rates aren't a nice-to-have. They directly impact margin on every cross-border booking.
Chargebacks and Disputes
Travel has some of the highest chargeback rates in e-commerce. Bookings made months in advance. Services that don't match expectations. Cancellations. Schedule changes. Force majeure events that trigger mass refund requests.
Airlines face friendly fraud at scale — customers claiming flights weren't taken when they were. Hotels deal with no-show disputes. OTAs sit in the middle, managing disputes between customers and suppliers they don't control.
Payment infrastructure needs to handle dispute management, evidence submission, and chargeback representment across multiple PSPs — not just one.
Regulatory and Industry Mandates
Airlines operating through IATA-accredited agents must settle through BSP (Billing and Settlement Plan) or ARC (Airlines Reporting Corporation). This isn't optional. It's an industry requirement that dictates which acquirers and settlement mechanisms can be used for ticket sales.
Hotel chains with corporate PSP agreements mandate that bookings are processed through their designated acquirer — regardless of what the platform prefers. Regional regulations add another layer: PSD2/SCA in Europe, specific payment method requirements in APAC, local acquiring mandates in Latin America.
A single PSP can't satisfy all of these requirements. The math doesn't work.
The Multi-PSP Requirement
This is where travel payment processing diverges most sharply from standard e-commerce.
Airlines Mandate Specific Acquirers
Major airlines have contractual relationships with specific payment processors for ticket sales. When a travel platform sells airline tickets, the payment often must be processed through the airline's designated acquirer — not the platform's preferred PSP.
A platform selling tickets for ten airlines across three continents may need to support six different acquirers. Building and maintaining six PSP integrations is not a checkout feature. It's an infrastructure project.
Hotel Chains Have Corporate PSP Agreements
Large hotel groups negotiate enterprise-level PSP agreements with preferential rates. They require that bookings — even those made through third-party platforms — are processed through their designated processor.
The platform doesn't get to choose. The hotel's PSP agreement takes precedence.
Regional Payment Methods Are Non-Negotiable
Travel is a global business. Chinese travellers expect Alipay and WeChat Pay. Dutch customers default to iDEAL. Brazilians use PIX and Boleto. Japanese travellers use Konbini payments. Indian customers expect UPI.
A travel platform targeting international customers that only supports cards and PayPal is leaving conversion on the table. Regional payment methods aren't a nice-to-have — they're the dominant payment method in their respective markets.
The Integration Burden
Each PSP integration means:
A separate technical integration (API, webhooks, error handling)
Separate merchant onboarding and KYC
Separate reconciliation and reporting
Separate dispute management workflows
Separate compliance and certification maintenance
For a travel platform managing five to ten PSP relationships, this consumes a payments team of three to five engineers — permanently. That's engineering capacity not spent on core product: search, booking, pricing, supplier management.
The question becomes: should a travel platform be a payments company? For most, the answer is no.
Phone-Based Travel Payments
Despite the shift to online booking, a significant portion of travel transactions still happen by phone.
Group travel bookings. Corporate travel arrangements. Complex multi-leg itineraries. Booking modifications and additions. Customers who started online but need human help to complete.
Travel call centres handle high-value transactions daily. A corporate group booking for 40 people. A multi-city business trip with specific airline and hotel requirements. A family booking a month-long holiday with multiple components.
These aren't transactions that happen in a shopping cart. They happen in a conversation.
The PCI Problem on Voice Channels
Every time an agent takes a card number over the phone, the contact centre's PCI scope expands. The telephony system, call recordings, agent workstations, and network infrastructure all enter PCI scope.
For a travel call centre processing thousands of bookings weekly, maintaining PCI DSS compliance across the entire voice environment costs hundreds of thousands annually — before factoring in audit, remediation, and the operational overhead of PCI controls.
Secure Voice Payment Capture
DTMF-based payment capture solves this. The customer enters card details via keypad during the call. Tones are captured within a PCI-certified environment and suppressed from the audio stream. The agent stays on the line, guiding the customer through the booking, but never hears or sees card data.
The contact centre's PCI scope drops from SAQ-D (300+ requirements) to SAQ-A (roughly 20 requirements). The compliance burden shifts to the payment provider.
For travel platforms with call centres — which is most of them at any meaningful scale — voice payment capability isn't an add-on. It's core infrastructure.
Payment Links as Fallback
When DTMF capture isn't practical (customer on a landline without keypad, international call quality issues, customer preference), SMS or email payment links provide a secure alternative. The agent sends a branded payment link during the call. The customer completes payment on their device — supporting cards, digital wallets, and local payment methods — while the conversation continues.
This covers the full range of phone-based travel payment scenarios without any card data entering the platform's environment.
Three Approaches to Travel Payment Infrastructure
1. Build Custom
What it involves: Integrate each required PSP directly. Build currency conversion logic. Develop pre-authorisation and delayed capture flows. Create reconciliation systems for multi-party settlement. Build PCI-compliant infrastructure for voice channels. Maintain everything.
Timeline: 18-24 months to reach production parity with what a payment layer provides out of the box. Then ongoing maintenance, version upgrades, and new PSP integrations as requirements change.
Cost: $2M+ for PCI DSS Level 1 compliance alone. Three to five full-time payments engineers. Ongoing maintenance running $360K+ annually.
When it makes sense: Almost never — unless payments are your core business. Travel platforms exist to sell travel, not to build payment infrastructure.
2. Single PSP with Add-Ons
What it involves: Standardise on Stripe, Adyen, or Checkout.com. Use their multi-currency support. Rely on their acquiring network. Add third-party tools for voice payments if needed.
Where it works: Simple OTAs with limited geography, selling primarily their own inventory, targeting customers in one or two regions.
Where it breaks: The first time an airline mandates a different acquirer. The first time a hotel chain requires processing through their corporate PSP. The first time you need Alipay for the Chinese market and your PSP's coverage is weak in APAC. The first time an enterprise client demands a gateway you don't support.
Single-PSP works until your business outgrows it. For travel platforms with enterprise ambitions, that happens fast.
3. Payment Layer
What it involves: A single integration point that sits between the platform and multiple PSPs. The platform integrates once. The payment layer handles PSP routing, currency conversion, pre-authorisation flows, multi-channel support (embedded checkout, voice, payment links), and PCI compliance.
How it works: Configure which PSP handles which region, product type, or supplier requirement. Add new PSPs through configuration, not code. Route payments based on currency, geography, airline mandate, or hotel chain requirement. Handle voice payments and payment links through the same integration.
Timeline: Weeks, not months. Single API integration. PSP configuration handled at the platform level.
Trade-off: You're adding a dependency. But you're replacing five to ten PSP dependencies (each requiring separate integration, maintenance, and compliance) with one.
What Travel Platforms Need from Payment Infrastructure
Not every travel platform needs every capability. But at scale, the requirements converge:
Multi-PSP with regional routing. Route payments to the right PSP based on geography, airline mandate, hotel chain requirement, or payment method. Add new PSPs without re-integration.
Multi-currency with competitive FX. Handle tourist-pays-in-home-currency, platform-settles-in-reporting-currency, supplier-receives-in-local-currency. FX rates that don't eat your margin.
Pre-authorisation and delayed capture. Support hotel deposits, car rental holds, and booking-to-ticketing flows where authorisation and capture happen at different times.
Split payment support. Route funds to multiple parties from a single booking — supplier, platform commission, insurance provider, transfer operator.
Voice payments for call centres. PCI-compliant DTMF capture with tone suppression. Agents stay on the call. Card data never enters your environment.
Payment links for booking confirmations. Branded payment links sent via SMS, email, or chat. Supports cards, digital wallets, and local payment methods. Useful for deposits, balance payments, and post-booking additions.
PCI DSS Level 1 compliance. Non-negotiable. Travel platforms handling card data across multiple channels need Level 1 — the highest certification tier. Building this yourself costs $2M+. A payment layer includes it.
White-label checkout. Customers see the travel platform's brand throughout the payment experience. No redirects to third-party checkout pages. Consistent with the booking flow.
Implementation: What It Actually Looks Like
For platforms evaluating a payment layer approach, the integration is simpler than the problem it solves.
Single API integration. One set of endpoints for payment creation, capture, refund, and status. The platform's booking system calls the payment API. The payment layer handles PSP routing, currency conversion, and compliance.
PSP configuration per region and product. Define routing rules: European hotel bookings go through Acquirer A, airline tickets through the airline's mandated processor, APAC bookings through a regional PSP with local payment method coverage. Configuration, not code.
Currency handling. Specify the customer's preferred currency, the settlement currency, and the reporting currency. The payment layer handles conversion at each point. Transparent FX rates visible in the merchant portal.
Pre-authorisation flows. Create a pre-auth at booking. Capture (full or partial) at the appropriate trigger — check-in, ticket issuance, service delivery. Release unused holds automatically based on configurable timeouts.
Webhook notifications. Real-time notifications for payment events — authorisation, capture, refund, chargeback — pushed to the booking system. The platform's workflow engine reacts to payment events without polling.
Merchant portal. White-label dashboard for transaction monitoring, refund processing, dispute management, and reconciliation. Configurable per merchant or per supplier.
The integration typically takes a single developer one to two weeks. PSP configuration and testing add another week. Compare that to 18+ months of custom build.
The Cost of Getting This Wrong
Travel platforms that underestimate payment complexity pay for it in predictable ways.
Lost bookings. Customers abandon checkout when their preferred payment method isn't available. In markets where local payment methods dominate (China, Netherlands, Brazil, India), card-only checkout is a conversion killer.
Failed airline partnerships. Airlines that mandate specific acquirers won't work with platforms that can't support them. No PSP flexibility, no airline inventory.
Engineering drag. Every new PSP integration consumes engineering capacity. Every PSP API change requires maintenance. Every compliance upgrade requires remediation. Payments become a permanent tax on the product roadmap.
Compliance exposure. Operating voice payment channels without proper PCI controls creates liability that scales with transaction volume. One breach can cost more than years of infrastructure investment.
Margin erosion. Poor FX rates on multi-currency transactions compound across millions of bookings. A 50-basis-point difference on currency conversion across $100M in annual bookings is $500K in lost margin.
Conclusion
Travel payment infrastructure is not a checkout problem. It's an infrastructure problem — multi-PSP, multi-currency, multi-party, multi-channel — that compounds as the platform scales.
Building it from scratch is expensive and slow. Relying on a single PSP works until it doesn't. And the gap between "works for now" and "works at scale" is where travel platforms lose bookings, airline partnerships, and engineering momentum.
A payment layer approach gives travel platforms multi-PSP routing, multi-currency handling, voice and link payment channels, and PCI compliance through a single integration — without turning the platform into a payments company.
If your travel platform is wrestling with multi-PSP mandates, multi-currency complexity, or the cost of maintaining payment infrastructure across channels, that's the problem Shuttle was built to solve.
[Book a Call] | [See How It Works]