How to Build an Offer & Order Airline Reservation System

Why is it still easier to buy a phone online in one click than to change a flight online after a booking, without having to phone a contact center, trigger a ticket reissue, or see systems fight each other about what you actually ordered?

Anyone who’s ever had to integrate airline retail and servicing systems knows that, when you scratch beneath the surface of a smooth customer experience, you find a reality where customer data is often represented across multiple records, and multiple system lifecycles. This makes something as simple as “add one bag, keep one seat” surprisingly hard to get right.

The push to 100% Offers and Orders is a bet that airlines, and eventually all transportation providers, are now able to think and act like retailers, making Offers, taking Orders, and servicing those Orders across distribution, delivery, and accounting systems alike.

This is a practical, engineering-led introduction to implementing an Offer & ONE Order ‘happy path’ airline reservation system, which can be extended to rail and ground transportation too.

We'll look at:

What’s hard for airlines today, and how Offer & Order, and ONE Order, address those challenges
A practical reference architecture, rather than a nice idea
How to implement a first vertical slice, including one Offer, one Order
How to chunk a large change program into more digestible pieces, and retire legacy systems safely
The hardest problems (performance, servicing, interline, finance) and patterns to solve them

(To keep this realistic, I will use a “composite airline” example based on general industry patterns and publicly available standards documentation, rather than specific implementations.)

The uncomfortable truth: airlines are not “retailing” yet; they are reconciling

Airline IT infrastructure was built to perform best in a world where:

A fare is filed, not computed
Distribution happens through legacy channels with payload constraints
A booking record is not the purchase record
Ancillaries are added after the fact

Airlines have traditionally had different IT infrastructure evolution paths. Instead of having a single purchase record, there are multiple artifacts and concepts that were introduced during the era of process design.

Even today, in 2026, the industry still has to live with constructs that were introduced during the paper era. According to IATA’s ONE Order Factsheet, the vision for ONE Order is to “simplify the industry by consolidating PNRs, e-tickets, and EMDs into a single unified record - the Order - removing inefficiencies inherited from paper-based processes to ensure improved communication between order management, revenue accounting, and delivery.”

From an engineering perspective, this is not a “format change.” This is a domain model change.

And this is a contentious issue for good reasons:

From an engineering perspective: “Is this a big rewrite?” “Will we be locked in?”
From a distribution perspective: “Are we ready?” “Is the ecosystem ready?”
From a finance perspective: “Settlement?” “Auditability?” “Revenue recognition?”
From an operations perspective: "How will disruptions be handled?" “Airport delivery?”

These are legitimate concerns - Offer/Order is not a system; it is a process transformation.

This is evident from IATA’s definition of ONE Order: The objective of ONE Order is to facilitate a simplified reservation, delivery, and accounting process by progressively replacing existing booking, delivery, and accounting records such as PNRs, e-tickets, and EMDs with a single record for retail and customers.

That’s important because duplication is not just ‘messy’; it’s costly and risky:

Servicing is reconciliation. You don’t ‘change an order’; you ‘synchronize multiple documents.’
Customer support is archaeology. Agents and systems search for references across systems.
Finance is brittle. Ticket/EMD-based systems aren’t naturally aligned with modern retail bundles, non-air content, or dynamic changes.

That’s why airline ecommerce can appear like ‘a front-end rewrite over a legacy truth.’ It may look modern, but still function like a document processing system.

What IATA means by Offer/Order (and where NDC and ONE Order fit)

There’s a lot of jargon in the airline ecommerce space, so let’s clarify the important bits:

Offer

An Offer is a priced, sellable offer created for the customer in the context of route, dates, availability, customer attributes, loyalty, channel, etc.

It’s similar to an ecommerce cart offer:

It includes items (flight, seat, bag, bundle, lounge, carbon offset, etc.).
It includes pricing, conditions, and an expiry/validity window.
It’s transient; you should expect an Offer to expire or change.

Order

An Order is the single source of truth for what the customer bought, what they’re entitled to consume, over the lifecycle of the trip.

ONE Order’s central idea is exactly that: take the ‘legacy booking/ticketing’ elements and merge them into one Order.

NDC (distribution with Offers and Orders)

The IATA NDC standard defines the distribution protocol that enables Offer/Order to be used throughout the distribution chain via an API. According to the NDC Factsheet: “…the NDC standard enables sellers to shop, order, pay, and service using Offer and Order processes.”

Modern Airline Retailing (the larger narrative)

IATA defines the larger narrative of Modern Airline Retailing as follows: “Modern Airline Retailing is the larger narrative of the journey to modern retailing, supported by NDC, ONE Order, and other standards… to move away from legacy artifacts to a world of ‘100% Offers and Orders.’”

A reference architecture for an Offer/Order-based reservation system

Here’s a simple architecture that should work for airlines and can be extrapolated to rail/ground transport as well.

Core Domains (Bounded Contexts)

Product Catalog & Merchandising
1. Defines products (fare families, bundles, seats, bags, WiFi, upgrades, etc.)
2. Owns content, eligibility rules, sellability constraints
Pricing
1. Computes prices, promotions, taxes/fees
2. Supports continuous/dynamic pricing strategies (even if filed fares are used)
Availability & Inventory
1. Seat inventory, O&D controls, capacity management, waitlists
2. “Reserve” vs “commit” semantics
Offer Management
1. Combines products + prices + availability to create Offers
2. Issues Offer IDs, TTLs, terms/conditions references
Order Management (ONE Order-aligned)
1. Stores Orders, Order Items, services/entitlements, Order States
2. Owns servicing (change, cancel, refund, split/merge scenarios)
Payments & Risk
1. Auth/capture/refund
2. Fraud detection, 3DS, wallet support
Delivery/Fulfillment
1. Check-in/DCS integration, vouchers/credentials
Accounting & Settlement
1. Revenue accounting, invoicing
2. Settlement mechanisms (eventually aligned to Orders)

Cross-cutting capabilities to design early

Identity/customer context (loyalty, corp policy, digital identity alignment to follow)
Observability & audit (very important for finance and servicing teams)
Eventing (OrderCreated, OrderPaid, OrderChanged, etc.)

Integration principle

The “retail layer” should remain decoupled

You can implement Offers/Orders as a retailing layer around the original PSS components, at least initially, using adapters. This is how you avoid the “catastrophic replacement of everything at once” scenario.

Reason why the architecture is applicable to rail, ground transport, etc.

Rail, ground transport, etc. are also inventory + entitlement businesses.

Inventory could be seat inventory, zone inventory, capacity inventory, etc.
Entitlement could be QR code, gate, driver, etc.
However, the overall “Offer -> Order -> Deliver -> Service -> Refund” process is the same.

The difference is operational delivery, not the model.

Implementing the first vertical slice: one Offer -> one Order

You can’t possibly “do ONE Order” across all the scenarios. It’s not possible. The way to win is to deliver a thin but complete way through the system.

Step 0: pick a narrow “happy path”

Pick something boring.

Single airline, no interline/codeshare.
One way
One passenger, ADT
Card payment
No exchanges, Cancellation allowed
Minimal ancillaries e.g., one bag

It’s not that you’re compromising. It’s that you’re building the extensibility.

Step 1: define your internal domain model (don’t start with XML)

NDC is based on XML.

Which means your internal systems don’t have to be.

A good way forward:

You can model your Offers, Orders using a language-native domain model. JSON, protobuf, POJOs.
You can provide mappers from/to NDC messages.

You’re optimizing for evolvability, not a schema tree.

Step 2: implement Offer creation

Offer creation flow

POST /offers/search with origin, destination, dates, pax, cabin preferences.
Offer service calls:
1. Availability: “what can I sell?”
2. Pricing: “what price should I quote?”
3. Catalog: “what products/bundles are eligible?”
Return one or more Offers with:
1. offerId
2. expiresAt
3. list of offerItems
4. total price + breakdown

Example internal Offer (simplified)

{   
"offerId": "OFF-7F3A9C",   
"expiresAt": "2026-01-02T12:05:00Z",   
"passengers": [{ "paxId": "P1", "ptc": "ADT" }],   
"items": [     
{       
"offerItemId": "OI-1",       
"type": "AIR",       
"segments": [{ "from": "FRA", "to": "BCN", "dep": "2026-02-12T09:10:00Z" }],       
"termsRef": "TNC-BASE-ECO",      
 "price": { "currency": "EUR", "total": "189.90" }     
},     
{       
"offerItemId": "OI-2",       
"type": "ANCILLARY",       
"service": "CHECKED_BAG_1",       
"price": { "currency": "EUR", "total": "25.00" }     
}   
],   
"total": { "currency": "EUR", "total": "214.90" } 
}

Key engineering decisions you should make early:

Offer TTLs: treat Offers as quotes with expiry.
Idempotency: every offer search should be idempotent-friendly (especially for retried requests).
Offer “fingerprint”: store enough context to revalidate quickly.

Step 3: implement Order creation (ONE Order-style “single record”)

Order creation flow

Client submits selected Offer Items:
1. POST /orders with offerId + offerItemIds + passenger details + payment method.
Order service runs a saga:
1. Revalidate Offer (TTL, price, eligibility)
2. Reserve inventory (temporary hold)
3. Authorize payment
4. Commit order
5. Confirm inventory
6. Trigger fulfillment (during migration this may mean “issue ticket/EMD downstream”)

Example internal Order (simplified)

{   
"orderId": "ORD-91B2E1",   
"status": "CONFIRMED",   
"customer": { "name": "A. Traveler", "email": "a@example.com" },   
"orderItems": [     
{ "orderItemId": "IT-1", "fromOfferItemId": "OI-1", "status": "ACTIVE" },     
{ "orderItemId": "IT-2", "fromOfferItemId": "OI-2", "status": "ACTIVE" }   
],   
"payments": [     
{ "paymentId": "PAY-77", "status": "AUTHORIZED", "amount": { "currency": "EUR", "total": "214.90" } }   
],   
"entitlements": [     
{ "type": "FLIGHT", "segmentRef": "S1" },     
{ "type": "SERVICE", "code": "CHECKED_BAG_1" }   
] 
}

This matches the ONE Order intent – one record of entitlements, eliminating duplication.

Step 4: bridge to legacy (without letting legacy own your model)

The not-negotiable truth is that most airlines can’t switch off legacy operational delivery and accounting in one go.

So, what does this mean? The migration pattern that works is:

Order is the source of truth
Legacy records (PNR/ticket/EMD or equivalents) are derived artifacts, created only when required by downstream systems

This is consistent with IATA’s goal to phase out legacy records in favor of a single order record.

In other words, create an Order to Legacy Adapter:

Translate Order Items into downstream issuance steps
Store these mappings (orderId to legacy references)
Make it replayable (what if downstream fails?)

Over time, shrink this adapter as more issuance and accounting become native to Orders.

Step 5: implement minimal servicing

First, implement these minimum servicing APIs:

GET /orders/{orderId}
POST /orders/{orderId}/cancel (with refund rules)
POST /orders/{orderId}/add-service (add bag/seat)

Servicing is where all the complexity will come – so start with one or two to prove the flow.

Making “the big bang” into tangible projects

What does a transformation plan look like? It’s a sequence of individually valuable projects:

Domain model + API façade
1. Define Offer/Order canonical model and API contracts.
2. Map to NDC at the edge.
Offer creation for one channel
1. Start with direct web/mobile.
2. Add basic ancillaries.
Order store as the source of truth
1. Create/read Orders.
2. Start emitting events (OrderCreated, OrderPaid, OrderCancelled).
Payments + refund automation
1. Move refunds from manual queues into deterministic workflows.
Order servicing expansion
1. Add change flows, partial cancels, split orders.
Operational integration
1. DCS delivery hooks, disruption workflows.
Finance integration
1. Revenue accounting and settlement processes aligned to Orders.
Partner distribution and interline
1. Expand to agencies and interline/codeshare once the core is stable.

This is the “strangler” approach: new capabilities grow around legacy until legacy becomes a small compatibility layer.

Key challenges airlines hit (and how to solve them)

1) Look-to-book and performance: Offers are expensive to compute

Dynamic offer generation can trigger huge search volumes and strain systems. IATA’s Look-to-Book white paper explicitly calls out a surge in search volumes that drives up LTB ratios and strains systems, costs, and customer experience.

Patterns to use:

Two-tier caching: cache “market” availability/pricing, then personalize at the edge
Offer-to-order metrics: measure CPU-to-order, offer-to-order, not just requests/sec
Rate limits with graceful degradation: don’t fail; return fewer offers, longer TTLs, or precomputed bundles

2) Consistency between offer pricing and order creation

Problem: your Offer is computed at time t, but at time t+30s inventory, taxes, or promotions change.

Solutions:

Put a validity window on Offers.
Reprice on order creation with explicit rules:
- “Honor price if within TTL and inventory unchanged” vs “always reprice.”
Use inventory holds with clear expiration and idempotent commit.

3) Servicing complexity replaces ticketing complexity - if you don’t design it

Problem: If you model Orders like “a PNR, but renamed,” servicing ends up being a nightmare.

Solutions:

Servicing should be state changes on Order Items (ACTIVE, CHANGED, CANCELLED, REFUNDED).
Immutable financial data (payments, refunds) and deltas from events.
Sagas for servicing changes: reserve, price, pay delta, commit.

4) Transition pain: you still need legacy artifacts

Problem: You can’t change airports, interline partners, and accounting practices in an instant.

Solutions:

Legacy issuance should be downstream and replaceable:
- “Order first, then derive ticket/EMD where required.”
Build a reconciliation dashboard early on:
- Order vs PNR vs ticket vs EMD mapping
- Status and failure replays

5) Ecosystem interoperability

Problem: Even after you agree on a profile, you may not know how your trading partners will implement it. And the whole industry ecosystem is affected by the rollout of ONE Order (PSS suppliers, travel agents, GDSs, and even non-air players like rail, hotel, car rental).

Solutions:

Choose a profile and commit to it (what you support, and what you don’t).
Versioning of your APIs.
Provide “capabilities discovery” endpoints to support your trading partners.

6) Organizational design becomes a technical dependency

Problem: Offers/Orders span distribution, revenue management, servicing, and financials.

Solutions:

Think of this as a product transformation, not an API project.
Own the Offer/Order within a single organizational structure (business and technology).
How to measure success:
conversion rate, attach rate, change cost, refund cycle, call deflection

Why this approach extends beyond airlines (rail, ground, and multimodal)

The Offer/Order model is not “airline-only.” It’s retailing applied to transport:

Rail: seat + fare families + onboard services = Offer; ticket + seat + meal entitlement = Order.
Ground transport: route + baggage + priority boarding = Offer; QR credential + entitlement list = Order.
Multimodal: a single Order can represent entitlements across operators - if you design Order Items and fulfillment boundaries cleanly.

And as a side note, IATA itself points out that “modern retailing with Offers and Orders” has a “broader industry implication” that “extends beyond airlines to include rail and other non-air services.”

The takeaway here should be that you shouldn’t “implement IATA.” Instead, you should “implement commerce” with IATA as a guiding star

The pitfall here is that people think that Offer/Order is a standards-compliance exercise. The opportunity here is that Offer/Order can be a way for you to achieve:

One Offer engine that can personalize and bundle.
One Order record that can eliminate record-sync failures and make servicing sane.
One way to achieve ecommerce-grade experiences across channels and partners.

So yes, start with one Offer and one Order. Make that real. Then grow from there

Because once you achieve that one Order that can be the truth, all other “modernization initiatives” such as payments, disruption handling, interline, finance, etc. finally have “something” to orbit

Note that this article only scratches the surface of implementing IATA Offer/Order and ONE Order. In a real-life airline, there can be many differences in architecture, data model, process, and migration depending on many factors such as detailed business needs, regulatory requirements, commercial models, partner ecosystems (such as interline/codeshare), and airline-specific operational realities.