Flight booking engine development and NDC, explained without the acronym soup

For three decades, most flight booking engines worked the same way: connect to a GDS (Amadeus, Sabre, Travelport), search fares, book a PNR, done. That model is still the backbone of the industry, but airlines have spent the last several years pushing a parallel standard — NDC, IATA's New Distribution Capability — that changes both what you can sell and how hard it is to build the booking engine that sells it.

What NDC actually is, without the jargon

NDC is an XML/API-based standard that lets airlines distribute their full retail content — branded fares, seat bundles, bags, upgrades, ancillaries — directly to booking platforms, instead of being limited to the flattened fare classes that classic GDS distribution supports. In plain terms: a classic GDS search often shows you a fare code; an NDC search can show you the airline's actual retail offer, the same richness a customer would see booking directly on the airline's own site, with dynamic bundling and personalised pricing.

Why this makes booking engines harder to build, not easier

The catch is that NDC is not one standard implemented identically by every airline — each carrier's NDC API has its own quirks, offer structures, and certification process, and airlines are rolling it out at different paces alongside their classic GDS content. A booking engine built purely for classic GDS fare search cannot simply 'add NDC' as a checkbox; it needs an architecture that can merge NDC offers and classic GDS/EDIFACT fares into one comparable search result, handle order management (NDC uses an 'Order' concept instead of the traditional PNR), and manage servicing — changes, refunds, ancillary purchases after booking — which works differently under NDC than under classic distribution.

• Dual-content search: merge NDC offers and classic GDS fares into one ranked, comparable result set
• Order-based booking management rather than assuming every booking is a classic PNR
• Per-airline NDC certification and mapping, since each carrier's implementation differs
• Post-booking servicing (changes, ancillaries, refunds) built for both content types, not just the booking step

What this means for a travel agency or OTA deciding what to build

Agencies still selling exclusively through classic GDS content risk losing access to certain fares and ancillaries that airlines are increasingly reserving for NDC channels, as carriers use NDC to differentiate direct and NDC-enabled distribution from legacy channels. But jumping straight to an NDC-only booking engine before your supplier mix and volumes justify it is its own mistake — most agencies and OTAs need both content types running side by side for the next several years, not a full migration.

• Start with classic GDS integration if you don't have one — it still covers the widest airline and fare coverage
• Add NDC connectivity for the specific carriers where it materially improves fares or ancillary revenue for your customer base
• Build the search and order layer to be content-agnostic from day one, so adding a new NDC carrier later doesn't mean rebuilding search

This dual-content complexity is exactly what we scope for when we build or extend flight booking engines at Mona Technologies — GDS integration where it's needed, NDC connectivity where it earns its complexity, and a search architecture that doesn't have to be torn up when the next airline switches on NDC.

Sources

• IATA — New Distribution Capability (NDC) Program