Order
The commercial record that tracks product, traveler, payment and servicing state after purchase. In flight/NDC systems, an order is not the same thing as a PNR or ticket.
Why it matters
In the flight domain, itinerary, leg, segment, carrier and seller identity are distinct. Flattening them too aggressively mixes schedule, fare, agent and booking rules. The search UI can be simple, but the source model needs enough detail for repricing and handoff.
What does it look like in practice?
The same itinerary can be sold by multiple agents with different fare brands, baggage and booking conditions. Segment schedule and seller/offer identity are different concepts.
Implementation questions
- Which legs and segments form the itinerary?
- Are marketing and operating carriers separated?
- Is agent/provider identity retained?
- Is the source reference available for repricing?
Common mistakes
- Modeling an offer as flight number plus price
- Mixing marketing and operating carriers
- Embedding agent identity into itinerary identity
Where does it appear in the travel stack?
Order commonly appears across flight, transaction layers. Its implementation should make source-of-truth, identity, freshness and transaction-ownership boundaries explicit.
Related terms
Related technical guides
Cancellation Succeeded but Local State Stale
Diagnose cases where provider cancellation succeeded but local booking state stayed stale across webhook, persistence, ordering and reconciliation layers.
Explore →Canonical Offer, Order and Booking State Model
Design canonical Offer, Order and Booking lifecycle boundaries with an explicit booking state machine for travel integrations.
Explore →NDC Offer/Order Lifecycle: Search to Servicing
Model NDC Offer/Order lifecycle across search, offer, revalidation, order creation, payment, ticketing, servicing and reconciliation states.
Explore →Order Confirmed but Ticket Not Issued Troubleshooting
Diagnose flight cases where an order is confirmed but ticket/document issuance is incomplete by separating order, payment and fulfillment state.
Explore →Webhook Replay & Idempotency Troubleshooting
Handle duplicate, delayed and out-of-order webhook events safely with deduplication, replay rules and idempotent state transitions.
Explore →Booking Lifecycle Event Model
Design travel-booking state around create, confirm, modify, cancel, fail and reconcile events with explicit ordering and idempotency.
Explore →