NDC (New Distribution Capability)

NDC defines a family of XML/JSON schemas for airline retailing across shop, order and service. It moves pricing and product definition closer to the airline and away from the constraints of EDIFACT. For operators, the key idea is not “a different API” but “a different commercial and servicing surface” — richer offers, fare brands and ancillaries exposed with airline‑controlled logic.

In production, no two airlines behave the same. Payload shapes, authentication, error semantics and servicing coverage all vary. A practical setup uses an aggregator or a unified API that normalises carriers into one order model with per‑airline capability flags. Agents then see a single grid with a clear source label (GDS, NDC, LCC, contract) rather than three separate tools.

Shopping differences show up in branded fares, seat maps and ancillaries. Present these as structured attributes on an offer — not free‑text — so the UI can compare like with like. On the order side, store airline order identifiers, documents and payment references in a channel‑agnostic model so mid‑office and customer flows remain stable whichever pipe issued the ticket.

Payment handling needs deliberate design. Some airlines expect pay‑at‑order and capture immediately; others issue after verification or accept third‑party acquirers. Idempotency on all write operations (create, pay, exchange, refund) prevents duplicates under retries. Store the idempotency key on the order for audit and support.

Servicing is where NDC maturity differs the most. Many carriers support voluntary changes and refunds; fewer support full involuntary flows and post‑ticket ancillaries. Expose this via capability flags per airline and build orchestration that picks the right path automatically. Agents should not have to remember which airline must be changed “in tool X”.

Involuntary schedule changes (IRROPS) require fast detection and consistent state. Subscribe to airline events when available, otherwise poll queues predictably. Record the original vs updated segments and the chosen resolution, and notify travellers through your post‑booking channel. Duty of care and corporate reporting depend on this being reliable.

Corporate programmes rely on policy, approvals and negotiated fares. Treat NDC as another content source within the same policy engine. Where corporate IDs or programme attributes belong on the request, make them first‑class fields so the same policy logic can run across GDS, NDC and LCC.

Testing should include real fixtures: lookups for branded fares, ancillaries, exchanges, refunds and edge‑cases like mixed‑cabin returns. Keep replayable sample traffic and a contract of expected behaviours so upgrades and airline releases do not surprise your production flows.

Migration rarely happens as a big‑bang. Enable a handful of markets and carriers first, measure attachment of ancillaries and servicing success, then expand. The outcome to watch is agent and traveller experience, not a percentage of traffic “moved to NDC”. Use the best source per fare at the time of sale.

For finance, ensure tickets, EMDs, taxes, commissions and supplier references are captured on the same order model you use for other channels. With that in place, BSP/ARC matching and ledger posting can be source‑agnostic, and statements reconcile cleanly even when one PNR/record locator is not present.

Governance matters: publish your API surface (if you expose one), version changes that alter behaviour, and maintain a per‑airline capability sheet that commercial and operations teams can trust. It sets the right expectation for both features and limits.