Why NDC will not solve your immediate problems

Adopting NDC will not fix a single thing that is broken in your product right now. It will add a third dialect beside the two you already speak, with its own certification matrix, its own version drift and its own error semantics, and you will still refund through BSP.

That is not an argument against NDC. The direction is right and I would rather live in the world where it wins: airlines author offers instead of filing fares, and branded fares, ancillaries and continuous pricing reach the channel closer to the airline's intent. But direction is not delivery. NDC is a supply migration spread unevenly across hundreds of carriers and measured in years; your roadmap is measured in quarters. That mismatch is the whole problem, and the standard advice, "get on NDC", quietly asks a product team to fund a distribution programme out of a product budget.

Here is why, in technical terms, and what to build so that NDC arriving is good news rather than a rewrite.

Certification levels are not interchangeable

"This carrier supports NDC" is a sentence with no information in it. IATA's Airline Retailing Maturity index (and the earlier NDC certification scheme it absorbed) distinguishes levels of capability, and the spread between those levels is the entire story.

• Level 2, offer management. The carrier can respond to shopping requests with structured offers. You can search and price. You cannot necessarily book through the same channel, and you certainly cannot service.
• Level 3, offer and order management. OrderCreate works. You can turn an offer into an airline-held order and get a real PNR-equivalent back. Servicing beyond creation is not guaranteed.
• Level 4, full offer and order lifecycle. OrderChange, OrderCancel, involuntary change handling and servicing exist as first-class API operations, not just as message definitions in a PDF.

The population thins dramatically at each step. Many carriers advertise NDC on the strength of shopping alone. Fewer complete order management in production. The set that supports the full servicing lifecycle, which is the only part your support team actually lives in, is a minority, and inside that minority coverage still differs by market, point of sale and fare type. A logo on a slide is a Level 2 claim until someone proves otherwise.

The number that matters is not how much NDC content you can shop. It is how much you can operate. Those are different numbers, the first is always larger, and every servicing case in the gap between them lands on a human.

Version plurality is permanent, not transitional

NDC is not one wire format. It is a family of schema releases, and carriers pin to whichever release they implemented. In a realistic multi-carrier integration you will speak 17.2-era payloads to one airline, 18.1 to another and 21.3 to a third, at the same time, for years. Not during a migration window. That is the steady state. The 21.3 generation was close to a redesign: message roots gained an IATA_ prefix, Passenger became Pax, flight structures were reorganised and element paths moved.

Here is the same idea, a branded fare with an included bag, expressed in two eras. First, a 17.2-style response, where the brand is a coded reference and the entitlement often rides along as loosely structured detail:

<!-- Carrier A · 17.2-era AirShoppingRS (abbreviated) -->
<OfferPrice OfferItemID="OF-A1">
  <FareDetail>
    <FareComponent>
      <FareBasis>
        <FareBasisCode><Code>KLOWDE</Code></FareBasisCode>
        <RBD>K</RBD>
      </FareBasis>
      <FareRules>
        <Penalty ChangeFeeInd="true" RefundableInd="false"/>
      </FareRules>
    </FareComponent>
  </FareDetail>
  <BrandedFareRef>ECOFLEX</BrandedFareRef>
  <!-- checked bag implied by the brand, described in remarks -->
</OfferPrice>

Then a 21.3-style response, where the brand and its inclusions are first-class service definitions:

<!-- Carrier B · 21.3-era IATA_AirShoppingRS (abbreviated) -->
<Offer OfferID="OF-B7">
  <OfferItem>
    <FareDetail>
      <FarePriceType><FarePriceTypeCode>Filed</FarePriceTypeCode></FarePriceType>
    </FareDetail>
    <Service>
      <ServiceDefinitionRef>SD-BRAND-ECOFLEX</ServiceDefinitionRef>
    </Service>
    <Service>
      <ServiceDefinitionRef>SD-BAG-1PC-23KG</ServiceDefinitionRef>
    </Service>
  </OfferItem>
</Offer>

Both describe "economy flex with a 23kg bag". Your comparison surface has to know that, and keep knowing it every time a carrier migrates versions, changes an optional element or reads a code list its own way. That mapping is the majority of the engineering cost of NDC, and it appears on no NDC slide anywhere, because it is not interesting and it never ends.

Servicing lags creation, sometimes by years

The demo path is AirShopping, OfferPrice, OrderCreate. The production path is everything after: the traveller who wants a different date, the airline that cancels a leg at 2am, the refund that has to reach the original card.

This is where implementations are thinnest, and the gap is not incidental. Creation is the part that sells:

• OrderChange trails OrderCreate. A carrier that books cleanly through NDC may support only a subset of voluntary changes through OrderChange, or none. The fallback is a call centre or an offline queue, which erases the channel's automation benefit exactly where automation matters.
• Voids and refunds fall back to legacy rails. Money movement in agency distribution still largely settles through BSP and ARC processes. An NDC order may be created through a modern API and then refunded through the same settlement machinery as a legacy ticket, on the settlement calendar, not yours.
• Involuntary changes arrive unevenly. Schedule change notifications through NDC channels vary in structure and reliability by carrier. Many integrations still reconcile disruptions through parallel feeds.

If your immediate problem is servicing cost or refund latency, read that list again. Not one of those fallbacks improves because you adopted NDC. You inherit all of them, and you add an integration to monitor.

Interline is the hard edge, and it is not close

Legacy distribution is old, but it is old in a specific way: it encodes decades of multi-carrier agreements. A single ticket across three airlines with protected connections and through-fares is unremarkable in the GDS world. It is also the itinerary a traveller most wants someone else to own when the first leg is late.

NDC is airline-authored by design. That is what makes single-carrier retailing rich, and the same property is what makes multi-carrier retailing hard. Offer-and-order interline, where two airlines' order systems compose one purchasable offer, is an active standards effort, not an installed base. Itineraries crossing alliances, needing interline baggage agreements or riding codeshare marketing frequently cannot be fulfilled NDC-only today. Source them through the channel that can fulfil them, usually the legacy one, and stop apologising for it.

Content parity is a negotiation, not a setting

The last constraint is not technical at all, which is why engineering teams keep getting blindsided by it. Airlines use NDC to differentiate their direct and preferred channels: continuous-pricing fare points, channel-exclusive bundles, surcharges on legacy bookings. What lands in your NDC feed versus the aggregated channel is the output of commercial agreements between airlines, aggregators and sellers, and those agreements move.

So parity is something you monitor, never something you assume. The same route can price differently across your own channels for reasons no engineer controls and no amount of caching explains. If your product's promise is "always the best fare", you need multi-channel sourcing and honest deduplication far more than you need any single channel's richness.

The third dialect

NDC does not replace your GDS integration: coverage, interline and mature servicing still live there. It does not replace LCC direct connections: most low-cost carriers built their retailing outside both worlds and have no reason to move. So it is not a replacement at all. It is a third dialect with its own certification matrix, version drift, error semantics and settlement quirks, arriving on top of the two you already maintain.

None of this argues against NDC. It argues against treating a supply migration as a product roadmap.

Make NDC a supply-side detail

There is a version of this story where NDC's arrival is pure upside, and it turns on one decision made before any of it: channel semantics never reach your product code. Not in a helper, not behind a feature flag, never.

Define one offer abstraction: identity, total price, conditions, included entitlements, optional services, service capability. Define one order abstraction: canonical order, per-item fulfilments holding native supplier references, event history, ledger entries. Every channel, NDC in any schema era, GDS, LCC direct, maps into those two objects at the supply edge, and ranking, checkout, servicing and support read the canonical form and nothing else. The first if (source === 'ndc') in a checkout controller is where this stops working, and it is always written for a good reason.

Servicing is where the payoff shows. One change request fans out to whatever each source requires and comes back comparable:

Under this model NDC adoption stops being a programme and becomes an event in the supply team's week. A carrier reaches real Level 4, the servicing adapter behind the abstraction gets richer, and the product improves without a release note. A carrier migrates from 17.2 to 21.3, one adapter changes, nothing above it notices. Channel strategy becomes procurement rather than engineering, which is where it belonged.

This is the model we run: NDC, GDS and LCC content, 517+ carriers including 140+ low-cost carriers, normalised behind one offer and order contract so the dialect question never reaches checkout. The broader portfolio argument is in NDC, GDS or LCC direct? The wrong answer is choosing one, and the lifecycle that contract has to survive is in Checkout is the midpoint.

What to do this quarter

Three things, if you are evaluating NDC right now:

1. Score carriers by servicing, not shopping. For every carrier that matters, ask which OrderChange operations work in production, what falls back to BSP-era flows and how involuntary changes arrive. Weight by your booking volume, not by logo count. The list gets shorter and far more useful.
2. Budget for version plurality. Assume at least three schema eras in parallel for years. When a vendor says "one normalised NDC integration", ask which versions it speaks today and who pays for the work when a carrier moves.
3. Fix the abstraction first. Every benefit NDC eventually delivers, richer offers, airline-held orders, cleaner servicing, only reaches your users if the product consumes supply through a stable contract. Build that contract now, against the supply you already have. Then NDC arrives as an upgrade instead of a project.

NDC is the right long-term direction for airline retailing. The goal is to benefit from every carrier that gets there, on whatever schedule they choose, without betting a quarter on any of them.