Technical practitioner guide · 6 November 2026 · Neerej Sasikumar

Multi-Passenger NDC Order Servicing: Change One Traveller Without Breaking the Group

Evidence boundary: IATA source descriptions are explicitly identified; operational patterns and test criteria are independent practitioner recommendations.

Why a family booking is not one indivisible itinerary

A single booking may contain several travellers who initially share flights, seats and ancillaries. One traveller later needs to depart a day earlier; another needs to retain the original journey. A simplistic implementation treats the Order as a single itinerary and either changes everybody or attempts to split a legacy reservation without checking what happens to the Order Items. Both shortcuts risk unintended changes. Modern servicing needs to identify the exact services affected, the travellers associated with those services and the commercial dependencies that must be recalculated. This is a practical architecture problem, not just a screen design problem. The critical question is which parts of the commercial agreement remain unchanged and which parts require a new offer.

What IATA guidance actually says

The IATA 20.2 Enhanced and Simplified Distribution Implementation Guide includes a dedicated section titled “Servicing Multi-passenger Order.” It describes three distinct situations: a seller changing a subset of passengers, an airline notifying a change affecting a subset, and a request to stop sharing data between passengers for privacy. Its example involves two travellers sharing outbound and return flights, then travelling separately on the outbound while keeping the return together. The guide says NDC supports non-homogeneous Orders: passengers in the same Order can be associated with different services. Crucially, when the seller requests an OrderReshop, the affected Services identify the impacted passengers by association, but the entire Order Item is reshopped and reevaluated. Implementers should not assume that an unchanged Order Item simply receives a modified service. These are statements about the cited implementation guidance, not a promise that every airline API supports every scenario.

Model Order, Order Item and Service separately

IATA's 21.3 implementation guide describes the Order structure in terms of Order, Order Items and Services, including status at each level. That hierarchy matters. An Order identifies a commercial relationship; an Order Item groups priced commitments; a Service identifies a deliverable and its passenger or segment associations. A passenger can have more than one service and a service can have related delivery details. A UI showing only the itinerary is therefore insufficient for a reliable servicing operation. It must also understand service references, order item boundaries and which monetary or entitlement consequences follow the requested change. Do not infer the price of the changed subset merely by subtracting the displayed fare of one traveller from the original total.

Worked example: one outbound changes, both returns stay

Assume two passengers, A and B, have the same outbound on 19 December and the same return on 30 December. B requests an outbound on 20 December while A remains on 19 December. The target state is two distinct outbound services and two unchanged return services. First retrieve the authoritative Order and map every Service to its passenger and flight reference. Then identify B's outbound Service as the requested change scope. Reshop the relevant Order Item according to the applicable message version and implementation contract. Inspect the returned offer items and associated prices rather than assuming the original grouping survives. Confirm the intended unchanged return services before committing the change. Finally retrieve the resulting Order and compare actual associations with the requested target state. The dates are illustrative, not a live availability or fare example.

Do not confuse a passenger split with an Order split

A different itinerary inside one Order is not necessarily the same operation as creating two Orders. IATA's published servicing material distinguishes non-homogeneous passenger services from scenarios involving separation of passenger data for privacy. The airline's implementation determines its internal Order storage and the effect on legacy PNRs or accountable documents. In a coexistence architecture, a legacy PNR split may occur while a retail Order remains one customer-facing record, or the retail servicing workflow may produce separate references. Neither behaviour should be presumed universal. The seller must treat new references, old references and cross-system correlation as explicit outcomes to verify. A reference that looks familiar in a user interface is not proof that the underlying financial and fulfilment records are still grouped in the same way.

An implementable change contract

A robust change request should carry the current Order identifier, the intended passenger and Service identifiers, the requested itinerary change, the seller's correlation key and the version or freshness information supported by that implementation. The response-processing contract should capture new offer identifiers, affected Order Item references, expiry information, price difference, applicable penalties and any additional payment or refund instructions. This list is an independent engineering recommendation; it is not a mandatory universal IATA field list. Build adapters that map these logical requirements to the actual supported schema version and partner contract. Reject an ambiguous selection before payment rather than trying to guess which passenger the customer meant.

Protect the unaffected traveller

The strongest acceptance test is not whether passenger B's new outbound appears correctly. It is whether passenger A's outbound and both return journeys remain valid and deliverable. Compare before-and-after Service references, flight associations, status, seat selections and ancillary dependencies. Some service identifiers can legitimately change during re-shopping, so a pure identifier equality check may be misleading. Instead compare intended entitlements and their fulfilment state. If an unchanged service has been repriced, cancelled or detached, flag it for reconciliation rather than silently declaring success. Where group seating or shared ancillaries matter, ask whether those relationships are preserved, transformed or explicitly released.

Payment, refund and inventory boundaries

A passenger-specific itinerary change can produce a collection, refund, even exchange or no monetary difference. That calculation belongs to the authoritative commercial response, not to the frontend. Inventory release and reacquisition may occur asynchronously, and a payment authorization does not by itself prove that the Order mutation succeeded. Use a durable change-operation identifier to prevent accidental duplicate submissions. After uncertain timeouts, retrieve the Order and reconcile payment activity before retrying. Record the result at the affected Order Item and Service levels so a later partial refund can identify what was actually changed. These are recommended operational controls; the cited IATA guidance does not prescribe a single universal transaction coordinator.

Notifications and seller synchronisation

An airline-initiated change may affect only one passenger in a multi-passenger Order. The seller needs enough information to identify the changed services without overwriting the entire group itinerary from a stale local snapshot. IATA's public NDC implementation blockers specifically discuss inconsistent Order Change Notification adoption and missing Order History support. The practical response is to treat notifications as triggers to reconcile the authoritative Order, not as the sole source of truth. Deduplicate notifications, detect missing versions when available, and re-retrieve before presenting a final state. If a notification arrives after the seller's own change, compare operation identifiers and actual service associations before applying another mutation.

Privacy is a separate design requirement

Travellers sharing an Order may later need their data separated. The IATA multi-passenger servicing guidance explicitly includes a privacy-related scenario in addition to ordinary itinerary changes. A UI that can alter flights is not automatically authorised to expose every passenger's contact, payment or identity data. Define access by passenger relationship, seller authority and the applicable privacy rules. If an Order or reservation is divided, verify that contact details, notifications, document access and consent are appropriately scoped. Preserve only the linkage necessary for servicing and audit. Do not interpret the existence of a shared Order reference as blanket permission to share all associated personal information.

Coexistence with PNR, ticket and EMD records

IATA describes ONE Order as a transition toward a single integrated customer record, gradually reducing dependence on separate PNR, ticket and EMD records. During coexistence, passenger-specific changes may need translation into legacy reservation and document operations. That creates reconciliation obligations: a new service can be visible in an Order while the associated legacy coupon or seat assignment is not yet aligned. Define a per-service crosswalk between retail references and legacy fulfilment references, record the source system of each status and quarantine mismatches. Avoid reporting a passenger as ready to travel until the required delivery systems have accepted the change. The coexistence mapping described here is a practitioner recommendation, not a claim that IATA mandates one database design.

Test matrix: failures that matter

A useful certification-style test pack includes one passenger changing only the outbound; one changing only the return; a change to both passengers; a seat linked to a replaced flight; a paid ancillary linked to an unaffected flight; simultaneous changes by seller and airline; payment success followed by Order update uncertainty; a duplicate request after timeout; an airline-initiated disruption affecting only one traveller; and privacy separation after servicing. For each case assert the final passenger-to-service graph, commercial totals, payment state, notification outcome and fulfilment evidence. Test both success and recovery, including an authoritative retrieval after each ambiguous response. A schema-valid message alone is not evidence that the business scenario has been correctly implemented.

Operational scorecard and decision rights

Track unintended changes to unaffected passengers, orphaned ancillary services, Order-versus-delivery mismatches, unresolved servicing operations, duplicate collections and time to restore a consistent Order. Segment metrics by seller, API version and scenario type without claiming industry benchmarks where none are published. Agree which party can approve an involuntary change, who owns customer communication and who reconciles any settlement difference. A change should be considered complete only when the commercial Order and the required delivery and financial records agree, or when a named exception owner is actively resolving the mismatch. This final completion criterion is an independent control proposal.

Key takeaway

Multi-passenger Order servicing is a graph transformation, not a blanket booking edit. Start with the passenger-to-service associations, honour Order Item repricing boundaries, preserve unaffected entitlements, and verify the authoritative post-change Order. Distinguish a non-homogeneous Order from a true Order split, and treat privacy, payment and legacy coexistence as explicit dimensions. IATA provides the vocabulary and documented servicing scenarios; the engineering controls proposed here turn those concepts into a testable implementation.

Original primary sources

Browse all research