Modern Airline Retailing fundamentals. A series of short explainers on MAR — the terminology, the structure, and what changes when airlines move from PNRs to orders.
The shift from PNR to Order fundamentally changes how you model what a customer has purchased, and it has real consequences for what you can and can't do at every stage of the journey.
Offers become Orders
In the OOSD world, everything starts with a search. Searching for availability returns offers. When a customer selects an offer and accepts it, that offer becomes an order. Offer ID typically becomes the Order ID. Where the old logic gave you a six-character alphanumeric PNR, the new one gives you an Order ID, which can be much longer and can carry internal structure that is meaningful to the systems using it.
What can live inside an Order?
This is where it gets interesting. Under a single Order ID, you can have:
- Multiple passengers travelling to different origins and destinations
- Passengers in different cabin classes within the same order
- Air ancillaries, airport ancillaries, retail add-ons
- Products and services with no connection to the flight at all, if an airline wants to sell it, it can live here
This is a significant departure from the PNR world. In the legacy model, everyone in the same booking had to be going to the same place in the same cabin. The order model removes that constraint entirely.
Orders → Order Items → Services
The structure has three layers.
The order is the top-level container — the thing with the Order ID, the customer's name, the payment record.
Order items sit in the middle. They usually represent a journey (more on that word in a moment), and they're how the order gets broken into meaningful chunks. Just as offers become orders, offer items become order items. When you add something new to an existing order (fast track, say, or lounge access), you'd search for it, get back an offer item, accept it, and that creates a new order item on the existing order.
Services are the granular things: the right to fly, a seat assignment, a baggage allowance, lounge access, a meal preference, wheelchair assistance. Everything a passenger is entitled to exists at this level.
Services also absorb what legacy systems handled as SSRs (Special Service Requests). If you need to communicate with a legacy system that expects an SSR, you can map a service to a PADIS SSR code. But you don't have to. The mapping is optional. This matters because it means you're no longer limited by what's in the PADIS code set — you can represent services that don't have a legacy equivalent, and you don't have to shoehorn things into codes that were never designed for them.
Note on "journey"
Journey has a specific technical meaning in this world, and it trips people up. A journey is a trip from an origin to a destination. It can have multiple segments or legs. A return trip is typically two journeys. An order item usually represents a journey, though additional services added later will create their own order items that reference the same underlying journey.
This also matters for baggage tracking: you track bags through the journey, not per leg or per segment.
Q: Is there a limit on the number of passengers or flights in a single order?
There's no absolute limit in the standard. In practice, there's a soft ceiling of around 200, but that's a performance consideration rather than a schema constraint. The intention is clearly to go well beyond what the legacy world allowed — PNR bookings were commonly capped at around 20 passengers.
Q: What about time — is there any limit on how far in advance or how long the travel can span?
Nothing in the standard limits that. In theory, you could have 200 people with a complex multi-destination itinerary all sitting under one order, with nobody travelling the same route. Any constraints on advance purchase windows or date ranges are decisions made by individual implementations — not imposed by the schema.
Q: What does this mean for systems that are built assuming the old constraints?
It means you have to be careful not to hard-code legacy assumptions. One airline's system might impose a limit; another won't. Systems that handle orders need to be built to handle that variability gracefully.