Payments Consume Up to 78% of Airline Industry Net Profit. Time to Fix That
Airlines process about one trillion dollars in payments each year on net margins of 2–3%. McKinsey puts payment costs at $22 billion per year, or about 78% of combined industry net profit. A misrouted transaction, a day of manual reconciliation, a declined cross-border card: each one drains revenue in a business where the profit-loss gap comes down to dollars per passenger. This is not a back-office problem. It is a structural challenge embedded in airline payment architecture, one that demands specialized expertise to address systematically. API-driven payment orchestration is an architectural answer to this challenge – a decision that determines whether your payment stack makes money or burns it.
Why Now
Three forces press on airline payment infrastructure at once.
Alternative payment methods keep gaining ground. Worldpay’s 2025 Global Payments Report puts digital payment volume at $18.7 trillion in 2024, up from $1.7 trillion in 2014, with projections of $33.5 trillion by 2030. Airlines that accept cards alone lose customers in markets where UPI, Pix, or Alipay+ are the default payment instruments. The payment infrastructure must keep pace with the distribution landscape or the revenue gap widens with every new market entered.
Regulatory pressure is intensifying. PSD2 Strong Customer Authentication requirement introduced mandatory multi-factor verification across European transactions, increasing checkout timeouts and abandoned sessions, especially on complex itineraries where a passenger must locate a secondary verification device mid booking. PSD3 and the Instant Payments Regulation (IPR), which requires SEPA banks to offer 24/7 instant transfers, follow close behind. Each regulatory change adds compliance obligations that legacy stacks cannot absorb without architectural change.
Ancillary revenue keeps growing. For many carriers, baggage fees, seat selection, and lounge access now account for 30–40% of total revenue, according to IATA. These transactions occur across different channels, currencies, and time windows after the initial booking, and each one requires reconciliation against the original order record. Legacy payment stacks were not designed for this model, and the operational cost of forcing them to support it grows with every new ancillary product introduced.
Together, these forces turn monolithic payment stacks, assembled piece by piece over decades – from operational inconveniences into strategic bottlenecks. Below is how orchestration addresses the problem at the architectural level.
The Mechanics of Orchestration
How a Typical Airline Payment Stack Works Before Orchestration
Most airline payment infrastructure was never designed as a system. It accumulated. A processor for home markets. A fraud engine layered on later. Currency conversion from a third vendor. Routing logic stitched on top. No single system sees the full transaction lifecycle: payment data sits fragmented across orchestration layers, fraud tools, the PSS, and finance ledgers, each with different identifiers, timestamps, and status mappings.
Finance teams spend days on monthly reconciliation, matching records by partial keys: authorization IDs, order IDs, processor references. Month-end close turns into a multi-day investigation of mismatches between captured amounts, settled funds, and recorded revenue. Authorization rates suffer not because customers abandon the purchase, but because rigid routing in legacy systems forces international transactions through a single acquiring path that underperforms on cross-border cards. The result: declined payments and lost bookings across web, mobile, and contact center channels.
What an Orchestration Platform Changes
Payment orchestration is a programmable middleware layer between the airline’s commerce systems (booking engine, mobile app, contact center) and external payment service providers. The key word is programmable: you configure routing logic, retry rules, fraud thresholds, and currency behavior through APIs instead of hardcoding them into vendor contracts.
Four components deliver the most immediate value. An intelligent routing engine selects the best acquirer per transaction based on card type, currency, geography, and real-time authorization performance. A tokenization vault cuts PCI DSS scope and enables stored-credential flows for post-booking ancillary upsells. Cascading retries reroute declined transactions to alternative acquirer paths before the customer sees an error. Unified reporting consolidates data from all PSPs into a single reconciliation feed.
Before and After: Payment Stack Comparison
| Parameter | Legacy Stack | With Orchestration |
| Routing | Fixed, one acquirer per region | Dynamic, based on real-time authorization performance |
| Retries | None or manual | Automated cascade across backup acquirers |
| Adding a new payment method | Months of direct integration | Days via platform connector |
| Reconciliation | Manual, 3–5 days/month | Automated, hours |
| PCI scope | Broad, card data across multiple systems | Reduced via network tokenization |
| Refunds on flight cancellation | Manual intervention for split payments | Automated via webhook triggers to PSPs |
Airline-Specific Complexity: Where Generic Solutions Fall Short
Two scenarios from my direct implementation work illustrate why generic orchestration platforms require deep aviation-specific customization to deliver full value.
Post-booking ancillary purchases present the first challenge. A passenger purchases a ticket, then adds priority boarding and an extra bag through the airline mobile application 48 hours later. This transaction references stored credentials established at booking, may involve a different currency if the passenger has traveled internationally, and must reconcile against the original PSS order record. I have designed and configured these multi-step payment journeys, mapping API event sequences that link the initial authorization to downstream ancillary captures – a process requiring precise understanding of both the orchestration platform’s data model and the airline’s PSS integration layer.
Flight disruption and cancellation handling present the second. When a flight cancels, the payment layer must initiate refunds not to the original card alone, but potentially across multiple payment methods – card plus miles, or split across two cards – against bookings that may have been modified since the original transaction. Without orchestration, each disruption event triggers manual intervention from the payment operations team. With properly configured orchestration, refund workflows execute through webhook-driven API calls to the relevant PSPs, initiated automatically by the cancellation event in the PSS. I have implemented these workflows for airline clients, reducing disruption-related payment operations from hours of manual work per event to automated execution.
What Implementation Looks Like
Orchestration deployments are not plug-and-play projects. In my experience managing these integrations, the organizational complexity matches and frequently exceeds the technical challenge. This distinction matters because it is the primary reason implementations extend beyond initial timelines and because addressing it requires a different skill set than technical integration alone.
On the technical side, the key integration points are the PSS, the airline’s digital booking channels, and the acquirer/PSP network. Each connector requires mapping the orchestration platform’s data model to the airline’s existing transaction schema: API specification work, endpoint testing across payment method types and currencies, and sandbox validation before any production traffic routes through the new layer.
The organizational challenge is less bounded. Payment modernization requires aligned requirements from finance, IT, revenue management, and compliance. In my experience managing these cross-functional integrations, establishing a shared data model early – agreed upon by both finance and technical stakeholders before integration work begins – is the single most effective timeline control available, because divergent assumptions about data identifiers and settlement timing are the most common source of reconciliation failures in early production.
Maturity Framework: Three Levels of Payment Modernization
| Level | Description | Typical Outcome |
| Level 1: Connection | Orchestrator replaces point integrations; routing logic remains static | Faster reconciliation, simplified PCI scope. Minimal authorization uplift |
| Level 2: Optimization | Dynamic routing and cascading retries enabled; acquirer A/B testing | Authorization uplift of 3–8 pp, measurable cost reduction |
| Level 3: Productization | Payments embedded in commercial strategy: personalized methods, BNPL, subscriptions, data-driven pricing | Payment stack generates new revenue |
Most airlines stop at Level 1, capturing operational improvement but no competitive advantage. Level 2 is a data and analytics challenge. Level 3 requires an organizational decision: payments stop being IT’s responsibility and become a product owned by a cross-functional team.
An underestimated risk sits at every level of this maturity progression. Organizations that deploy orchestration as an IT infrastructure project without changing the commercial and analytical model around payments acquire a new middleware layer while leaving the management model that produced the original problem unchanged. That unchanged model is what keeps a carrier from reaching Level 3. IATA estimates the industry could unlock about $14 billion in revenue uplift and cost savings by modernizing payment standards. That figure is achievable only for carriers who treat payments as a product, not as infrastructure maintenance.
One more observation that analytical reports seldom capture explicitly: NDC migration and payment orchestration are interdependent transformations. As airlines shift from GDS distribution to direct API-based offer and order management, the payment layer has to match that flexibility. An Offer & Order model requires handling partial payments, installment plan structures, and real-time settlement adjustments. Legacy PSP integrations support none of that. Airlines that deploy NDC without parallel payment modernization are building a commercial storefront without a functional checkout counter – a structural contradiction with direct revenue consequences.
Where to Start
A practical recommendation from my implementation experience: begin with routing optimization on your existing payment methods before adding new ones. Intelligent routing can deliver authorization uplift of 3–8 percentage points within weeks and build confidence before the more complex work of integrating local methods or BNPL begins. In parallel, an audit using IATA’s Airline Payment Index will pinpoint specific loss areas in authorization, cost, and reconciliation.
The organizational challenge matters as much as the technical one. Payment modernization requires alignment with finance (reconciliation and settlement), IT (API integration and security), revenue management (ancillary conversion), and compliance (PCI DSS, PSD2, local regulations). Establishing this alignment early – particularly around data residency obligations and tokenization scope decisions – is where experienced payment practitioners provide the most durable value, because these decisions determine both the compliance posture and the architectural boundaries of everything that follows.
Airlines that treat payments as a managed product – with defined performance metrics, measurable improvement targets, and architectural investment – are the ones capturing gains in conversion rates, cost efficiency, and speed to market. API-driven orchestration does not replace the acquirer and PSP relationships airlines have built. It makes those relationships programmable, measurable, and optimizable in real time.
The technical architecture is mature. The implementation path is documented. The remaining question is organizational will – the commitment to treat payments as a strategic capability rather than a cost center.
