---
title: "NDC Offer/Order Lifecycle: Search to Servicing"
description: "Model NDC Offer/Order lifecycle across search, offer, revalidation, order creation, payment, ticketing, servicing and reconciliation states."
slug: "ndc-offer-order-lifecycle"
translationKey: "guide-ndc-offer-order-lifecycle"
locale: "en"
type: "guide"
category: "flight"
tags: ["ndc","offer","order","ticketing","servicing","reprice"]
publishedAt: "2026-09-26"
updatedAt: "2026-09-27"
reviewedAt: "2026-09-27"
technicalVerifiedAt: "2026-09-27"
codeExampleStatus: "illustrative"
sources:
  - title: "IATA NDC"
    url: "https://www.iata.org/en/programs/airline-distribution/retailing/ndc/"
  - title: "Travelport NDC Guide"
    url: "https://support.travelport.com/webhelp/jsonapis/airv11/content/air11/NDC/NDCGuide.htm"
  - title: "Amadeus NDC for Travel Sellers"
    url: "https://amadeus.com/en/travel-sellers/content/ndc-travel-agents"
---
In NDC, Offer and Order are different entities. An Offer is an airline retail proposition at shopping time; an Order is transaction and servicing state after booking. Collapsing both into one DTO creates stale-price, duplicate-booking and servicing errors.

## Canonical state machine

```mermaid
%% title: NDC Offer to Order to Ticket lifecycle
%% description: A flight shopping offer moves through revalidation, order creation, payment, ticketing and servicing.
stateDiagram-v2
  [*] --> Offered
  Offered --> Selected
  Selected --> Revalidating
  Revalidating --> Matched: unchanged
  Revalidating --> Changed: price / policy changed
  Revalidating --> Expired: unavailable
  Changed --> Selected: user accepts
  Matched --> OrderCreating
  OrderCreating --> OrderConfirmed: airline confirms
  OrderCreating --> OrderRejected: explicit rejection
  OrderCreating --> OrderUnknown: ambiguous outcome
  OrderUnknown --> OrderConfirmed: reconciliation finds order
  OrderUnknown --> OrderRejected: authoritative lookup finds none
  OrderConfirmed --> Ticketing
  Ticketing --> Ticketed: documents issued
  Ticketing --> TicketingUnknown: issuance outcome unclear
  Ticketed --> Servicing
  Servicing --> ChangedOrder
  Servicing --> Cancelled
  Servicing --> Refunded
```

## Offer identity

A normalized fingerprint can support deduplication but cannot replace the provider offer/reference.

Preserve source/carrier, offer ID/reference, observation time, expiry, itinerary, fare family, baggage, ancillaries, totals and penalties.

## Revalidation

After selection, stale-state risk increases. Revalidation should map to explicit outcomes:

```text
same -> continue
price changed -> user reconfirm
expired/unavailable -> re-shop
```

## Order creation and unknown state

A network timeout is not proven failure.

```text
create sent
  -> confirmed
  -> rejected
  -> no definitive response = UNKNOWN
```

Retrieve/reconcile before another create when state is UNKNOWN.

## Ticketing is not Order

A confirmed Order does not necessarily mean ticket/document issuance is complete. Keep order, payment and ticket/document state separate.

## Schedule change and servicing

Post-booking lifecycle may include involuntary schedule changes, voluntary changes, exchange, cancellation, refund and ancillary modifications. Capability varies by carrier/provider.

## Observability

Track offer age, reprice-change rate, unknown-create rate, order-to-ticket latency, schedule-change lag, servicing failures and refund reconciliation.

## Anti-patterns

- itinerary == offer,
- offer == order,
- PNR == ticket,
- timeout == failure,
- removing source lineage during normalization.


## Failure modes

- stale offer used for order creation,
- order confirmed while ticket issuance fails,
- duplicate order creation,
- ancillary or fare-family detail lost during normalization,
- delayed schedule-change propagation,
- assuming servicing capability is uniform across providers.

## Production checklist

Keep Offer and Order separate, make revalidation explicit, model UNKNOWN order state, track ticket/document state independently, maintain provider/carrier capability maps, define servicing/reconciliation paths, preserve source lineage and correlate the lifecycle end to end.