1

Messaging Approach

API-driven, enabling direct real-time communication between airlines and sellers.

Follows file-based exchanges (e.g., PAXLST for bookings, AIRIMP for reservations)

2

Format

XML and JSON – human-readable, structured, and based on IATA schemas (e.g., AirShoppingRQ, OrderCreateRQ, etc.)

EDIFACT – a flat file, delimited format (not human-readable) used in traditional Electronic Data Interchange (EDI) protocols.

3

Fare Types

Supports both filed and dynamically priced fares. Airlines can generate prices on-the-fly based on multiple factors like availability, demand, passenger profile, market, etc.

ex. In NDC, Air France can offer dynamic pricing: A loyal user may get ₹200 cheaper fare than a guest user — based on context, device, or history.

Only filed fares, distributed via ATPCO. These are static, pre-published fares based on RBDs (e.g., Y, M, T).

ex. In GDS, Air France offers static fares: Y26, M35 from ATPCO. Same fare shown to all.

4

Product Display

Rich content including airline branding, cabin images, aircraft info, and seat visuals.

Airlines can bundle services into custom packages – e.g., a family pack with baggage and meals.

No visuals or branded fare details. Display is restricted to price and basic flight details.

5

Ancillary Services

Full support for rich ancillaries — baggage, meals, preferred seats, lounge access, insurance, Wi-Fi, etc., all in a single API workflow.

ex. NDC booking for Emirates: You can view and add 5KG extra bag, select meals, buy lounge access, all directly in the booking via a single NDC API call.

Limited support — primarily basic services like extra baggage. For other services (meals, seats, Wi-Fi), you often need manual intervention or separate systems.

ex. GDS booking for Emirates: You might only see extra baggage; for meals/seats, you contact the airline or manage via airline website.

6

Branded Fares

Fully supported. Airlines can promote fare families (e.g., Basic, Flex, Comfort) with benefits shown in the UI.

ex. In NDC, Lufthansa shows branded fares like: Light, Classic, Flex — each with a clear benefit grid.

Not supported properly. All fares look similar; differentiation is only through fare basis code, which is not user-friendly.

ex. In GDS, Lufthansa fares may just show: Y, M, T classes without clear benefits.

7

Offer Ownership

Fully supported. Airlines can define and display fare families like Basic, Flex, Comfort, each with clear benefits (baggage, changes, meals, seat selection, etc.)

GDS owns and constructs the offer using ATPCO filed fares and airline inventory.

– same offer is shown to all users regardless of context or customer profile.

8

Commission Structure

Airline has flexibility to control commissions, incentives, and pricing strategies directly.

Controlled by GDS and negotiated with agencies.

9

Distribution Cost

Lower – Direct NDC connections bypass GDS, reducing reliance on intermediaries and cutting distribution costs.

ex. Lufthansa via NDC: Direct API with OTA; no GDS fee, more control + lower cost

High – Airlines pay GDS fees per booking (typically $10–$20 USD per segment), which adds up significantly.

ex. Lufthansa via Amadeus GDS: $18 fee/segment + EDIFACT surcharge

10

Distribution Model

Airline-centric – enables direct distribution (via airline APIs or aggregators).

GDS-centric – relies on Global Distribution Systems (Amadeus, Sabre, Travelport).

11

Payment Options

Wide range of options supported: credit/debit cards, UPI, wallets (e.g., Paytm), BNPL (Buy Now Pay Later), corporate accounts, and even airline-specific methods.

ex. In NDC, Lufthansa may support credit card, PayPal, UPI, vouchers, or corporate accounts — all selectable via API.

Limited to traditional options like credit cards or BSP/ARC settlement (used by travel agents).

ex. In GDS, a Lufthansa ticket may only allow credit card or BSP settlement.

12

Ancillary Revenue

High. Airlines can bundle, cross-sell, and upsell ancillaries like meals, seats, insurance, Wi-Fi in real time — increasing revenue.

ex. In NDC, Indigo can offer combo meals + extra legroom + travel insurance, bundled with a discount during booking.

Limited. Few ancillaries (mainly baggage), poor upselling capability. Airlines miss chances to promote extras.

ex. In GDS, Indigo may offer extra bag only. Seat selection, meals, or add-ons not pushed upfront.

13

Speed of Innovation

Rapid – Airlines can independently build and update NDC APIs. Schema is extensible and governed by IATA, allowing frequent updates and fast rollout of new features.

ex. in NDC, airline adds CarbonOffset as a new ancillary in weeks and starts offering it instantly via API.

Very slow – Major updates to GDS (EDIFACT) standards or features can take years, involving complex coordination between GDS providers and airlines.

ex. Airline wants to add Carbon Offset fee: In GDS, needs global update → may take 1–2 years.

14

Integration

Developer-friendly API structure, well-documented schemas, and sandbox environments available.

Complex. Requires expertise in cryptic formats, legacy systems, and host connectivity.