Why NDC will not solve your immediate problems

NDC deserves its momentum. Airlines get to author offers instead of filing fares. Branded fares, ancillaries and continuous pricing travel through the channel closer to the airline's intent. The direction is right.

But direction is not delivery. NDC is a supply migration measured in years, spread unevenly across hundreds of carriers, and your product roadmap is measured in quarters. If the problem in front of you is duplicate offers, slow servicing, refund reconciliation or a checkout that breaks on retries, adopting NDC will not fix any of it. In several cases it will add a new place for the same problem to occur.

This note explains why, in technical terms, and what to do architecturally so that NDC adoption becomes good news instead of a rewrite.

Certification levels are not interchangeable

"This carrier supports NDC" is close to meaningless without knowing what was certified. IATA's Airline Retailing Maturity index (and the earlier NDC certification scheme it absorbed) distinguishes levels of capability, and the spread between them is the whole 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.

In practice 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, the part your support team actually lives in, is a minority, and even within that minority the coverage differs by market, point of sale and fare type.

The consequence for a product team: the NDC coverage you can shop is much larger than the NDC coverage you can operate. If you plan capacity around the first number, servicing volume falls back onto humans.

Schema versions drift, and carriers do not move together

NDC is not one wire format. It is a family of schema releases, and carriers pin to the 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, indefinitely. 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 it has to keep knowing it every time a carrier migrates versions, changes an optional element or interprets a code list differently. That mapping work never appears on an NDC slide, and it is the majority of the engineering cost.

Servicing lags creation, sometimes by years

The demo path is AirShopping, OfferPrice, OrderCreate. The production path includes everything after: a traveller who wants a different date, an airline that cancels a leg, a refund that must reach the original payment method.

This is where NDC implementations are thinnest:

• 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, note that none of these fallbacks improve when you adopt NDC. You inherit them, plus a new integration to monitor.

Interline and codeshare remain the hard edge

Legacy distribution is old, but it is old in a way that encodes decades of multi-carrier agreements. A single ticket spanning three airlines with protected connections and through-fares is routine in the GDS world.

NDC is airline-authored by design, which makes single-carrier retailing rich and 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. Today, itineraries that cross alliances, need interline baggage agreements or rely on codeshare marketing often cannot be fulfilled NDC-only. The practical answer is to source them through the channel that can fulfil them, which is frequently the legacy one.

Content parity is a negotiation, not a setting

The last constraint is not technical at all. Airlines use NDC to differentiate their direct and preferred channels: continuous-pricing fare points, channel-exclusive bundles, surcharges on legacy bookings. What appears in your NDC feed versus the aggregated channel is the output of commercial agreements between airlines, aggregators and sellers, and those agreements shift.

Design consequence: parity is a property to monitor, not to assume. The same route can price differently across your own channels for reasons no engineer controls. If your product's value depends on always showing the best fare, you need multi-channel sourcing and honest deduplication far more than you need any single channel's richness.

The third dialect problem

Add all of this up and the operational reality is blunt. NDC does not replace your GDS integration, because coverage, interline and mature servicing still live there. It does not replace LCC direct connections, because most low-cost carriers built their own retailing outside both worlds. It becomes a third dialect beside the two you already speak, with its own certification matrix, version drift, error semantics and settlement quirks.

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

The architectural takeaway: make NDC a supply-side detail

There is a version of this story where NDC's arrival is pure upside, and it depends on one decision: never let channel semantics reach your product code.

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. Ranking, checkout, servicing and support read only the canonical form.

Servicing is where the payoff is most visible. One change request from your product fans out to whatever the source requires and returns one comparable result:

Under this model, NDC adoption becomes a supply-side event. When a carrier reaches real Level 4 support, the servicing adapter behind the abstraction gets richer and your product silently improves. When a carrier migrates from 17.2 to 21.3, one adapter changes and nothing above it notices. Channel strategy becomes a procurement decision instead of an engineering programme.

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

What to do this quarter

If you are evaluating NDC right now, three suggestions:

1. Score carriers by servicing, not shopping. For each carrier that matters to you, ask which OrderChange operations work in production, what falls back to BSP-era flows and how involuntary changes arrive. Weight coverage by your booking volume, not by logo count.
2. Budget for version plurality. Assume at least three schema eras in parallel for years. If a vendor claims one normalised NDC integration, ask which versions it speaks today and who owns the migration when a carrier moves.
3. Fix the abstraction first. Every problem NDC will eventually help with, richer offers, airline-held orders, cleaner servicing, pays out only if your product consumes supply through a stable contract. Build that contract now, against the supply you already have. Then NDC arrives as an upgrade, not an event.

NDC is the right long-term direction for airline retailing. Your product should be positioned to benefit from every carrier that gets there, on whatever schedule they get there, without betting this quarter on it.