NDC, GDS or LCC direct? The wrong answer is choosing one

The NDC-versus-GDS argument has filled a decade of conference panels and produced almost nothing a traveller can feel. No traveller has ever asked which protocol produced their fare. They ask for a departure time, a total price, a bag, a seat and conditions they can understand, and every serious flight product ends up buying from all three sources anyway.

So the strategic question is not which acronym wins. It is whether the acronym ever reaches your checkout. If it does, you have not built one flight product. You have built three, plus a router, and you will maintain all four.

This is not an argument that the sources are equivalent. They are not, and the differences are precisely where the engineering lives. It is a method for choosing coverage without letting checkout and servicing become source-aware. Where a single channel deserves a full examination, this essay points at it.

The short comparison

Read the last row as the real scoreboard. Every source has a strength you want and a machinery you do not, and the only durable question is: what combination produces the best bookable offer for this traveller, and can we service it after the sale?

NDC: the coverage you can shop is not the coverage you can operate

That gap is the entire story, and “supports NDC” exists to keep you from noticing it.

The upside is real. NDC lets airlines distribute offers with more context than a filed fare carries: branded fares, ancillaries and merchandising presented close to the airline’s own intent. The work is in the edges. Certification levels thin out exactly where servicing lives. Schema versions drift per carrier for years. Refunds still settle on legacy rails. That case is made at length in Why NDC will not solve your immediate problems.

So stop accepting the phrase and ask instead:

• Which shopping and servicing capabilities exist per carrier?
• Can fare families be compared with offers from other channels?
• Are seats and bags priced and fulfilled consistently?
• What happens when an airline upgrades its schema?
• Does one order surface handle voluntary and involuntary changes?

NDC earns its place when the richness survives normalisation and the implementation details never reach the product code.

GDS: the reach is real, the vocabulary is contagious

Broad carrier coverage, interline itineraries and mature ticketing workflows are not nostalgia. Airline distribution is not only shopping, and the fulfilment machinery underneath a GDS took decades to build.

The risk was never using a GDS. The risk is letting its vocabulary become your customer experience. A queue is an operational mechanism, not a product strategy. A terminal command should not be the only way a modern application can explain a change or request a refund. Products that let legacy record structures into their own data model pay for it in the manage-booking screen, years later, in a rewrite nobody budgeted.

A good abstraction keeps the coverage and the fulfilment, and converts the downstream work into inspectable API operations and events.

This shows up after checkout, never before. If search looks unified but agents learn a different change flow per source, the integration is cosmetic.

LCC direct: indispensable, and never the same twice

Low-cost carriers distribute their fares and bundles through their own systems, and their most useful content often exists in no other shape anywhere else. If a carrier matters in your market, a direct connection is not a preference. It is the only way to surface the operator’s actual bags, seats and bundles.

“Direct” is not “simple,” though. Each connection brings its own authentication, shopping semantics, payment expectations and servicing model. One airline’s change workflow is another airline’s cancel and rebook. Those differences do not converge as you add carriers, they compound, which is why the count matters: OnArrival runs 140+ low-cost carriers operator-direct.

The architectural question is whether that variance is absorbed at the supply edge or copied into every application that consumes it.

Treating LCC direct as a first-class source means:

• Retaining carrier-specific product detail.
• Mapping it into comparable total-price and condition fields.
• Recording the native confirmation references behind a canonical order.
• Exposing changes and refunds through the same product contract where possible.
• Making limitations explicit instead of simulating unsupported capabilities.

What “one offer object” should mean

One object does not mean one lowest-common-denominator object. That is the failure mode product teams rightly fear from normalisation: sand an LCC bundle down to a base fare and a time, and you have destroyed the thing you built the direct connection to get.

A stable envelope with typed richness is the alternative. At minimum, a comparison surface needs:

1. Identity: source, carrier, segments and the offer’s validity window.
2. Price: total, currency, taxes, fees and any mandatory payment costs.
3. Conditions: refundability, change terms and fulfilment constraints.
4. Included value: baggage, seat entitlements and fare-family benefits.
5. Optional services: bookable ancillaries with clear prices.
6. Service capability: what can be changed, cancelled or refunded after booking.

On the wire, the envelope is deliberately unglamorous. Source is a field the ranking layer may read, never a branch the checkout must contain:

{
  "offer_id": "off_8c14",
  "source": "lcc_direct",
  "carrier": "XX",
  "valid_until": "2026-08-03T10:42:00Z",
  "price": { "total": 14860, "currency": "INR", "taxes_included": true },
  "conditions": { "refundable": false, "change": { "fee": 3500, "currency": "INR" } },
  "included": { "checked_bags": 1, "cabin_bags": 1, "seat_selection": "paid" },
  "services": [{ "type": "extra_bag", "weight_kg": 5, "price": 1450 }],
  "capability": { "change": "api", "cancel": "api", "refund": "unsupported" }
}

A checkout reading that object neither knows nor cares which acronym produced it. When the same shape comes back from a full-lifecycle NDC carrier, the capability block simply says more, and the product gets richer without a new branch. Note what the envelope refuses to do: it does not pretend the LCC fare is refundable, and it does not hide that refunds are unsupported. Typed honesty beats simulated parity, because the moment you simulate a capability in search you have signed your support team up to fake it by hand forever.

OnArrival’s Flights page describes NDC, GDS and LCC content behind one offer object across 517+ carriers, including 140+ low-cost carriers, with bags, seats, branded fares and refunds normalised the same way. Comparability is the product principle: a customer should never have to work out why two fares describe the same bag differently.

Rank outcomes, not sources

Hard-coding a preferred source is a false optimisation with a good-looking dashboard. The cheapest base fare loses the moment a bag goes on it. A private fare can be excellent for one traveller and unavailable to the next. A rich NDC offer can be the wrong answer for a managed-travel policy that needs a flexible GDS fare.

Source-agnostic ranking weighs:

• Total trip price after selected ancillaries.
• Schedule and connection quality.
• Refund and exchange conditions.
• Entitlements included in the fare.
• Policy compliance.
• Fulfilment confidence and service capability.
• Commercial rules that do not misrepresent the traveller’s cost.

Keep the explanation inspectable. “Recommended” has to be defensible from observable attributes. If the only honest explanation is a hidden source preference, it is not a recommendation, it is a margin with better typography.

The demo that reveals the real integration

When you compare airline-content platforms, put the coverage slide away and make them run one itinerary in front of you.

Shopping

• Show the same route returned by different source types.
• Explain how duplicate or equivalent offers are resolved.
• Add a bag and a seat, then compare total price.
• Recheck an offer whose price has moved.

Booking

• Trace payment and supplier confirmation.
• Lose the confirmation response and retry safely.
• Show every native reference under the canonical order.

Servicing

• Change a date voluntarily.
• Process a schedule change.
• Quote and execute a refund.
• Show the events delivered downstream.

Operations

• Identify which capabilities vary by carrier.
• Explain who owns certification and schema versions.
• Demonstrate how a new source avoids a new front-end branch.

Search demos beautifully everywhere. Servicing is where the integration either exists or does not. If a provider can only show you search, you are evaluating a metasearch feed, not a booking lifecycle.

When should you connect directly?

Direct is right when a carrier is central to your market and negotiated content genuinely differentiates the product. It still has to enter the same canonical layers as everything else. Aggregation wins when breadth and one servicing surface matter more than owning each certification. Hybrid keeps the direct deals and buys reach for the rest.

None of it has to be permanent, and that is the argument for keeping source selection behind a stable contract: commercial strategy can change without rewriting the traveller journey. For the architecture behind that contract, see The travel API is not the architecture.

The principle to carry forward

NDC, GDS and LCC direct are tools, not religions. Preserve their strengths. Contain their machinery. Rank the traveller outcome. Keep one history after booking.

Do that and you have one flight product. Skip it and every new source is a new branch in the front end, forever.