Chapter 7.2 — NDC (New Distribution Capability)

1. Purpose

This chapter defines travoBooks' NDC integration model: how the platform consumes airline-direct NDC connections (per IATA's NDC Schema 21.3 / 22.3 / current version) for offer retrieval, order creation, payment, servicing, and refund. NDC is increasingly the channel through which airlines distribute differentiated content — branded fares, ancillaries, rich attributes — that GDS channels do not consistently surface.

2. Why it matters

• Content differentiation: NDC offers richer fares (branded fares, ancillaries, dynamic offers) than legacy ATPCO via GDS.
• Commercial alignment: Many airlines pay incentives to volume via NDC channels.
• Future-state: GDS↔NDC dual-distribution is the current reality; NDC-only flows are increasing.
• Settlement model differs: NDC orders typically settle via direct airline arrangement or NDC-enabled BSP — not via the traditional BSP ticket flow.

3. NDC vs traditional GDS — key differences

Dimension	Traditional GDS	NDC
Pricing	ATPCO filed fares	Airline dynamic offers
Branding	Limited	Rich brand display per offer
Ancillaries	EMD-as-RFISC after ticket	Bundled in offer
Booking artefact	PNR + Ticket	Order + Order Items
Settlement	BSP standard	Direct or BSP NDC variant
Servicing	Re-issue, void	OrderChange / OrderCancel APIs
Identifier	PNR record locator	OrderID (UUID-like)
Schemas	XML (Amadeus, Sabre proprietary)	NDC IATA XML schema

4. Connectivity options

Per supplier, travoBooks supports two NDC paths:

4.1 Direct airline NDC

• Airline-hosted NDC endpoint.
• Airline-issued credentials.
• Airline-specific quirks despite IATA standardisation.
• travoBooks configured per supplier.ndc_endpoint.

4.2 NDC aggregator

• Third-party NDC aggregator (Travelport NDC, Sabre NDC, Travelfusion, AirGateway, etc.).
• Aggregator-issued credentials.
• Aggregator normalises supplier quirks (but may add its own).
• travoBooks configured per supplier.ndc_aggregator_id.

Both paths share the same internal interface; per-supplier configuration drives the underlying client.

5. Standard NDC operations

Operation	NDC verb	Purpose
AirShopping	AirShoppingRQ/RS	Search offers
OfferPrice	OfferPriceRQ/RS	Re-price selected offer
OrderCreate	OrderCreateRQ/RS	Convert offer to order
OrderRetrieve	OrderRetrieveRQ/RS	Get order state
OrderList	OrderListRQ/RS	List orders
OrderChange	OrderChangeRQ/RS	Modify (add segment, change pax, etc.)
OrderCancel	OrderCancelRQ/RS	Cancel order or item
OrderReshop	OrderReshopRQ/RS	Re-shop existing order
ServiceList	ServiceListRQ/RS	List ancillary services
SeatAvailability	SeatAvailabilityRQ/RS	Seat map

6. Internal NDC model

travoBooks stores NDC orders as bookings with booking.supplier_protocol = NDC. Mapping:

NDC concept	Internal table / field
OrderID	bookings.supplier_order_id
OrderItem	booking_order_items
Service (flight or ancillary)	booking_segments or booking_ancillaries
TimeLimit (price guarantee)	booking_tsts.price_valid_until
PaymentTimeLimit	bookings.payment_timelimit_at
Branded fare label	booking_segments.fare_brand
OrderState	bookings.state (mapped)

7. Settlement model

NDC settlement varies by airline and channel:

7.1 NDC via BSP

Some airlines route NDC sales through BSP with a distinct accounting code. Settlement looks like traditional BSP. The ticket number generated may follow the standard 13-digit IATA format and appear in BSP files.

7.2 Direct payment to airline

Airline collects payment from the agent directly (often by virtual card or direct debit). No BSP touch. travoBooks posts to a direct supplier-AP account (2002 AP — Airline Direct).

7.3 Net-net commercial agreement

Agent contracts net pricing with the airline; sells at marked-up rate; settles at agreed terms. Common for partners with strong negotiated agreements.

Per supplier, the platform's supplier.settlement_mode field drives downstream JE patterns: - BSP_NDC — analogous to BSP regular. - DIRECT_AIRLINE — direct AP/cash settlement. - NET_NET — principal-or-agent classification per Chapter 3.2.

8. JE patterns — direct-airline NDC

Booking creation, customer side (credit customer):

Debit  1101 AR — Customer                 X (gross to customer)
Credit 2002 AP — Airline Direct           N (net to airline)
Credit 2031 Deferred Air Revenue          C (commission/markup)
Credit 4031 Service Fee                   F (issuance service fee earned now)
Credit 2061 VAT Output                    V (if applicable)

Customer pays:

Debit  1013 Bank
Credit 1101 AR — Customer

Airline payout (we wire to airline):

Debit  2002 AP — Airline Direct
Credit 1013 Bank

Service-date recognition:

Debit  2031 Deferred Air Revenue
Credit 4011 Air Base Commission / Markup

9. Order servicing

NDC reissue/refund mechanics differ from traditional: - No void window equivalent — most airlines allow cancellation up to a defined NDC timelimit, but no universal "void before midnight" rule. - OrderChange can do reissue + ancillary adds + pax-detail edits in one transaction. - PaymentTimeLimit is critical — if exceeded, the offer expires and reshop is required.

travoBooks surfaces NDC-specific timelimits on the booking detail UI distinctly from GDS-style fare timelimits.

10. Offer caching

NDC offer responses are cacheable for short TTLs (typically 5–15 minutes) per the offer's OfferExpiration field. travoBooks respects this; offers selected after expiration trigger re-price (OfferPrice) before OrderCreate.

11. Authentication patterns

Per IATA NDC schema, the auth header is part of the message envelope. Per-airline variations: - Bearer token (OAuth2). - Mutual TLS (some airlines). - API key in custom header. - WS-Security for legacy.

Per-supplier auth config in supplier_credentials (encrypted).

12. NDC certification

IATA's NDC certification levels — Aggregator, Capable, Live — affect what operations are available with which airlines. travoBooks' per-supplier capabilities matrix tracks: - AirShopping support. - OrderCreate support. - OrderChange support (reissue). - OrderCancel support. - ServiceList for ancillaries. - Servicing capabilities.

Capability mismatches surface at runtime via NDC_CAPABILITY_NOT_SUPPORTED error.

13. Data canonicalisation

The platform normalises NDC responses to its internal model. Raw NDC envelopes stored in supplier_request_log for replay. Canonical model abstracts: - Per-segment fare brand. - Per-segment baggage allowance. - Per-segment ancillary inclusion. - Tax breakdown (carrier-imposed vs government). - Penalty / cancellation policy text.

14. Error handling

NDC error	Treatment
Schedule changed	Re-shop; restart booking flow
Offer expired	Re-shop
Payment timelimit exceeded	Re-shop
Order already cancelled	State sync; no action
Invalid passenger data	Surface to agent; non-retryable
Aggregator timeout	Retry once with backoff
Capability not supported	Surface as configuration issue

15. Observability

Per supplier per NDC operation: - Success rate (rolling). - p50/p95/p99 latency. - Error breakdown. - Capability test results (daily smoke tests).

Anomalies (success rate drop, latency spike) alert engineering.

16. Database tables touched

Table	Role
bookings.supplier_protocol = NDC	Marker
bookings.supplier_order_id	NDC OrderID
booking_order_items	NDC line items
booking_ancillaries	NDC services
supplier_request_log	NDC envelopes (raw)
supplier_capabilities	Per-supplier capability matrix
supplier_credentials	NDC auth

17. Common pitfalls

• ⚠️ Treating PaymentTimeLimit like a fare timelimit. Distinct concepts; PaymentTimeLimit is shorter and stricter.
• ⚠️ Cancellation policy parsing — NDC policy text varies wildly; capture raw + structured where possible.
• ⚠️ Brand fare display fidelity — partners may not realise the same flight has 3 NDC offers at different prices/brands.
• ⚠️ Mixing GDS and NDC for same airline — both channels may surface the same flight at different prices; commercial decision per partner config.
• 🔒 NDC credentials per partner — never share across partners.
• ⚠️ Aggregator-introduced quirks masquerading as airline behaviour — track via aggregator-specific test suite.