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

Airline distribution debates often begin as if a single channel will replace the others. NDC is newer. GDS has reach. Low-cost carriers prefer direct distribution. Pick the future.

Travellers do not shop protocols. They shop a departure time, a total price, a bag, a seat and a set of conditions they can understand. A useful airline product therefore needs a portfolio strategy: use each source for what it does well, then make the differences manageable behind one offer and order model.

This is not an argument that every source is equivalent. It is a method for choosing coverage without making the checkout and servicing layers source-aware. Treat this essay as the overview of that method; where a single channel deserves a full examination, it links to the deeper essay.

The short comparison

The right question is not “Which acronym wins?” It is “What combination produces the best bookable offer for this traveller, and can we service it after sale?”

NDC: richer intent, uneven edges

NDC lets airlines distribute offers with more context than a traditional filed fare alone: branded fares, ancillaries and merchandising presented closer to the airline’s intent. The work is in the edges. Version support, certification, carrier interpretation and post-booking capabilities can vary. “Supports NDC” is not a sufficient acceptance criterion.

Those edges run deep enough to deserve their own essay: certification levels that thin out exactly where servicing lives, schema versions that drift per carrier for years, and refunds that still settle on legacy rails. That case is made in Why NDC will not solve your immediate problems. The short version is that the NDC coverage you can shop is much larger than the NDC coverage you can operate.

Ask instead:

• Which shopping and servicing capabilities are available 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 the same order surface handle voluntary and involuntary changes?

NDC is most valuable when its richness survives normalisation without its implementation details entering the product code.

GDS: reach and operational memory

For products that need broad carrier coverage, interline itineraries or established ticketing workflows, GDS content can remain important because airline distribution is not only shopping.

The risk is not using a GDS. The risk is allowing source-native concepts to become the 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.

A good abstraction preserves the GDS contribution of coverage and fulfilment while converting downstream work into inspectable API operations and events.

This matters most after checkout. If the search layer looks unified but agents must learn a separate flow for every change, the integration is only cosmetically normalised.

LCC direct: indispensable, deliberately different

Low-cost carriers often distribute fares and bundles through their own systems, and some of their most useful content may not appear in the same form through other channels. Direct connections can surface the operator’s actual bags, seats and bundles.

But “direct” is not automatically “simple.” Each connection can have its own authentication, shopping semantics, payment expectations and servicing model. One airline’s change workflow may resemble another’s cancellation and rebook.

The architectural question is whether those differences are absorbed at the supply edge or copied into every consuming application.

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 should not mean one lowest-common-denominator object. It should mean a stable envelope with typed richness.

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. The source is a field the ranking layer may read, not 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 that reads this 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.

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. The important product principle is comparability: customers should not need to understand why two fares describe the same benefit differently.

Rank outcomes, not sources

Hard-coding a preferred source can create false optimisation. The cheapest base fare may lose after a bag. A private fare may be better for one traveller but unavailable to another. A rich NDC offer may be less suitable than a flexible GDS fare for a managed-travel policy.

A source-agnostic ranking model can consider:

• 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 ranking explanation inspectable. “Recommended” should be supported by observable attributes, not a hidden source preference.

Procurement questions that reveal the real integration

When comparing airline-content platforms, replace the coverage slide with a worked itinerary.

Shopping

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

Booking

• Trace payment and supplier confirmation.
• Lose the confirmation response and retry safely.
• Show all native references 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 certification and schema-version ownership.
• Demonstrate how a new source avoids a new front-end branch.

If a provider can only demonstrate search, you are evaluating a metasearch feed, not a booking lifecycle.

When should you connect directly?

A direct airline relationship may be right when the carrier is central to your market and negotiated content differentiates the product. It still benefits from entering the same canonical layers as other supply. Aggregation is stronger when breadth and one servicing surface matter more than owning each certification. A hybrid preserves direct deals while adding reach elsewhere.

The decision does not have to be permanent. The key is to keep source selection behind a stable contract so 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 different tools, not competing religions. Preserve their strengths. Contain their machinery. Rank the traveller outcome. Keep one history after booking.

That is what makes a multi-source flight product feel like one product.