RCH Technologies

How Airline Reservations Work

And Where Payments Sit In The Flow

Booking a flight may seem simple from a passenger’s perspective, but behind the scenes, it involves a carefully coordinated process that ensures seat availability, secure payment, ticketing, and financial reconciliation. This system balances the airline’s need to protect inventory with the customer’s expectation of a smooth and reliable booking experience.

In short: a successful reservation is the result of a series of automated steps all designed to make flying reliable and stress-free

Traditional Airline Booking Lifecycle

A system-level view of how airline reservations progress from inventory hold to financial reconciliation after a customer clicks purchase

1. Book

A temporary reservation is created to hold inventory while the customer commits to purchase.

  • Flight segments sold from inventory
  • PNR created in PSS/GDS
  • Fare, taxes, and rules stored
  • Ticketing Time Limit (TTL) applied

System state: Inventory held, not sold
Customer view: “Seats reserved”

2. Pay

Funds are collected or guaranteed before any ticket can be issued.

  • Credit/debit cards, wallets
  • Asynchronous methods (A2A, BNPL, pay-by-link)
  • 3DS, fraud, and compliance checks
  • Payment callbacks / webhooks supported

System state: Payment successful or guaranteed
Customer view: “Payment received / pending”

3. Ticket

The airline issues the e-ticket, creating the legal right to travel.

  • E-ticket number generated
  • Ticket linked to PNR
  • Inventory permanently confirmed
  • Passenger eligible for check-in

System state: Booking confirmed
Customer view: “Booking confirmed”

4. Stamp

Post-ticket financial validation and reconciliation.

  • Form of Payment stamped against ticket
  • Revenue accounting updated
  • BSP / ARC / corporate settlement prepared
  • Audit and reporting flags set

System state: Financially finalised
Customer view: No visible change

A booking is only confirmed when the ticket is issued.
Stamping is a post-ticket financial process and does not affect the passenger’s right to fly.

Pay → Ticket Transition Times

How long it typically takes for a booking to move from payment success to ticket issuance.

Synchronous Payments

Payments processed in real-time (credit/debit cards, Apple Pay, Google Pay).

  • Payment authorization and capture immediate
  • Ticketing usually triggered automatically
  • Customer sees booking confirmation within 5–120 seconds

Notes: Automatic ticketing enabled → minimal delay; GDS latency can add a few seconds.

Fast Asynchronous Payments

Payments via bank transfer, pay-by-link, or fast BNPL providers.

  • Payment confirmation arrives via webhook or polling
  • Retail/order layer validates before ticketing
  • Typical Pay → Ticket time: 1–30 minutes

Notes: TTL for PNR must account for potential delays; customer sees “Seats reserved while payment is processed.”

Slow Asynchronous Payments

Bank transfers with delays, or certain BNPL schemes with manual approvals.

  • Pay → Ticket can take 1–72 hours
  • PSS may hold PNR until payment confirms
  • Risk of TTL expiry if confirmation is slow

Notes: Manual intervention or retries may be required; customer is informed that booking is pending.

Key Points:
- Faster payment methods = near-instant ticketing
- Asynchronous payments introduce delays and require TTL management
- Display provisional references to reduce customer abandonment

Airline Booking Flow with Pre-Authorization

How Pay-first (authorization-only) integrates with Book → Ticket → Capture → Stamp

1. Pay (Authorize)

Customer authorizes payment without immediate capture.

  • Authorization hold placed on card / wallet
  • Amount reserved but not yet charged
  • Authorization ID stored in Retail

State: AUTHORIZED
Customer view: “Payment authorized, will be captured after ticketing”

2. Book

Attempt to create PNR and hold seats in PSS/GDS.

  • PNR created if successful
  • Inventory held temporarily
  • TTL applied to booking

Failure: Book fails → PNR not created
Action: Release authorization, notify customer

3. Ticket

Issue e-ticket after successful booking.

  • E-ticket number generated and linked to PNR
  • Inventory permanently confirmed
  • Customer eligible for check-in

State: TICKETED
Customer view: “Booking confirmed”

4. Capture Payment

After ticketing succeeds, authorized payment is captured.

  • Authorization ID used to capture funds
  • Amount charged to customer
  • Integration with accounting / billing

State: CAPTURED
Customer view: “Payment successful”

5. Stamp

Post-ticketing financial reconciliation.

  • Payment recorded against ticket in accounting
  • Revenue recognized and BSP/ARC settled
  • Audit flags updated

State: STAMPED
Customer view: No visible change

Failure Handling:
- Book fails → release authorization, notify customer, allow retry
- Payment authorization expires → prompt customer to re-authorize
- Ticketing fails → do not capture, retry or escalate
- Stamp is independent, performed after capture

Key Points:
- Pre-authorization protects the airline from inventory risk
- Authorizations are cancelled if booking or ticketing fails
- Funds are only captured after ticket issuance

CONTACT

Contact us and we'll get back to you within 24 hours.

Swords, Co. Dublin, Ireland

+353 86 3118747

rachel@rchtech.ie