Every airline distribution professional who finds UCP Checker eventually asks a version of the same question: "Are we supposed to replace our NDC investment with this?"

It's a sensible question. NDC is the most expensive distribution initiative the airline industry has run in the past two decades — IATA's New Distribution Capability launched in 2012, and most major carriers have spent the years since rebuilding offer and order systems around it. Now Google ships UCP, Sabre and Mindtrip launch an agentic flight-booking flow with PayPal, and every airline distribution roadmap suddenly has a new acronym at the top of it.

Here's the honest answer from running the only continuously-updated UCP directory and from listening to airline distribution teams trying to figure this out:

UCP and NDC aren't competitors. They sit at different layers of the same airline distribution stack. NDC carries the airline content; UCP is how an AI agent discovers and transacts against it. An airline with NDC investment has a head start on UCP-readiness, not a wasted investment.

This post is the practitioner comparison.

#The stack, in one diagram

┌─────────────────────────────────────────────┐
│                                             │
│  AI Agent (Gemini, ChatGPT, Claude, etc.)   │
│                                             │
├─────────────────────────────────────────────┤
│                                             │
│  UCP        ← discovery + agentic checkout  │
│             (the agent contract:            │
│              capabilities, transports,      │
│              payment handlers)              │
│                                             │
├─────────────────────────────────────────────┤
│                                             │
│  NDC        ← rich content distribution     │
│             (Offer, Order, ancillaries,     │
│              fare families, baggage,        │
│              seat maps, dynamic pricing)    │
│                                             │
├─────────────────────────────────────────────┤
│                                             │
│  Airline PSS / Reservation system           │
│  (Amadeus Altéa, Sabre SabreSonic,          │
│   Navitaire, custom)                        │
│                                             │
└─────────────────────────────────────────────┘

Read top-to-bottom: an AI agent reaches an airline's UCP profile to discover what it can do, transacts via UCP's declared transports, and the airline's UCP endpoint serves content out of the NDC offer/order architecture sitting underneath — which in turn is fed by the carrier's passenger services system.

That's the whole shape. Now the detail.

#What NDC actually is

NDC (New Distribution Capability) is an IATA-standardised XML messaging schema first introduced in 2012 via Resolution 787. It is not a transport, not a network, and not a marketplace — it's a content standard. NDC defines how an airline describes its products (flights, fares, ancillaries, seats, branded fares) to distribution partners in a way that lets the airline control the content, rather than have it filtered through legacy GDS pipes built around EDIFACT.

The core conceptual move in NDC is the Offer / Order model. Instead of the legacy world of PNRs, fare construction strings and tariff filings, an airline issues an Offer (a fully-priced, fully-described bundle including ancillaries) and the buyer accepts it into an Order. The airline owns the offer. The airline owns the order. The distribution partner just transacts.

IATA has run an assessment program for implementer maturity since the mid-2010s; the program has been through several iterations and renamings, though the industry shorthand "Level 1 through Level 4" (Capability Assessment through Full Offer and Order) is what most carriers and aggregators still use to describe their progress. Reaching the top tier — full Order-based distribution — is multi-year work for any large carrier.

Adoption has been uneven but real. The most-public NDC adopters include Lufthansa Group, Singapore Airlines, IAG (British Airways, Iberia, Aer Lingus), Emirates, Air France-KLM, Cathay Pacific, Qantas, and a long tail of others at varying maturity. The US Big Three (American, United, Delta) have engaged on very different timelines, with publicly contentious episodes around GDS distribution costs and full-content access charges shaping each carrier's pace differently. IATA reports steady year-over-year growth in NDC-channel bookings for the carriers that prioritise it, though headline penetration figures vary depending on which carriers and channels are included.

Low-cost carriers are a different conversation entirely. Ryanair, Southwest, easyJet, Wizz Air, Spirit and most other LCCs have historically operated outside the GDS-and-NDC distribution model altogether, selling direct via their own websites and apps (and a limited set of metasearch partners). They face the agentic-distribution question with a fundamentally different starting architecture: no NDC backend to wrap, but also no entrenched GDS or NDC pipes to defend. A direct UCP-airline endpoint — bypassing the GDS layer entirely — is closer to how LCCs already operate, which makes them a quietly interesting category for the agentic transition.

The point of NDC, decoded: airlines reclaim control of how their content is described, priced and bundled, instead of inheriting whatever the GDS aggregation layer makes available.

#What UCP actually is (in airline context)

Universal Commerce Protocol is the open standard for agentic commerce. It answers a different set of questions than NDC does — questions that didn't matter much until AI agents started transacting on behalf of consumers:

• How does an agent find the merchant in the first place? A well-known manifest at /.well-known/ucp declares the merchant's identity, signing keys, and a capability inventory.
• What can this merchant do? A declared set of capabilities — catalog-search, cart, checkout, payment, identity-linking, and so on.
• How does the agent talk to it? One or more declared transports — REST, MCP, A2A, Embedded.
• How does the agent pay? A declared list of payment handlers with enough detail for an agent to tokenize a card or invoke an AP2 mandate.

UCP is the agent contract. It tells an arriving AI agent what the merchant can do, how to dispatch tool calls, and how to pay. It is deliberately silent on the merchant-internal stuff: how the catalogue is structured behind the scenes, where the inventory comes from, how prices are calculated, how the order ends up in the back-office. That's the merchant's problem to solve — and for airlines, NDC is already most of the answer.

Today, UCP's published capability namespaces are retail-shaped (dev.ucp.shopping.*) — designed for the discrete-SKU world Google Shopping was built around. As we've measured separately, that retail-native shape isn't yet a fit for the perishable-inventory dynamic-pricing reality of airlines. Travel-specific capability work is on the roadmap; the lodging vertical was the first formally named and airlines will follow.

#How they actually compose — a worked example

Picture an AI agent asked to book a flight: "Book me LHR–SFO next Tuesday, business class, one checked bag, window seat near the front."

In a fully-agentic airline future where UCP and NDC compose cleanly:

1. UCP discovery. The agent fetches https://united.com/.well-known/ucp. It parses the profile: capability list (flight-search, seat-selection, payment, order), transport options (MCP first), payment handlers, signing keys.
2. Search. The agent calls flight-search({origin: "LHR", destination: "SFO", date: "..."}) via MCP against the declared endpoint. The airline's UCP endpoint translates this into an NDC AirShoppingRQ against its own offer engine — which produces real, priced, content-rich Offers including ancillaries and branded fares.
3. Selection. Agent presents options. User picks. Agent calls select-seat({...}) and add-ancillary({type: "bag"}). The airline's UCP endpoint maps each into the corresponding NDC SeatAvailabilityRQ, ServiceListRQ and OfferPriceRQ calls, getting back a re-priced Offer that bundles the seat and bag.
4. Order creation. Agent calls order.create(). The UCP endpoint wraps an NDC OrderCreateRQ underneath — the same one the airline would receive from any NDC-Level-4 OTA today.
5. Payment. Agent looks at the airline's declared payment handlers. If AP2 is declared (eventually), it runs the AP2 mandate flow. If not, it tokenizes via the declared handler (a card network, an alternative payment method, or an airline-direct method like a corporate-account charge). The airline's UCP endpoint forwards the tokenized payment to the same payment gateway it would use for any NDC order.
6. Confirmation. The airline returns the Order. UCP wraps it in the agent's response. The agent confirms with the user. The PNR exists in the carrier's PSS the same way it would for any other channel.

UCP at the agent interface layer. NDC carrying the offer/order content. PSS at the back. None of them replaced the others — and an airline that's already NDC Level 4 has done the hardest part of getting ready to serve the UCP endpoint cleanly.

The first live consumer rollout of something close to this pattern is the Sabre / Mindtrip / PayPal launch in May 2026 — flight-only at launch with hotels phased in later, GDS-mediated rather than airline-direct, and US-and-Europe in scope. Booking volume isn't public yet, but the architectural shape — AI agent at the front, existing content infrastructure at the back — is the one to watch.

#The economics question

Every airline distribution conversation eventually arrives at money. NDC's biggest commercial argument wasn't technical — it was that airlines were paying GDS fees and full-content surcharges to distribute content the airlines themselves owned, and NDC promised a path to reclaiming margin. The agentic equivalent is the question every airline commercial team will ask first: who pays for an agent-mediated booking?

There's no settled answer yet. The candidate models worth understanding:

• Platform-subsidised (currently Google). UCP itself is an open standard governed by a multi-vendor Technical Council — Google, Shopify, Amazon, Meta, Microsoft, Salesforce, Stripe and others — not a Google-controlled protocol. But the dominant early agent surfaces — Gemini, AI Mode, Google Shopping — are Google-operated, and Google has so far avoided directly billing merchants or consumers for the flows running through them. This subsidy can persist for as long as Google treats agentic commerce as a Google Pay and Search funnel — which may not be forever, and which doesn't bind what other agent platforms (ChatGPT, Claude, Copilot) decide to charge.
• Merchant-funded (referral or transaction fee). The most direct analogue to the metasearch model — airlines pay the agent platform a fee per click, per booking, or per completed transaction. This is the model OTAs and metasearch have worked under for two decades; an agent layer would inherit it.
• Consumer-funded (premium agent). The user pays the agent platform (Gemini Advanced, ChatGPT Plus, premium Copilot tiers, etc.) for the privilege of agent-mediated booking. Airlines pay nothing extra; the agent platform monetises the user relationship.
• Hybrid. A baseline free tier funded by referral fees, premium tiers for higher-quality recommendations, a separate enterprise tier for corporate travel. This is where most distribution markets eventually settle.
• Tokenised-payment incentive. The Sabre/Mindtrip/PayPal launch includes a PayPal Buy-Now-Pay-Later incentive — a sign that payment-method economics may end up being one of the early subsidy lines, with the agent platform, the payment provider, and the airline all sharing different slices of the spread.

UCP itself takes no position on any of this. The spec is commercially neutral by design: it standardises the contract, not the commercial model. That neutrality is deliberate and leaves the entire economic question to the implementations sitting on top.

For airline commercial teams, the practical near-term answer is: track which agent platforms your competitors are showing up in, and what fee structures (if any) emerge. The economic shape of the market will be visible within 12–24 months of broad agent-platform adoption; UCP itself will not be the deciding variable.

#The customer-ownership question

The other thing NDC won for airlines — arguably the deeper strategic win — was the customer relationship. In legacy GDS distribution, the OTA or TMC sat between the airline and the traveller, owning the email address, the marketing consent, the post-booking communications, and the loyalty-enrolment opportunity. NDC's Offer/Order model let airlines reclaim that: the airline is the merchant of record, the airline owns the customer data, the airline runs the post-booking journey.

Agentic checkout reopens the question. When an AI agent books a flight on a traveller's behalf:

• Who is the merchant of record? The airline still issues the ticket, but the consumer-facing transaction surface is the agent platform. The Sabre/Mindtrip flow has PayPal as the consumer-facing payment relationship and Sabre's NDC pipes underneath. The customer experience never visits the airline's website.
• Who captures marketing consent? UCP's Identity Linking capability provides an OAuth-based path for an agent to bring an authenticated user account into a merchant flow — but it's optional, and the default agent-mediated booking does not necessarily transfer email or marketing consent to the airline.
• Who runs post-booking communications? Schedule changes, gate changes, irregular-operations notifications, loyalty-point credits, post-flight surveys — historically these flowed merchant-to-customer over the airline's own channels. In an agent-mediated booking where the agent platform mediates communications, the airline may or may not own that channel.
• Who owns the loyalty-enrolment moment? A first-time flyer who books an airline via an agent is a high-value enrolment opportunity. Whether the airline captures it depends on what the agent platform passes through and what the airline's UCP profile requests.

UCP doesn't resolve these questions today; it gestures at the surfaces where they would be answered (Identity Linking, the buyer-consent capability, the payment-handler declarations) but leaves the actual policy to the agent platforms and the merchants to negotiate. For an airline distribution exec, this is the section that determines whether agentic checkout is a channel expansion (you still own the customer, you just gained a new way to be discovered) or a channel disintermediation (you gained a booking but lost the relationship) — and the answer will be specific to each agent-platform partnership the airline signs.

#Where they actually compete

The composition story above is the optimistic one. There's a competitive tension worth naming honestly.

For airlines, the strategic question is whether UCP routes around NDC. If every major airline exposes a direct UCP endpoint, agents can transact airline-direct without ever touching a GDS or an NDC-aggregator OTA. That's the airline distribution dream that NDC chased and only partially delivered: full control over the customer relationship and full margin on the order, with no intermediation.

But it's not a foregone conclusion. The OTAs, GDSes and metasearch players that have built businesses on aggregating multi-carrier content also have UCP options — they can expose their own UCP endpoints aggregating across carriers, and an agent that wants to compare three airlines for one route is more likely to use an aggregated UCP endpoint than three airline-direct ones.

The likeliest outcome: a mixed market. Direct-airline UCP for high-loyalty customers booking a specific carrier; aggregated UCP from OTAs and metasearch for comparison-shoppers; GDS-mediated UCP (the Sabre/Mindtrip pattern) for the corporate and TMC channels.

That's the same market structure airlines have today, just with an additional agent-native shopping surface on top. Which is exactly why the airlines with NDC content infrastructure already in place are best positioned for any version of the future — agent-direct or agent-aggregated, both run on the same offer/order primitives.

#Common comparison questions

These are the exact questions we get from airline distribution teams and from agents starting to research the space. Direct, anchored in the actual UCP spec and the actual NDC documentation.

#What is the difference between UCP and NDC?

NDC is an airline content distribution standard. UCP is an agentic commerce contract. They solve different problems at different layers of the same stack.

NDC (IATA, 2012) defines how an airline describes its products — Offers, Orders, ancillaries, branded fares, seat maps — to distribution partners (OTAs, GDSes, TMCs). It's a B2B content standard with multi-level certification. UCP (Google + industry, 2026) defines how an AI agent discovers what a merchant can do and dispatches transactions against it — a profile of capabilities, transports, and payment handlers. It's agent-to-merchant.

The clean composition: an airline exposes a UCP endpoint that serves content out of its NDC implementation underneath. The agent talks UCP at the front; the airline talks NDC at the back; the customer never sees either acronym.

#Does UCP replace NDC?

No. UCP doesn't define the content NDC defines.

NDC carries the airline-specific data primitives — Offers, Orders, ancillaries, fare rules, seat maps, fare families — that UCP's current capability vocabulary doesn't model. An airline exposing UCP today would need somewhere to serve that content from; for any airline with an NDC investment, that "somewhere" is the NDC implementation already in production. For airlines without NDC, the gap is much larger — they'd need to invent or buy equivalent offer/order primitives from scratch.

The strategic question for airlines isn't "UCP or NDC?" It's: "Given our existing NDC investment, what does it take to expose a UCP-compliant agent surface on top of it?"

#Can UCP work without NDC?

Yes for non-airline merchants. For airlines, technically yes, practically no.

UCP itself is content-agnostic — it's just the agent contract. Non-airline merchants (retail, lodging, food delivery, eventually B2B) don't need NDC at all; their content models are completely different.

For airlines specifically, you'd need to invent equivalent primitives for offers, orders, ancillaries and fare construction to serve the UCP endpoint with anything more than a basic flight-search-and-book. NDC has 14 years of industry work behind exactly those primitives. Greenfield airline UCP without NDC underneath is unlikely to be a faster path than wrapping NDC in.

#Will airlines that invested in NDC have an advantage in UCP?

Yes — a significant one.

UCP needs a content backend. Airlines at NDC Level 3 or higher already have the offer/order architecture that can serve a UCP endpoint with minimal new content modeling. The expensive part of agent-readiness isn't the UCP profile JSON — that's a few thousand lines of capability declarations. The expensive part is everything underneath: the offer engine, the dynamic-pricing infrastructure, the seat-map APIs, the ancillary product catalogue, the order management system. NDC adopters have spent years building exactly that. They get to repurpose it.

Airlines that haven't invested in NDC face the offer/order problem twice — once for distribution partners, again for agents. The NDC effort isn't sunk cost; it's the foundation.

#What about EDIFACT and the legacy GDS pipes?

EDIFACT is the layer NDC was designed to replace, not UCP.

The legacy world of EDIFACT messaging, PNRs and fare-construction strings (the inheritance from the EDI era of the 1980s and 1990s) is what IATA's NDC initiative has been chipping away at since 2012. UCP doesn't touch that layer — it sits one stack-level up, at the agent interface. An airline that's still primarily on EDIFACT/GDS distribution faces an NDC migration and a UCP-readiness question. They are independent migrations. Most airlines will tackle NDC first because it's the prerequisite for the content infrastructure UCP will end up wrapping.

#Which should airlines actually adopt

Depends on where you sit in the distribution stack.

If you're an airline at NDC Level 3 or higher, UCP is an incremental investment, not a parallel one. The offer/order architecture is most of the work. Build a /.well-known/ucp profile, declare your capabilities, wire a transport (MCP will almost certainly be the first) against your existing NDC backend. The hardest part will be the agent-native checkout flow — consent capture, payment mandates (AP2), tokenized payment — which is the UCP and AP2 layer, not the content layer.

If you're an airline with no or low NDC investment, don't skip NDC and jump straight to UCP. You'll need offer/order primitives either way. Use the NDC effort as the content foundation and layer UCP on top when the content layer is stable. Trying to do agentic checkout against a pre-NDC distribution architecture is rebuilding NDC under a different name.

If you're a GDS, both, and the strategic question is harder. The GDSes were the layer NDC was meant to disrupt; UCP at the agent layer either composes with the GDS (agents → GDS → NDC airline content) or routes around it (agents → airline UCP direct). The Sabre/Mindtrip/PayPal launch is the first GDS-mediated agentic booking in live consumer rollout — that's the playbook GDSes can defend with. Aggregated UCP endpoints that expose multi-carrier content are the next move.

If you're an OTA or metasearch player, your platform consumes NDC content today. The agentic future requires consuming NDC and exposing your own UCP endpoint, so that agents can shop your aggregated inventory directly. The competitive shape is the same as it is today — your value is the aggregation and the user experience — but the consumer surface changes from "user with a browser" to "AI agent with a UCP client."

If you're a corporate TMC or expense platform, watch the agent-side UCP development closely. A future in which corporate travel agents discover and book flights via UCP doesn't kill TMCs (corporate-policy enforcement, expense integration, duty-of-care reporting are all real value the agent doesn't replace), but it does change which content surfaces TMCs need to be aware of and the role of human travel counsellors in the booking flow.

#The one-line summary

UCP and NDC sit at different layers of the same airline distribution stack. NDC carries the airline content (Offers, Orders, ancillaries) that an agent-native UCP airline endpoint will expose. They're not alternatives — and airlines with NDC investment have a head start on UCP-readiness, not a wasted investment.

If your airline is mid-NDC and wondering what UCP changes about the roadmap: the answer is "less than you think on the content side, more than you think on the consent and payment side." If you want to see where retail UCP has actually landed as a reference point for the architectural shape airlines will end up adopting, browse the directory of verified UCP stores — the structural pattern is the same one airlines will inherit when the travel capability namespaces formally land.

• Check a store's UCP profile: ucpchecker.com/check
• Browse the directory: ucpchecker.com/directory
• Developer guide to /.well-known/ucp: ucpchecker.com/well-known-ucp
• Related reading: Google Opened UCP for Lodging. We Already Tested What It Needs to Handle.
• Related reading: Agentic AI in Travel: Why UCP Isn't Travel-Ready Yet — and What We Measured
• Related reading: We Tested 5 AI Models on Expiring Travel Inventory — Here's How They Failed
• Related reading: MCP vs UCP vs AP2: What is the Difference?