Published 2026-05-05
Offers and Orders in NDC Explained
A simple explanation of the Offer and Order model and why it matters for airline retailing workflows.
The Offer and Order model is central to NDC. An offer is what the airline proposes to sell at a point in time. An order is the record of what the traveler has bought after the booking is completed. Separating these two ideas helps teams design cleaner shopping, booking, and servicing flows because each stage has a different purpose.
An offer belongs to the shopping and decision stage. It can describe flights, brands, included services, optional ancillaries, prices, penalties, and rules. The offer may be built by the airline based on route, availability, traveler context, or commercial logic. For the seller, the key responsibility is to display the offer in a way that supports comparison and avoids hiding important conditions.
Offers are not permanent. Availability can change, seats can sell out, and pricing can move. That is why many NDC workflows include a price confirmation step before order creation. The confirmation step helps validate that the user is still buying the same product at the expected price. It also gives the seller a clear moment to show final details before payment.
An order begins after the offer is accepted and the booking succeeds. The order should describe the confirmed products, passengers, services, payment state, and fulfillment state. It is the record that support teams and automated systems use after the sale. If the order state is unclear, every post-booking workflow becomes harder to operate.
The order model matters most during servicing. Cancellation, refund, exchange, schedule change handling, and adding ancillaries all depend on retrieving the order and understanding what can be changed. A seller cannot design reliable servicing by only focusing on shopping. The operational value comes from being able to manage the order after the initial sale.
For technology teams, the lesson is to build the internal model around the full lifecycle. Store enough offer context to explain what was selected, but treat the order as the authoritative post-booking record. Track identifiers carefully because airline, aggregator, and seller systems may each use their own references. Good identifier mapping saves hours during support investigations.
A simple mental model helps: the offer answers: what can the traveler buy right now; the order answers: what has the traveler bought and what can happen next. When teams keep that distinction clear, NDC implementations become easier to reason about, test, and support in production, especially when multiple airlines and servicing paths are involved across real customer journeys.