When shopping on platforms like Amazon, eBay, or Wayfair, people enjoy personalized offers, customized discounts, tailored recommendations, and other perks of modern retailing. Travelers have a similarly rich experience with an airline website.
But things are different when purchasing a flight via an online travel agency (OTA) or other third-party booking platform. In most cases, it’s impossible to buy more than a bare seat or to have detailed information about the airline and its services. Offer and order management, a foundation for IATA's New Distribution Capability (NDC) initiative, promises to change all that.
Our article discusses the importance of offer and order management for airline retailing and shares our experience and lessons learned from building an airline distribution hub with offer and order management functionality.
What is OOM?
In travel, offer and order management, or OOM, is a new way of selling air products via third-party platforms. To define terms, an offer here is a proposal generated by the airline in response to a traveler’s query, while an order, in turn, is a finalized purchase record also created by the carrier once the traveler accepts the offer.
In the traditional indirect distribution scenario, which still prevails today, the control over offers belongs not to airlines but to global distribution systems (GDSs). They aggregate information about flights from different sources to create proposals and pass them to OTAs or other resellers. The GDS offering relies on the pre-Internet EDIFACT protocol, which doesn’t support photos, videos, or detailed text descriptions.
Read our article on the flight booking flow or watch the dedicated video to better understand how traditional airline distribution works.
Flight booking flow explained
The NDC-driven OOM framework relies on modern XML messaging via APIs. It returns ownership over airline content to carriers, enabling them to propose a wide range of ancillaries showing photos of lounges and meals. It also creates a precondition for bundling and personalizing products, upselling and cross-selling, and applying other advanced retailing techniques. In other words, with OOM, airlines can present their offerings through resellers the way they already do on their own websites.
What is an offer and order management system?
An OOM system is a technical implementation of the concept. Basically, it’s middleware that sits between an airline’s passenger service system (PSS) and distribution channels. The functionality of a full-fledged system spreads the end-to-end merchandising process and, among other things, paves the way for:
- creating personalized offers;
- continuous pricing;
- BSP/ARC and card transactions;
- managing the entire lifecycle of orders; and
- sales reporting.
Unfortunately, the idea of OOM is far from being fully implemented at the industry level, so even with the right system in place, carriers still have to deal with EDIFACT-based artifacts such as passenger name records (PNRs), e-tickets, and electronic miscellaneous documents (EMDs) with information about purchased ancillaries. That’s why it’s critical for the OOM software to have backward compatibility with legacy systems, letting airlines manage all records in one place.
OOM adoption options
There are three main types of OMM systems — embedded PSS modules, standalone off-the-shelf products, and custom-built solutions.
PSS modules. Passenger service systems, pre-equipped with OOM capabilities, include Amadeus Altéa NDC and Amadeus-owned Navitaire New Skies, targeting hybrid and low-cost carriers.
Standalone off-the-shelf products. Among the leading airline retailing platforms are FLX ONE by Accelya, Astra by TPConnects, Datalex, t-Retail NDC by OpenJaw (now owned by Travelsky), SabreMosaic, and Amadeus Nevio. These systems are PSS-neutral, meaning an airline can implement them no matter what their current infrastructure. However, IT engineers are still needed to build API connections between a passenger service system and OOM software.
Custom-built solutions. In this scenario, a carrier engages a software development team with a deep understanding of air distribution to create a platform that neatly fits the needs of a particular airline.
AltexSoft helped a tech provider develop a standalone retailing hub to be integrated with partner airline PSSs. The software was designed to support four sales distribution options:
- a carrier’s website or mobile app,
- NDC-enabled resellers,
- non-NDC resellers, and
- GDSs.
From a technical perspective, this meant handling a separate API and booking process for each channel type. Our team was engaged in building direct and NDC distribution channels. In both cases, we considered following an OOM roadmap proposed by IATA to minimize development time and effort.
Offer and order flow by IATA
The traditional reservation flow consists of numerous small steps, each accompanied by exchanging EDIFACT messages between systems. OOM reduces the process to three major stages.
- Shop—a passenger provides search details on the airline’s website or OTA, and, in response, the airline generates an offer based on inquiry and customer data (travel history, loyalty program tier, booking patterns, and more). The carrier can price the offer according to the current market conditions;
- Order—once the passenger accepts the offer, the airline’s system turns it into an order, that contains information on all products and can capture future changes—like upgrading to business class, adding ancillaries, or making cancellations.
- Pay—the passenger pays for the order and is then ticketed.
Under the hood, each stage comprises a set of capabilities realized via specific request-response transactions between an airline and a sales channel.
Standard Offer and Order flow by IATA. Source: IATA distribution guide
Today, IATA supports dozens of capabilities, including continuous pricing and dynamic packaging. Below, we’ll only examine what our team explored or implemented as part of the OOM flow for the client’s distribution hub. We've included observations of Eugene Kallaur, Solution Architect at AltexSoft, who participated in preparing technical documentation for the development team.
Shop capabilities
IATA defines three types of offers airlines can sell.
- Classical offers contain flight fares that can be with bundled ancillaries.
- A-la-carte offers are for optional services a traveler buys in addition to the fare (meals, on-board Wi-Fi, etc.). They work as an implementation of a shopping basket concept for ancillaries.
- Priced offers consolidate all products chosen by a passenger and come with a total price.
“When you initiate air shopping, the system will first return a range of classical offers,” Eugene Kallaur explains. “Then you can say, 'Ok, I’ve chosen this flight. But I also want a meal and WiFi'. In response, you’ll get a range of available a-la-carte offers. Once you’re done selecting, all items are combined into a priced offer.”
Now, let’s see what capabilities form the basic shop process and what information the airline exchanges with the sales channel at this stage.
Shop capabilities
Shop for flight. The website or NDC-enabled OTA sends a shopping request that includes origins and destinations, travel dates, Passenger Type Codes (PTC), and additional qualifiers (e.g., corporate ID or loyalty program details). The airline processes the request and responds with a list of fares with or without ancillaries. The response may also contain applicable rules and multi-media content (descriptions, photos, etc.)
Messages involved: Air Shopping request and response.
Offer conditions and restrictions. At different stages of the shopping flow, the airline can communicate the terms and restrictions associated with specific products, such as whether a passenger is allowed to change the flight free of charge or get a refund in case of cancellation.
Messages involved: Air Shopping response, Service List response, Seat Availability response, Offer Price response, Order Reshop response
Seat map and availability. After the flight is chosen, the seller requests a seat map, and the airline returns it with availability information.
Messages involved: Seat Availability request and response
Seat map and price points. In addition to previous details, the seller receives pricing information for each seat or seat range.
Messages involved: Seat Availability request and response
Shop for ancillaries. The seller sends a separate request for data on add-on services available for a particular flight. The airline responds with a-la-carte offers — for example, premium lounge access or priority boarding.
Messages involved: Service List request and response
Imagine an eCommerce shopping cart that you fill with different products. In the same way, you add a seat from a seat map and ancillaries. Or you can delete a service you don’t really need. The only condition is that your cart must include the core product, which is the flight.
Use of airline taxonomy. Airline taxonomy is a hierarchical code set that allows for describing flight products and services in a structured way. The IATA OOM flow enables sellers to request flights and services based on the codes, and airlines can respond accordingly. Taxonomy is not mandatory, but it can facilitate more effective communication between parties.
Examples of taxonomy for servicing, entertainment, and meals. Source: IATA Standards Development
Airlines can send additional information associated with a taxonomy code. For example, if the carrier provides pet grooming services, it may specify the pet's maximum height, length, and weight.
Messages involved: Taxonomy can be applied in any message where a service is mentioned.
Pricing offers. This capability allows a seller to request a consolidated offer with an associated total price. The airline may include additional details and upsell offers in its response.
Messages involved: Offer Price request and response, Order Quote request, Order Reshop Response
Upsell using pricing response. Airlines can send relevant upsell offers to sellers, like seat upgrades or extra legroom, either proactively or on request.
Messages involved: Offer Price request and response, Order Quote request, Order Reshop Response
Order capabilities
As we said, once the passenger accepts the offer, it becomes an order. But, of course, this process is not as straightforward and comprises a sequence of transactions.
Order capabilities
Create an order without payment. A seller can request an airline to create an order without paying for it immediately. In response, the airline sends a notification about the order creation with payment details and deadlines. This feature is useful for travelers who need time to arrange finances or confirm other details before completing the purchase while still securing their desired flights.
Messages involved: Order Create request, Order View response
Create an order with instant payment. The airline or reseller collects the payment immediately, and the carrier confirms the order and the payment (if the airline acts as a merchant of record).
Messages involved: IATA Order Create request, IATA Order View response
Watch our video to learn more about how a merchant model differs from an agency model, and why it matters for travel businesses.
Agency vs merchant model: two ways to handle payments in travel
“If the offer is paid, the airline immediately makes all necessary updates in its PSS,” Eugene shares. “But in the case of an unpaid order, several scenarios are possible. The airline can do nothing and just wait for money to be transferred. Or it can create a temporary booking in the PSS which expires, for example, in 20 minutes.”
Retrieve an order. The seller can always access the current version of the order — for example, to verify that loyalty program benefits have been applied to the booking or ensure that all added services are accounted for and that the pricing is up-to-date.
Messages involved: Order Retrieve request, Order View response
Shop for replacement services. Sellers can request new offers to replace a flight or services in an order. It provides an airline with information about new origins and destinations, dates, and/or services to be changed. The carrier responds with a set of relevant offers, a seat map, and/or a service list.
“Reshop typically results in the creation of a new priced offer that contains information about penalties applied and the sum to be paid extra or refunded,” Eugene adds. “If a new offer costs less than the canceled one, the airline can, for example, hold the money it owes to a traveler and propose to reuse this sum for purchasing other services. This payment method is called Value Store.”
Messages involved: Order Reshop request and response, Service List request and response, Seat Availability request and response, Order Quote request (for offer repricing in the replacement scenario).
Seller-initiated changes to an order. After all reshopped items are accepted by the traveler, the seller makes an order change request, and the airline updates the order accordingly, responding with the actual order view. The agency can also initiate changes that do not relate to the offer, for example, if there are alterations in passenger details.
Messages involved: Order Change request, Order View response
Order View response to an Order Change request, containing details about the old and new order, payment methods, and price differences. Source: IATA Standards Development
Note that Order Reshop and Order Change messages are also used for partial and full cancellations. Change requests deal with unpaid products, while paid items are processed through the reshop flow. “There are special cancellation offers that show how much will be refunded and what penalties are applied. The traveler must accept such an offer to cancel the flight,” Eugene explains.
Notification on airline-initiated order change. The airline informs the seller of any changes made to an order and follow-up actions it takes. The seller must acknowledge the information receipt. This capability is applied when an airline changes the schedule, switches the aircraft assigned to a flight with a resultant seat reassignment, or updates pricing and terms for certain services after the order was created.
Messages involved: Order Change Notification request, Acknowledgement
Historical information on orders. This enables sellers to access detailed records of order changes, whether initiated by the seller or the airline. For example, if there is a disagreement between the customer, seller, and airline regarding particular updates (such as cancellations or rebookings), accessing the historical information provides a clear record of all actions taken.
Each change in the history record comes with an explanation. For example, if there was a change in flight dates, the record will provide a reason for that, such as a schedule change due to bad weather.
Payment capabilities
IATA supports a range of payment methods in its NDC flow, including:
- customer cards, loyalty points, and value store for direct payments from travelers to airlines; and
- ARC/BSP Cash, IATA EasyPay, and corporate or virtual cards for B2B payments between airlines and travel agencies. In this case, a travel agency acts as a merchant of record, collecting payments from travelers and then making payouts to the airline.
Though a payment happens when or shortly after an order is created, the associated capabilities apply earlier in the process—starting from the flight shopping step.
Payment capabilities
Communicate payment catalog. In response to a range of shopping requests from the seller, an airline provides a payment catalog that sets forth
- payment methods accepted,
- additional details and requirements associated with particular payments (need for authentication, card type, etc.),
- whether the payment involves redirection to another website,
- processing fees, and
- other relevant data.
Messages involved: Air Shopping response, Service List response, Seat Availability response, Offer Price response, Order Reshop response, Order View Response
Pay for an existing order. The capability involves completing payments for unpaid or partially paid orders. As mentioned above, when creating an order without payment, the airline specifies the payment deadline. For this operation to be successful, the unpaid order items must adhere to this time limit.
Messages involved: Order Change request, Order View response
Pay using a settlement platform. When making a request for order creation or change, sellers can notify the airline of their intent to pay through a settlement platform, either IATA BSP or ARC. Airlines check the seller’s risk profile and agree (or disagree) to these indirect payments.
To use this capability, the airline must support ARC/BSP cash payments, and the agent must have a proper ARC or IATA accreditation.
Messages involved: Order Create request, Order Change request, Order View response
Pay using a customer card. This capability allows the airline to accept card payments directly from customers. In this scenario, an agent just forwards card details to the carrier, which collects a traveler’s money directly. To implement this payment flow, both parties must comply with Payment Card Industry Data Security Standards (PCI DSS).
Messages involved: Order Create request, Order Change request, Order View response
Pay offline using redirection. Offline here means that payments are completed outside the core offer and order flow with a method not included in the airline’s payment catalog. In this case, the seller initiates an offline payment in the request for order creation or change. The airline responds with relevant instructions on how to finalize the transaction, for example, by redirecting a passenger to the carrier’s website or to the page with details for bank transfer.
Messages involved: Order Create request, Order Change request, Order View response
Some notes on offer and order management implementation
IATA gives a high-level description of the offer and order booking flow, while the particular implementation and tech stack will differ from project to project depending on the development team’s skills and experience, the requirements of a specific airline, and many other factors. Below, we’ll share a couple of considerations relating to the solution architecture.
Synchronous/asynchronous design patterns. Some functionality (for example, managing order history in the airline’s OOM system) seems to be a perfect use case for asynchronous design patterns, such as event sourcing. Yet, in practice, “It does not align with NDC standard which is synchronous by nature and has associated constraints,” Eugene Kallaur explained.
Microservices. We used microservices architecture to implement three distinct sub-flows: Shop, Reshop, and Order. This modularity improves overall system resilience and enables more agile updates, as changes in one service don't impact others. Yet the division we followed is not a rule of thumb: The same flow can be realized via just two microservices—Shop (which includes Reshop functions) and Offer. Each approach has its pros and cons.
“IATA only shows where you must arrive, but it’s up to you to decide how to get there,” Eugene concludes.