Interline Order Servicing Handoffs: Retailer–Supplier Contracts That Survive Disruption

Why the handoff is the hard part

A traveller purchases a journey from a Retailer, but one of its services is delivered by a Supplier. The Retailer presents the itinerary and may take the payment; the Supplier controls operational facts about its own service. A schedule change, voluntary exchange, baggage amendment or refund request can therefore cross two order systems and several operational records. The difficult question is not whether an API call succeeds. It is whether the two parties agree on who is authorised to change what, which commitment is current and who tells the customer.

The Standard Retailer and Supplier Interline Agreement (SRSIA) is the partnership context for this problem. IATA describes an Offers and Orders interline framework built around clearly agreed customer responsibility and appropriate data exchange at touchpoints. Its published AIDM interline examples show distinct Retailer and Supplier Order identifiers. Those examples are useful design evidence, not a universal promise that every airline uses the same implementation or message version.

Standards boundary: IATA material establishes the Retailer–Supplier framework and describes example exchanges. The handoff contracts, states, timeout thresholds, sample payload and KPIs proposed below are practitioner recommendations. They are not mandatory IATA fields or an interpretation of any particular bilateral agreement.

Separate customer ownership from operational authority

Customer contact and service authority are different responsibilities. The Retailer may be the principal customer interface while the Supplier is the only party able to confirm a replacement seat or validate delivery of a supplied service. A single order number shown to the traveller does not erase the Supplier's own record. In IATA's published interline ordering example, the Supplier returns its own OrderID along with the Retailer's OrderID and relevant Order Item and Service identifiers. The interface also carries service and settlement information.

That is a strong reason to maintain a durable cross-reference table rather than relying on a human-readable locator or a traveller's name. The Retailer should be able to find every Supplier service affected by a request; the Supplier should be able to relate the request to its accepted commitment. Neither party should infer authority merely because it can technically access an endpoint.

This is an illustrative responsibility matrix. In practice the bilateral agreement, applicable regulation, channel model and disruption arrangements determine the rights. A supplier can be operationally responsible without being the customer's designated contact for every question.

Build an explicit identity and version contract

Every handoff should carry stable identifiers for the Retailer Order, Supplier Order, affected Order Item and Service, plus a unique business-operation ID. Store the correlation at creation, not after the first servicing incident. Include a schema version and an expected order version so a late update cannot silently overwrite a newer change. Preserve the original request and the confirmed response as separate immutable audit events.

For a voluntary change, record the proposed replacement, the authorising party, any price difference, and the time until the option expires. For an involuntary change, also record the disruption event, affected service and recovery authority. A service may be cancelled operationally while its commercial refund remains pending; one generic status cannot faithfully describe both.

{
  "operationId": "chg-4821",
  "retailerOrderId": "ret-1007",
  "supplierOrderId": "sup-9004",
  "supplierServiceId": "svc-31",
  "expectedSupplierVersion": 8,
  "intent": "INVOLUNTARY_REACCOMMODATION",
  "proposedOptionId": "option-12",
  "authorisedBy": "AGREED_RETAILER_RULE",
  "eventTime": "2026-10-25T08:00:00Z"
}

This JSON is a hypothetical integration envelope, not an IATA schema. It deliberately excludes passenger identity data. Production designs should use the applicable IATA message specifications and privacy controls, and exchange personal information only where necessary and authorised.

Define a two-sided servicing state machine

A simple success or failure response is inadequate for distributed servicing. We recommend tracking the Retailer's customer-facing request separately from the Supplier's fulfilment commitment. A request can move through RECEIVED → ELIGIBILITY_CHECKED → OPTION_HELD → COMMIT_REQUESTED → SUPPLIER_CONFIRMED → CUSTOMER_CONFIRMED. Alternative terminal states include REJECTED, EXPIRED and RECONCILIATION_REQUIRED. These names are local design suggestions, not IATA-defined statuses.

Do not mark the customer journey complete because a message was accepted by an API gateway. Confirm that the Supplier has committed the replacement service and that the Retailer has reconciled the resulting Order view. Acknowledgement of receipt is different from acknowledgement of business acceptance. Likewise, a notification that a flight is cancelled is evidence of an operational event, not proof that a refund or new flight is confirmed.

For each transition, specify the owner, allowed predecessor states, idempotency key, retry rule and recovery path. Reject out-of-order mutations unless the business contract explicitly permits reconciliation. Publish a time-bound escalation route for operations that cannot reach a stable state automatically.

Three handoff scenarios that reveal design gaps

1. Voluntary exchange across two suppliers

A traveller asks to move the second flight of a two-supplier itinerary. The Retailer first determines which services are affected and requests eligible alternatives from the relevant Supplier. Before presenting a final price, it checks whether the change alters connection validity, other supplier commitments or ancillaries. A customer acceptance should trigger an authorised commit sequence, not parallel blind changes to every party. If one supplier confirms and another rejects, the request moves to reconciliation with an explicit customer communication rule.

2. Involuntary cancellation with an airport handoff

A Supplier cancels a flight close to departure. Its operational event must be connected to the Retailer's customer record and any downstream service dependencies. The agreement should identify whether the airport team, Supplier or Retailer may offer immediate reaccommodation and what evidence the other party must receive. The customer should not be asked to repeat a confirmed change because the Retailer and Supplier order views update at different speeds. Offline or legacy fallback must be designed and tested before disruption occurs.

3. Ancillary refund after partial delivery

A traveller paid for an ancillary that is no longer deliverable after a flight change. The Supplier may know the service was not delivered, while the Retailer may hold the customer payment record. The parties need a consistent link among the original service, delivery evidence, refund entitlement and financial adjustment. The order should not show the ancillary as successfully delivered merely because its original purchase succeeded. This case tests whether commercial and operational states are genuinely reconciled.

Timeouts, retries and duplicate change prevention

A network timeout during a change creates an ambiguous outcome. The Supplier may have accepted the operation while the Retailer received no response. Repeating a non-idempotent request can produce a duplicate service, conflicting amendments or a second financial action. Assign a stable operation ID, persist the attempt before sending it, and provide a read-back or status enquiry route before retrying the business mutation.

We recommend an unknown outcome state rather than treating timeout as rejection. The recovery worker should query the Supplier's authoritative result using the operation ID and mapped Order references. If a result is found, reconcile and notify; if none is found after an agreed consistency window, follow the contract's retry or manual escalation policy. Payment reversals and refunds require their own idempotency and reconciliation, not merely a shared HTTP retry setting.

Retain a durable audit log of request hashes, acknowledgements, business responses, service events and operator overrides. Do not automatically replay a completed change because a delayed event arrives twice. In a hybrid environment, the same customer change may also need a legacy PNR or ticket update, but the system should track that adapter's status separately rather than assuming atomic completion across all platforms.

Make settlement and customer communications part of the contract

Servicing has commercial consequences. A replacement may alter supplier amounts, taxes, ancillary entitlement or refund liability. The Retailer and Supplier should agree which party calculates each component, who is permitted to authorise a waiver, and which event constitutes final financial evidence. IATA's SRSIA materials include billing and settlement among the framework's agreement areas, but the specific accounting workflow depends on the parties and the applicable implementation.

Customer messaging needs equal discipline. Specify who sends the initial disruption alert, who confirms a selected alternative, and how duplicate or contradictory messages are suppressed. A customer-facing status should never be ahead of the authoritative supplier commitment. When the customer contacts the other party, that party needs enough current, privacy-appropriate context to help or route the request without inventing a new commitment.

Observability and a testable readiness gate

Measure the handoff acknowledgement latency, time from customer request to supplier decision, percentage of supplier-confirmed changes reflected in the Retailer Order, unresolved cross-order divergences, duplicate-operation suppression, manual escalation volume and customer notification lag. Segment by voluntary versus involuntary change, product type, partner and legacy-adapter path. Measure successful delivery and refunds independently of API success.

Before launch, inject late responses, duplicate events, stale versions, expired alternatives, supplier unavailability, partially delivered ancillaries and conflicting airport updates. Verify that every case either converges to the same customer promise or lands in a visible, owned exception queue. Require an auditable answer to three questions: What was promised? What did the Supplier commit? What was actually delivered and settled?

A practical release gate is zero unexplained duplicate commitments in controlled tests, complete identity mapping for sampled Orders, documented ownership of every exception state, and rehearsed customer communications. These are proposed engineering acceptance criteria, not published industry benchmarks.

Related implementation guides

For the contractual context, start with What is SRSIA? and the SRSIA knowledge hub. For practical scenario exploration, use the SRSIA scenario explorer. See also seller servicing in NDC, interline disruption management and Order accounting controls.

Original sources and interpretation notes

1. IATA, Interlining with Offers & Orders: retailer–supplier roles, customer responsibility and data-sharing vision.
2. IATA Developer Portal, Passenger standards: interline implementation context and NDC/ONE Order standards families.
3. IATA AIDM 24.2, interline supplier Order confirmation example: cross-referenced Retailer and Supplier IDs and settlement details; the model labels this example Proposed.
4. IATA, Interline & Partnerships Working Group: partnership standards, servicing and disruption scope.
5. IATA, Multilateral Interline Framework: distinction between existing interline arrangements and the newer retailer–supplier model.

The article synthesises these original sources as of 25 October 2026. Any JSON envelope, state names, RACI decisions, operational thresholds or launch gates are illustrative design recommendations and should be verified against the relevant message release, bilateral agreement and local legal requirements.