Back to Blog
NDC Basics 18 min read

Published 2026-05-05 · Last updated 2026-05-17

How NDC Shopping Works Step by Step

A complete guide to the NDC shopping workflow — from search request to booking confirmation. Understand how airlines, sellers, aggregators, and travelers interact through the IATA NDC shopping process, including dynamic pricing, personalization, ancillary bundling, and API data flow.

Introduction: What Is NDC Shopping?

NDC (New Distribution Capability) shopping is the process by which a traveler or travel agent searches for flights and receives rich, personalized offers from airlines through modern API-based connections. It is the foundation of the entire NDC ecosystem — the first interaction in a workflow that can lead to booking, servicing, and long-term customer relationships.

To understand NDC shopping, it helps to contrast it with what came before. For over 40 years, airline distribution relied on EDIFACT — a fixed-format messaging standard from the 1980s that transmitted fare codes, cabin classes, prices, and basic availability counts in cryptic, space-constrained messages. A fare like "Y26NR" meant something to trained agents but nothing to travelers. Ancillaries were invisible. Personalization was impossible. Airlines had no control over how their products were displayed.

NDC shopping replaces that model with a structured, offer-based approach. Instead of returning a list of fares, the airline returns offers — complete product descriptions that include flight segments, branded fare names, prices, included services, optional add-ons, baggage rules, seat options, flexibility conditions, and even images. The airline constructs these offers dynamically, tailoring them to the traveler's context, loyalty status, corporate agreements, and real-time demand.

This guide walks through the entire NDC shopping workflow step by step — from the moment a search is initiated to the point where a traveler selects an offer and moves toward booking. We will explain the technical process, the business significance of each stage, and the real-world interactions between airlines, sellers, aggregators, and customers.

Why NDC Shopping Matters

NDC shopping is not just a technical upgrade. It is a fundamental shift in how airline products are discovered, compared, and sold. The commercial implications are significant for every participant in the distribution chain.

For airlines: NDC shopping restores merchandising control. Airlines can differentiate their products beyond price, present branded fare families with clear value propositions, and integrate ancillaries directly into the offer flow. Airlines using dynamic pricing through NDC report 3–8% revenue lift. The global airline ancillary market exceeded $100 billion in 2024, and NDC is the primary channel through which these products reach travelers at the point of sale.

For travel sellers (OTAs, TMCs, agencies): NDC shopping provides access to richer content that drives conversion. Branded fares with included services are easier for travelers to understand than cryptic fare codes. Integrated ancillaries create upsell opportunities that GDS-based flows simply cannot match. Accelya reports that up to 31% of NDC bookings include paid ancillaries, averaging $12 in additional revenue per ticket.

For travelers: NDC shopping means seeing the full product — not just a price. Travelers can compare what each fare includes, understand flexibility options, and add services like bags and seats during the initial search. The experience is closer to shopping on airline.com than to decoding a GDS screen.

For the industry: NDC shopping is the foundation for the future of airline retailing. It enables ONE Order, AI-driven offers, continuous pricing, and embedded travel distribution. The NDC aggregator market was valued at $1.8 billion in 2025 and is projected to reach $5.4 billion by 2034. NDC transactions accounted for 21.2% of ARC-settled agency bookings in December 2025, and corporate NDC bookings grew 168% year over year.

Key Participants in the NDC Shopping Ecosystem

NDC shopping involves multiple parties, each playing a distinct role in the workflow. Understanding who does what is essential for grasping the full process.

ParticipantRole in ShoppingExamples
AirlinesConstruct and return offers based on shopping requests. Control product definition, pricing, merchandising, and channel segmentation.Lufthansa, American, British Airways, Emirates, Singapore Airlines
Travel SellersInitiate shopping requests on behalf of travelers. Receive, normalize, rank, and display offers. Manage the user experience.Expedia, Booking.com, corporate TMCs, travel agencies
AggregatorsConnect to multiple airline NDC APIs and expose a single, normalized API to sellers. Reduce integration complexity.Accelya, Duffel, Verteil, TPConnects, Amadeus NDC, Sabre NDC
Technology ProvidersBuild the platforms, middleware, and tools that enable NDC shopping. Provide normalization, caching, and observability.Navitaire, Radixx, airline IT vendors, custom platform builders
Travelers / AgentsDefine search criteria, compare offers, select products, and proceed to booking. The end users of the shopping experience.Leisure travelers, business travelers, corporate travel managers

How they interact: A traveler enters search criteria on a seller's website or app. The seller (directly or through an aggregator) sends a shopping request to one or more airlines. Each airline processes the request, constructs offers based on its commercial logic, and returns them. The seller normalizes, ranks, and displays the offers. The traveler compares and selects. The seller then moves to price confirmation and booking.

Step-by-Step NDC Shopping Workflow

The NDC shopping process follows a logical sequence from search initiation to offer selection. Each step has both a technical responsibility (what the systems do) and a user experience responsibility (what the traveler sees). Understanding both dimensions is essential for building effective NDC implementations.

End-to-end workflow at a glance:

  1. Shopping request initiation
  2. Offer request transmission
  3. Airline offer creation
  4. Dynamic pricing and personalization
  5. Offer response delivery
  6. Comparison and display
  7. Offer selection
  8. Ancillary bundling
  9. Price confirmation
  10. Booking transition

Step 1: Shopping Request Initiation

The NDC shopping process begins when a traveler or travel agent enters search criteria into a seller platform — a website, mobile app, or agent desktop. This is the point where user intent is captured and translated into a structured request.

What the traveler provides:

  • Origin and destination — airport codes or city names (e.g., JFK to LHR)
  • Travel dates — departure date, return date (for round-trip), or multiple dates (for multi-city)
  • Passenger details — number of adults, children, and infants
  • Cabin preference — economy, premium economy, business, first (optional)
  • Trip type — one-way, round-trip, or multi-city

What the seller platform adds:

  • Market context — point of sale, currency, language
  • Corporate account codes — if the traveler is booking under a corporate agreement
  • Loyalty identifiers — frequent flyer program membership numbers, if available
  • Seller identification — unique identifiers that tell the airline which channel is making the request

Business significance: The quality and completeness of the shopping request directly affects the relevance of the offers returned. A request that includes loyalty status or corporate codes enables the airline to tailor offers with personalized pricing and exclusive benefits. A request without this context returns generic offers that may be less competitive.

Technical note: The seller platform validates the request before submission — checking date formats, airport code validity, passenger count constraints, and required fields. Invalid requests are caught early to avoid unnecessary API calls and poor user experiences.

Step 2: Offer Request Transmission

Once the shopping request is validated, the seller platform transmits it to the airline — either directly or through an aggregator. This is where the NDC API shopping process begins in earnest.

Direct connection path: The seller's NDC adapter constructs an AirShoppingRQ (Air Shopping Request) message in the airline's preferred format (XML or JSON, depending on the NDC schema version). The adapter handles authentication (OAuth, API keys, or mutual TLS), applies the correct schema version, and sends the request over HTTPS to the airline's NDC endpoint.

Aggregator path: The seller sends a normalized shopping request to the aggregator's API. The aggregator translates this into airline-specific requests, fans them out to multiple airlines in parallel, collects responses, and returns a consolidated result. The seller interacts with one API; the aggregator handles the complexity behind the scenes.

Parallel vs. sequential requests: Sophisticated seller platforms send shopping requests to multiple airlines simultaneously (parallel) to minimize response time. Simpler implementations may query airlines sequentially, which increases total latency but reduces infrastructure complexity.

Timeout handling: Airlines vary in response time. Some return offers in under 2 seconds; others may take 10+ seconds. Seller platforms set timeout thresholds (typically 8–15 seconds per airline) and handle slow or failed responses gracefully — either by excluding that airline from results or by displaying partial results with a "loading" indicator.

Architecture note: A well-designed seller platform uses a routing layer to decide which airlines or aggregators to query for each search. Routing rules may be based on airline coverage, commercial agreements, route availability, or performance metrics. This layer is critical for hybrid NDC+GDS strategies.

Step 3: Airline Offer Creation

When the airline receives the shopping request, its NDC system processes the request and constructs one or more offers. This is where the airline's commercial intelligence, inventory management, and merchandising strategy come into play.

What the airline evaluates:

  • Inventory availability — which seats are available on which flights, in which cabins
  • Fare rules and restrictions — which fare brands are available for this route, date, and market
  • Demand signals — booking pace, competitor pricing, historical load factors
  • Traveler context — loyalty status, corporate agreement, point of sale, booking channel
  • Commercial strategy — which products to promote, which channels to favor, which ancillaries to bundle

What the airline constructs: Each offer is a complete product proposal containing:

  • Offer ID — a unique identifier for this specific offer
  • Flight segments — origin, destination, departure/arrival times, flight numbers, aircraft types
  • Fare brand — the branded fare name (e.g., "Economy Basic," "Business Flex")
  • Pricing — base fare, taxes, fees, total price per passenger and for the full itinerary
  • Included services — what comes with the fare (checked bags, seat selection, meals)
  • Optional services — ancillaries the traveler can add (extra bags, preferred seats, lounge access)
  • Rules and conditions — change policies, cancellation penalties, refundability
  • Descriptive content — fare descriptions, images, benefit summaries

Real-world example: A traveler searches for JFK to LHR on June 15. The airline returns three offers: Economy Lite ($450, carry-on only, non-refundable), Economy Flex ($580, one checked bag, changeable for a fee), and Business Class ($2,100, two checked bags, lounge access, fully refundable). Each offer is a complete product — not just a price point.

Step 4: Dynamic Pricing and Personalization

One of the most powerful capabilities of NDC shopping is dynamic pricing — the ability for airlines to price offers in real-time based on demand, traveler context, and commercial strategy. This is a fundamental departure from the GDS model, where fares are filed through ATPCO with fixed rules and limited real-time adjustment.

How dynamic pricing works: Instead of selecting from pre-defined fare buckets (Y, B, M, Q, etc.), the airline's pricing engine calculates a unique price for each offer based on:

  • Real-time demand — current booking pace, remaining capacity, competitor pricing
  • Traveler profile — loyalty tier, corporate agreement, booking history, market
  • Channel context — whether the request comes from airline.com, an OTA, a TMC, or an aggregator
  • Timing — how far in advance the booking is made, day of week, seasonality
  • Bundle optimization — pricing that encourages ancillary attachment through bundled discounts

Personalization in practice: Two travelers searching the same route on the same date may receive different offers. A Gold-tier loyalty member might see a discounted Business Class offer with complimentary upgrades. A corporate traveler with a negotiated agreement might see fares with flexible change policies. A leisure traveler might see Economy Lite with an ancillary bundle for bags and seats.

Continuous pricing: The most advanced NDC implementations use continuous pricing, which removes traditional fare buckets entirely. Instead of pricing at discrete points ($450, $480, $520), the airline prices each seat at a unique point derived from demand modeling — $463, $467, $471. This granularity allows airlines to capture more revenue by pricing closer to what each traveler is willing to pay.

Important consideration for sellers: Dynamic pricing means that offers can change between the time they are displayed and the time the traveler is ready to book. This is why price confirmation (Step 9) is a critical safeguard in NDC workflows. Never assume a displayed price is still valid at booking time.

Step 5: Offer Response Delivery

Once the airline has constructed its offers, it returns them to the seller through the NDC API as an AirShoppingRS (Air Shopping Response). This response contains one or more offers, each with the full product description outlined in Step 3.

Response structure: The AirShoppingRS message includes:

  • Offers — the list of product proposals, each with a unique Offer ID
  • Offer Items — individual components within each offer (flight segments, services)
  • Service Definitions — detailed descriptions of ancillary products
  • Data Lists — supporting data such as airport codes, cabin descriptions, and fare brand definitions
  • Metadata — response timestamps, currency codes, and airline-specific identifiers

Response size considerations: NDC shopping responses can be large — often 50KB to 500KB or more, depending on the number of offers, ancillaries, and descriptive content. Seller platforms must handle these responses efficiently, parsing and normalizing them without blocking the user interface.

Error handling: If the airline cannot process the request (invalid dates, no availability, system error), it returns an error response instead of offers. Seller platforms must handle these gracefully — displaying meaningful error messages, suggesting alternative dates, or falling back to GDS content where available.

Step 6: Comparison and Display

This is where the NDC shopping workflow becomes visible to the traveler. The seller platform receives offers from one or more airlines (and potentially from GDS as well), normalizes them into a consistent format, ranks them, and displays them in a way that supports comparison and decision-making.

Normalization: Because each airline structures its offers differently, the seller platform must translate airline-specific responses into a consistent internal model. This is the normalization layer — converting different field names, status values, price formats, and service descriptions into a unified representation that the display layer can work with.

Ranking and sorting: The seller platform applies ranking rules to determine the order in which offers are displayed. Common ranking factors include:

  • Price — lowest total price first
  • Duration — shortest travel time first
  • Departure time — most convenient departure times first
  • Airline preference — preferred partners or airlines with commercial agreements ranked higher
  • Value score — a composite metric that balances price, duration, and included services

Display design: A well-designed NDC shopping display shows travelers the information they need to make informed decisions:

  • Fare brand names with clear value differentiation
  • Included services highlighted (bags, seat selection, meals)
  • Flexibility conditions (changeable, refundable, non-refundable)
  • Total price with tax breakdown
  • Ancillary add-on options with pricing
  • Visual indicators for recommended or best-value options

UX best practice: Display fare families side by side with a comparison matrix showing what is included in each. Travelers make better decisions when they can see value differences at a glance, not just price differences.

Step 7: Offer Selection

After comparing offers, the traveler or agent selects one to proceed with. This selection triggers the next phase of the NDC workflow — moving from shopping toward booking.

What happens at selection:

  • The seller platform captures the selected Offer ID and the specific Offer Items the traveler wants
  • The platform stores the offer context (price, services, conditions) for the next steps
  • The traveler may be prompted to select additional options — seat preferences, meal choices, ancillary add-ons
  • The platform prepares for price confirmation (the critical validation step before booking)

Important distinction: Selecting an offer does not create a reservation. The offer is still a proposal, and it can expire or change. Nothing is confirmed until the offer is accepted, price is confirmed, and an order is created. This is one of the most common misconceptions about NDC shopping.

Session management: The seller platform must manage the shopping session state — keeping track of the selected offer, traveler inputs, and any ancillary selections. If the session times out or the traveler navigates away, the offer may no longer be valid, and the process must restart.

Step 8: Ancillary Bundling

Before moving to price confirmation, the traveler may have the opportunity to add ancillary services to their booking. This is one of the most commercially significant stages of the NDC shopping workflow.

Types of ancillaries available at this stage:

  • Baggage — additional checked bags, overweight bags, sports equipment
  • Seating — preferred seats, extra-legroom seats, exit row seats
  • Meals — pre-ordered meals, special dietary options, premium dining
  • Comfort — lounge access, priority boarding, fast-track security
  • Flexibility — changeable tickets, refundable upgrades, travel insurance
  • Bundles — pre-packaged combinations (e.g., "Comfort Bundle" with seat, bag, and priority boarding at a discounted price)

Bundling strategy: Airlines and sellers use bundling to increase ancillary attachment rates. Instead of presenting each ancillary individually (which can overwhelm travelers), bundles combine complementary services at a discount. A "Premium Bundle" might include a preferred seat, an extra bag, and lounge access for $75 — less than the $95 total if purchased separately.

Timing matters: Not all ancillaries are available at the shopping stage. Some are offered during booking, and some only after an order exists. Airlines differ significantly in what they support at each stage. A well-designed seller platform handles this variation gracefully — showing available ancillaries at the right time and deferring unavailable ones to later in the workflow.

Revenue impact: For a seller processing 100,000 NDC bookings annually, even a modest ancillary attachment rate generates significant revenue. At 31% attachment with an average of $12 per ancillary, that is $372,000 in incremental revenue — revenue that GDS-based flows would likely miss entirely.

Step 9: Price Confirmation

Price confirmation (sometimes called Offer Price) is the critical validation step that occurs after the traveler selects an offer and before the booking is created. It verifies that the selected offer is still available at the price and conditions originally displayed.

Why price confirmation is essential: Airline availability and pricing are dynamic. Between the time the offer was displayed (Step 6) and the time the traveler is ready to book (Step 10), several things may have changed:

  • The selected fare may have sold out
  • The price may have increased or decreased
  • Ancillary availability may have changed
  • Fare rules or conditions may have been updated

How it works: The seller platform sends an OfferPriceRQ (Offer Price Request) to the airline, referencing the selected Offer ID. The airline validates the offer and returns an OfferPriceRS (Offer Price Response) confirming whether the offer is still available and at what price.

If the price has changed: The seller platform must display the new price to the traveler and require explicit acceptance before proceeding. This protects both the customer experience and the seller's operational integrity. Never process a booking at a different price than what the traveler sees without their explicit consent.

If the offer is no longer available: The seller platform should inform the traveler, suggest alternatives, and allow them to return to the shopping results to select a different offer.

Best practice: Always perform price confirmation before order creation. This is non-negotiable in production NDC implementations. Skipping this step leads to booking failures, customer complaints, and operational overhead.

Step 10: Booking Transition

Once the price is confirmed, the NDC shopping workflow transitions into the booking phase. While booking is technically a separate workflow from shopping, the two are tightly connected, and a smooth transition is essential for conversion.

What happens during the transition:

  • The seller platform collects passenger details (names, dates of birth, contact information, document details)
  • Payment information is gathered and validated
  • An OrderCreateRQ (Order Create Request) is sent to the airline with the confirmed offer, passenger details, and payment data
  • The airline creates the order and returns an OrderCreateRS (Order Create Response) with a unique Order ID
  • The seller platform confirms the booking to the traveler with a confirmation number, itinerary details, and next steps

The Offer-to-Order handoff: This is the moment where the proposal (offer) becomes a confirmed purchase (order). The Offer ID is replaced by an Order ID, and the traveler's relationship with the airline shifts from shopping to servicing. All post-booking actions — cancellations, refunds, exchanges, ancillary additions — will be performed against this order.

Failure handling: If the order creation fails (payment decline, validation error, airline system issue), the seller platform must handle the failure gracefully. The traveler should see a clear error message, and the platform should preserve as much of the booking context as possible so the traveler can retry without starting over.

Post-booking: After the order is created, the seller platform should store the order ID securely, send a confirmation email to the traveler, and make the booking available for servicing (retrieval, cancellation, changes, ancillary additions).

Data Flow and API Interactions

Understanding the technical data flow between systems is essential for anyone building or managing NDC shopping integrations. Here is how the API interactions work end to end.

Direct connection data flow:

  1. Seller Frontend → Seller Backend: Search criteria captured and validated
  2. Seller Backend → Airline NDC API: AirShoppingRQ (authenticated, schema-compliant request)
  3. Airline NDC API → Seller Backend: AirShoppingRS (offers with full product descriptions)
  4. Seller Backend → Seller Frontend: Normalized, ranked offers displayed to traveler
  5. Seller Frontend → Seller Backend: Offer selection and ancillary choices
  6. Seller Backend → Airline NDC API: OfferPriceRQ (price confirmation request)
  7. Airline NDC API → Seller Backend: OfferPriceRS (confirmed or updated price)
  8. Seller Backend → Airline NDC API: OrderCreateRQ (booking request with passenger and payment data)
  9. Airline NDC API → Seller Backend: OrderCreateRS (confirmed order with Order ID)

Aggregator-mediated data flow:

  1. Seller Frontend → Seller Backend: Search criteria captured and validated
  2. Seller Backend → Aggregator API: Normalized shopping request
  3. Aggregator → Multiple Airlines: Fan-out of airline-specific requests (parallel)
  4. Multiple Airlines → Aggregator: Individual airline responses
  5. Aggregator → Seller Backend: Consolidated, normalized response
  6. Seller Backend → Seller Frontend: Offers displayed to traveler
  7. (Subsequent steps follow similar pattern through aggregator)

Key difference: In the direct path, the seller manages airline-specific adapters, authentication, and error handling for each airline. In the aggregator path, the aggregator handles this complexity, but the seller has less control over offer presentation and may lose some airline-specific richness through normalization.

Personalization Advantages in NDC Shopping

Personalization is one of the most powerful capabilities that NDC shopping enables. Unlike GDS-based shopping, which returns the same fares to every traveler, NDC allows airlines to tailor offers based on who is searching and how they are searching.

Personalization dimensions:

  • Loyalty-based: Gold-tier members see exclusive fares, complimentary upgrades, or bonus ancillaries
  • Corporate-based: Employees of companies with negotiated agreements see contracted fares with specific conditions
  • Behavior-based: Repeat travelers on a route may see offers optimized for their preferences (e.g., aisle seats, morning departures)
  • Market-based: Travelers in different markets may see different fare availability, pricing, or ancillary offerings
  • Channel-based: Airlines may offer exclusive products or pricing on specific channels (direct, OTA, TMC, aggregator)

Business impact: Personalization drives conversion and revenue. Travelers who see relevant offers are more likely to book. Airlines that personalize effectively see higher attachment rates for premium products and ancillaries. Sellers that surface personalized offers prominently see improved customer satisfaction and loyalty.

Privacy considerations: Personalization requires data — loyalty status, booking history, corporate affiliations. Sellers and airlines must handle this data in compliance with privacy regulations (GDPR, CCPA) and be transparent about how traveler data is used to tailor offers.

NDC Shopping vs. Traditional EDIFACT Shopping

To fully appreciate the NDC shopping workflow, it helps to compare it directly with the traditional EDIFACT-based shopping process that dominated airline distribution for decades.

AspectEDIFACT (GDS)NDC (API)
Data formatFixed-format EDIFACT messages — cryptic, space-constrainedFlexible XML/JSON — structured, descriptive, extensible
Response typeList of fares with codes (Y26NR, B26NR) — requires manual decodingComplete offers with names, descriptions, images, and structured data
Content richnessFare code, cabin, price, basic rules. No images, no descriptions.Branded fares, ancillaries, bundles, seat maps, images, descriptive text
PricingFiled fares through ATPCO — fixed rules, limited real-time adjustmentDynamic, continuous pricing — tailored per traveler in real-time
PersonalizationNone — same fares to every travelerPer-traveler based on loyalty, corporate deals, behavior, market
AncillariesDisconnected post-booking upsell — invisible during shoppingIntegrated into offer flow — displayed and purchasable at point of sale
Airline controlGDS controls display and merchandising — airline has limited influenceAirline owns the offer — full control over construction and presentation
Response sizeSmall — a few KB per responseLarge — 50KB to 500KB+ depending on offer richness
IntegrationSingle GDS connection covers 400+ airlinesPer-airline connections or aggregator — each requires separate integration

The bottom line: EDIFACT shopping is efficient for broad access but limited in richness. NDC shopping is richer and more flexible but requires more integration effort. The best strategy for most sellers is hybrid — using both channels to maximize content access and commercial performance.

Common Challenges in NDC Shopping Implementation

While NDC shopping offers significant advantages, implementing it in production presents several challenges that teams must anticipate and address.

1. Airline variation: Every airline implements NDC differently — different schema versions, different authentication methods, different error codes, different required fields. A seller connecting to 10 airlines must manage 10 different integration patterns. Solution: use the adapter pattern with a strong normalization layer.

2. Response latency: NDC shopping responses can be slow, especially when querying multiple airlines. A 10-second timeout per airline across 10 airlines means a potential 100-second wait. Solution: implement parallel requests, intelligent routing, and graceful degradation for slow or failed responses.

3. Offer expiration: Offers can change or expire between display and booking. Solution: always perform price confirmation before order creation. Display offer validity periods to set traveler expectations.

4. Content inconsistency: Not all airlines provide the same level of detail in their offers. Some include rich descriptions and images; others provide minimal data. Solution: design your display to handle varying levels of richness gracefully, with fallback defaults for missing content.

5. Error handling complexity: NDC error responses vary dramatically between airlines. Some are detailed and actionable; others are cryptic. Solution: implement a normalized error taxonomy that categorizes errors and provides consistent, actionable messages to users and operations teams.

6. Observability: Without proper tracing, diagnosing shopping failures across multiple airlines and systems is nearly impossible. Solution: implement end-to-end trace identifiers that flow from the frontend request through the seller backend, adapter, airline API, and back. Store structured logs with request/response payloads for every interaction.

The Future of NDC Shopping

NDC shopping is evolving rapidly. Several trends are shaping the future of how airline products will be discovered and sold through NDC channels.

ONE Order convergence: IATA's ONE Order initiative will combine NDC's offer model with a single order record, replacing PNRs, e-tickets, and EMDs. This will simplify the transition from shopping to servicing and create a more unified retailing experience.

AI-driven offers: Machine learning is being applied to offer construction, pricing, and personalization. Airlines are using AI to predict traveler preferences, optimize bundle composition, and price offers in real-time based on complex demand signals. Expect increasingly sophisticated personalization as these technologies mature.

Embedded travel: NDC APIs are enabling airline distribution to be embedded into non-travel platforms — ride-hailing apps, hotel booking sites, corporate expense tools, and even social media. The NDC shopping workflow will increasingly happen outside traditional travel seller interfaces.

Aggregator market growth: The NDC aggregator market is projected to grow from $1.8 billion in 2025 to $5.4 billion by 2034. Aggregators will continue to improve their normalization quality, servicing coverage, and API reliability, making NDC accessible to sellers of all sizes.

Real-time offer streaming: Some airlines are experimenting with streaming-based offer updates, where offers are continuously refreshed in the background as availability and pricing change. This could eliminate the need for price confirmation in some scenarios, though it introduces new complexity around session management and data consistency.

Converging channels: Airlines are building unified retailing platforms that serve both direct channels (airline.com) and third-party sellers through the same offer engine. This means the NDC shopping experience on an OTA will increasingly match the experience on airline.com — consistent offers, consistent pricing, consistent personalization.

Summary: Key Takeaways

  • NDC shopping replaces fare-based distribution with offer-based retailing. Airlines return complete product proposals, not just price points.
  • The workflow follows 10 logical steps: request initiation, transmission, offer creation, dynamic pricing, response delivery, comparison display, selection, ancillary bundling, price confirmation, and booking transition.
  • Dynamic pricing and personalization are game-changers. Airlines can tailor offers per traveler, driving 3–8% revenue lift and higher ancillary attachment rates.
  • Price confirmation is non-negotiable. Always validate offers before booking — availability and pricing can change in seconds.
  • Normalization is essential for multi-airline platforms. Use the adapter pattern to isolate airline-specific variation behind a consistent domain model.
  • NDC and GDS are complementary. Most sellers use a hybrid strategy — GDS for broad access, NDC for richer content from priority carriers.
  • Ancillary integration is a major revenue driver. Up to 31% of NDC bookings include paid ancillaries, averaging $12 per ticket.
  • The future includes ONE Order, AI-driven offers, and embedded travel. NDC shopping is the foundation for the next decade of airline retailing.

For anyone building, managing, or strategizing around airline distribution, understanding the NDC shopping workflow is no longer optional. It is the foundation for how airline products will be sold for years to come.

Frequently Asked Questions

What is the NDC shopping workflow?

The NDC shopping workflow is the end-to-end process by which a traveler searches for flights and receives personalized offers from airlines through API-based connections. It includes request initiation, offer creation, dynamic pricing, response delivery, comparison display, offer selection, ancillary bundling, price confirmation, and booking transition.

How does NDC shopping differ from GDS shopping?

GDS shopping returns a list of fares with cryptic codes (e.g., "Y26NR") using fixed-format EDIFACT messages. NDC shopping returns complete offers with branded fare names, descriptions, images, ancillaries, and structured rules using flexible XML/JSON APIs. NDC also supports dynamic pricing and personalization, which GDS cannot.

What is an NDC offer?

An NDC offer is the airline's product proposal during shopping. It includes flight segments, fare brand, pricing, included services, optional ancillaries, baggage rules, seat options, flexibility conditions, and descriptive content. An offer is a proposal, not a reservation — nothing is confirmed until an order is created.

Why is price confirmation necessary in NDC?

Because airline availability and pricing are dynamic, the offer displayed during shopping may no longer be valid by the time the traveler is ready to book. Price confirmation validates that the offer is still available at the expected price before order creation, preventing booking failures and customer dissatisfaction.

Can NDC shopping return personalized offers?

Yes. Airlines can tailor offers based on traveler loyalty status, corporate agreements, booking history, market, and channel. Two travelers searching the same route may receive different offers with different prices, included services, and ancillary options.

What role do aggregators play in NDC shopping?

NDC aggregators connect to multiple airlines' NDC APIs and expose a single, normalized API to sellers. They reduce integration complexity by handling airline-specific differences, authentication, and response normalization. Sellers integrate once with the aggregator and gain access to all airlines in the aggregator's network.

How large are NDC shopping responses?

NDC shopping responses are significantly larger than GDS responses — typically 50KB to 500KB or more, depending on the number of offers, ancillaries, and descriptive content. Seller platforms must handle these responses efficiently without blocking the user interface.

What is the biggest challenge in NDC shopping implementation?

Airline variation. Every carrier implements NDC differently — different schema versions, authentication methods, error codes, required fields, and response structures. Managing this variation across multiple airlines requires a strong normalization layer and the adapter pattern.

Continue reading