What NDC does not fix in your booking product

Adding an NDC connection can improve access to airline offers and services. It does not, by itself, solve booking recovery, customer support or reconciliation. Those responsibilities remain with the product and its operating partners.

The practical question is what the connection can do for your customers, in your markets, across the whole booking lifecycle. Shopping support alone does not establish change, refund or disruption support.

This note explains the integration gaps to plan for and how to keep carrier differences out of the customer experience.

Check booking and servicing capabilities separately

IATA's ARM index superseded the former NDC and ONE Order certification registries. The old level numbers should not be used as a current guarantee that a connection supports every booking action.

Evaluate the actions your product needs on the connection you will use. Shopping, booking and servicing are separate questions:

OnArrival's NDC capability matrix examines the published evidence in detail. For an integration decision, also verify the carrier, market, fare and servicing cases you intend to support.

Plan for several NDC versions at once

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.

Check bookings that involve more than one airline

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.

Agree which fares and services the connection includes

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.

Direct low-cost airline APIs add another booking model

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

Keep supplier-specific parsing in the integration layer. Product code should work with shared offers and orders, while retaining the capabilities, conditions and evidence needed to explain each booking.

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 adds a supported servicing action, the adapter can expose it through the shared model, and the product can use it without adding a separate carrier workflow. 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.

OnArrival brings NDC, GDS and direct low-cost carrier content into a shared offer and order model. Each booking still retains its supplier references and supported actions. Read the distribution comparison and the travel order lifecycle for the wider design.

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.

Source

• Airline Retailing Maturity index fact sheet, IATA, accessed 8 September 2026.