IATA_OrderCreateRQ

Request · Order Management · Implemented

Implemented

Delivers: SHPOPE Multi-city / open jaw · SHPANC Shop for / with ancillaries · SHPAN2 Airline ancillaries · SHPAN3 3rd-party ancillaries (partial) · SHPMOD Transportation ancillaries · SHPSTO Seat options (partial) · SHPLOC Localised offers · SHPDSC Discounts / promotions · ORDWPM Create order without payment · ORDCRE Order with instant payment · PAYSET Settlement platform (partial) · PAYCPC Customer card · PAYVCH Vouchers · PAYMIX Mixed payment instruments · PAY3D2 Seller authenticates payer (3DS2) · PAYSUM Payment transaction summary · PAYCOM Disclosure of commission.

Limits today:

• SHPANC — ServiceListRS carries the full ServiceDefinitionList and priced à-la-carte items per segment / journey and passenger, for an offer and (post-sale) for a booked order. An AirShoppingRQ with OfferCriteria/ServiceCriteria also gets each offer's ALaCarteOffer of the airline's catalogue services — the same items and opaque ids ServiceList issues for them, orderable in OfferPrice / OrderCreate, narrowed to the requested RFIC / RFISC / Airline Taxonomy code — for the first NDC_SHOP_SERVICES_MAX_OFFERS offers, each read within a timeout and all within a deadline, fail-open (a Warning names what was not listed and whether it was transient); the rides (SHPMOD) and partner products (SHPAN3) ServiceList also lists are not shopped with the offers. An excluding criterion (IncludeInd false) removes the offers whose fare brand includes a classified bag it names; anything else a brand bundles is only text and is not filtered (a Warning says so). A fare brand's structured bag allowance (checked / cabin pieces and kg per piece, entered per fare family in the catalogue) is a BaggageAllowance (Checked / Carry on) in AirShoppingRS / OfferPriceRS / OrderViewRS for the fare-paying passengers; a brand the catalogue gives none states none. A booked order's ServiceList covers the airline's extras (Manage-My-Booking's catalogue, bought with ORDRE2); rides are SHPMOD and partner products SHPAN3.
• SHPAN2 — The Airline Product Catalog (bags, meals, wifi, priority, lounge, pets, flex) is listed, re-priced in OfferPrice by the ordering domain and ordered with the flight in OrderCreate; adding one to a booked order is ORDRE2.
• SHPAN3 — Partner (marketplace) products an admin opted into the marketplace's ndc channel are listed for an offer's trip with the partner named — each variant its own offer item, a product's options chosen from its service bundle (SelectedBundleServices) — re-priced by the ordering domain in OfferPrice and ordered with the flight in OrderCreate (captured with the marketplace, paid by the same tenders, their fulfilment shown on the order). Not sold over NDC: Arcube-connected products (session-bound offers that need supplier-specific booking fields) and marketplace bundles (capture prices a bundle from its components against a snapshot discount, and the catalogue states no price for a sum-priced one). Each product is sold once per order, a partner product needs a contact email to be delivered to, and a partner product is not added to a booked order (ORDRE2 adds airline extras and seats only).
• SHPMOD — Rail, coach and private-car rides timed to the offer's departures and arrivals (configured check-in / connection buffers) are listed, re-priced in OfferPrice by the ordering domain and ordered with the flight in OrderCreate; a ride cannot be added to a booked order (ORDRE2 adds airline extras and seats, not rides).
• SHPSTO — Seats from each flight's seat map (SeatAvailability) are priced in OfferPrice and ordered with the flight in OrderCreate, sold once across every channel. After the sale a seat change is one passenger, one seat and one flight per message: an OrderReshopRQ names one flight (OriginDestCriteria), one passenger (PaxList) and one seat (SeatCriteria), and an OrderChangeRQ buying from the order's seat map selects one seat (SelectedSeat) for one passenger; seats are reshopped and bought apart from extras (SeatCriteria and ServiceCriteria in separate OrderReshopRQs, a seat and extras in separate OrderChangeRQs).
• SHPLOC — Prices come in the requested currency. The airline’s content (fare-brand names and benefits, station, cabin, service and partner-product names, seat descriptions, promotion names, picture captions) comes in the requested language (LangUsage, else PrimaryLangID) where the airline has translated it in the Staff Console, otherwise in English with a content_language_fallback Warning naming it, and Processing/LangUsage states the languages of the content. The same applies to OrderViewRS, OrderReshopRS, ServiceListRS and SeatAvailabilityRS. Text the gateway composes (penalty, rule, ride and baggage-allowance descriptions, fee labels, warnings, errors) is English. Carrier, operator and aircraft names are proper names and are not translated. Languages are matched on the primary subtag, so zh-Hant and zh-Hans both resolve to zh, and pt-BR and pt-PT both to pt — a request for one script or region may be answered in the other. Text a supplier localised itself is passed through labelled en, whatever language it is actually in.
• ORDCRE — Books one or more offers with airline services and seats for fully described passengers (title, birth date, loyalty, contact, travel documents), idempotent on CorrelationID + TrxID, paid through the payment ledger by card tokens, vouchers, the seller’s settlement plan or the member’s loyalty points (with the redemption certificate the member issues in their account); an order sent without PaymentFunctions is held unpaid (ORDWPM); ground transport (SHPMOD) and partner products (SHPAN3) are ordered with the flight in the same OrderCreate. A passenger’s IdentityDoc is stored IN FULL by the ordering module as sensitive personal data — its type (IATA PADIS code list 7365), number, citizenship, issuing and residence countries, issue and expiry dates, the given, middle, sur- and suffix names and the title as written on the document, birth date and birthplace, and gender (ICAO Doc 9303 F/M/U/X) — with the number encrypted at rest (AES-256-GCM) and readable in the clear ONLY by an airline senior agent or supervisor who names one document and states a reason, recorded as a pii.reveal audit action naming that document and never its value. The number is in NO response, not even to the seller that sent it. Where the document is shown at all it is shown masked — its type, citizenship, issuing country, expiry and holder surname — and it is shown in OrderViewRS ALONE (OrderCreate, OrderRetrieve, OrderChange). Every other message states the passengers without it: ServiceListRS, SeatAvailabilityRS, ServiceDeliveryRS, OrderReshopRS, the accounting view, and the pushed OrderChangeNotifRQ snapshot — that one is delivered to a subscription endpoint rather than to whoever supplied the document, and what changed on an order is not a reason to send it. A document held under a type this airline cannot name is not shown at all, and the response says so (identity_document_not_shown) rather than letting the seller read silence as "no document on file". A document the airline cannot name is REFUSED rather than stored on a guess: an IdentityDocTypeCode outside PADIS 7365 (identity_document_type_unknown), a country code that is not ISO 3166-1 alpha-2 (identity_document_country_invalid), a malformed date, a gender outside ICAO Doc 9303, a missing number or holder surname, or a value longer than IdentityDocType allows — names 64 (up to five GivenName, three MiddleName), SuffixName / TitleName 16, BirthplaceText 200, IdentityDocID 60 (identity_document_invalid). PADIS 7365 codes 711 and 9PT are refused with the rest: the Code Set Directory 24.4 states no meaning for either. A document is taken at OrderCreate ONLY. One sent on OrderChangeRQ (UpdatePax included) or OrderReshopRQ is REFUSED (identity_document_not_updatable), never read and dropped: those are the messages on which a seller could reasonably believe it was updating the stored document, and being told a change succeeded while the airline discarded the document is the failure this capability exists to remove. On the shopping and listing messages that also carry a PaxList — AirShoppingRQ, OfferPriceRQ, ServiceListRQ and SeatAvailabilityRQ — a document is IGNORED rather than refused: it is not stored, not returned and not logged, and nothing on those messages could be updating one. They are not refused because OrderViewRS hands back the masked document, so a seller echoing that PaxList into a follow-up ServiceListRQ or SeatAvailabilityRQ for the same order would otherwise be refused for quoting us to ourselves. Do not send a document on them. NOT read from the document: the visas it may nest (IdentityDoc/Visa), its additional names (AddlName), and the passenger’s own RedressCase and FOID. RETENTION AND ERASURE, stated plainly because they bound how long the airline holds this. A document is erased once its TRIP is past by the configured window (ORDER_TRAVEL_DOC_RETENTION_DAYS, default 30 days after travel ends; each operator sets its own). The deadline is re-derived from the order on every sweep, so a flight moved later moves it; an order whose travel dates the platform does not hold is HELD, never erased on a deadline counted from the booking date. Erasing an account erases the documents on its orders — but an order booked over NDC for a guest has no account (the platform mints a synthetic owner per idempotency key), so for those the erasure paths are the retention sweep and an airline supervisor’s erase action, not a customer deletion. NOT DONE, and no response pretends otherwise: nothing files APIS data with a border authority or a DCS — the platform stores it, it does not transmit it; the field-encryption key is an environment secret with no KMS and no version stamped on the ciphertext, so there is no rotation path short of a bulk re-encrypt; and the web funnel still keeps its own copy of a document number in the originating quote’s cart in clear, which this channel does not touch.
• PAYSET — A SettlementPlan pays through the seller's active settlement account (CA BSP, DP ARC, MS direct bill) within its credit headroom; the sale is recorded with its settlement method — a post-sale change paid the same way (a seat, extras) as its own charge against the order: authorised (the credit reserved) before the change is made, captured after it, voided if it is not made — a leg left unfinished (an authorisation whose answer was lost, a capture or void that failed, a request that stopped) is finished by the reconciler only where that is provable: it captures a leg the commit recorded as paying for it (voiding it instead when the order or the change was cancelled since), voids a leg paying for no commit (agency-api refuses a charge arriving late under a voided reference, and a second capture for one change), and gives the rest — a change committed before its paying legs were recorded, a step still failing after its last attempt — to staff (reconcile_failed) — released per refund (every release, of the sale or of a charge, keyed so a retry gives nothing back twice), and commissioned at the agreement's percentage — or tier, in the agreement's own currency — on the charge's own amount; a flat-amount agreement states no rule for a charge made after the sale, so such a change is refused, as is one under a tiered agreement in another currency — and each is cleared under SwO by the simulated Clearance Manager (BSP by default, other methods once their clearance terms are configured). The platform is not connected to IATA's BSP: the BSP services PAConf Resolution 850 requires for NDC sales processed through BSP — NDC Onboarding (seller validation), the Agency Profile API (payment authorisation checks) and real-time sales reporting to BSP Risk Management in the EASD standard — are not implemented.
• PAYMIX — Up to four legs — card tokens, vouchers, the seller’s settlement plan and the member’s loyalty points — pay one order together: authorised together, voided together on a decline, captured after booking; a refund goes back to every leg, newest first. Points are this airline’s programme only, redeemed with the redemption certificate the member issues in their account (never on the account number alone) and valued at the programme’s redemption rate.
• PAYSUM — Every payment and refund on the order is listed in PaymentFunctions from the PaymentSession ledger: card brand + last four + PSP reference, masked voucher, settlement form of payment, loyalty points with the masked member account.

Rests on simulated supply (inventory, payment, settlement) — flagged on every response; see Simulated supply.

Create an order from priced offer items (with optional payment).

When to use

To book. Converts a priced offer into an order; the airline responds with IATA_OrderViewRS, the authoritative order snapshot.

Transport

Property	Value
Method & path	POST /24.4/OrderCreateRQ
Content-Type	application/xml
Auth	Authorization: Bearer <token> (or X-API-Key: <key>)
Routing header	IATA-Message-Name: IATA_OrderCreateRQ

See Authentication & connection for the full handshake.

Request example

note

✅ The example below validates against the original XSD.

<?xml version="1.0" encoding="UTF-8"?>
<IATA_OrderCreateRQ xmlns="http://www.iata.org/IATA/2015/EASD/00/IATA_OffersAndOrdersMessage">
  <DistributionChain>
    <DistributionChainLink xmlns="http://www.iata.org/IATA/2015/EASD/00/IATA_OffersAndOrdersCommonTypes">
      <Ordinal>1</Ordinal>
      <OrgRole>Carrier</OrgRole>
      <ParticipatingOrg>
        <OrgID>X</OrgID>
      </ParticipatingOrg>
    </DistributionChainLink>
  </DistributionChain>
  <Request>
    <CreateOrder xmlns="http://www.iata.org/IATA/2015/EASD/00/IATA_OffersAndOrdersCommonTypes">
      <AcceptOrderItemList>
        <CreateOrderItem>
          <OwnerCode>X</OwnerCode>
        </CreateOrderItem>
      </AcceptOrderItemList>
    </CreateOrder>
  </Request>
</IATA_OrderCreateRQ>

Key fields

Top-level content model of IATA_OrderCreateRQ (one level deep, including inherited content):

Field	Type	Required	Repeatable	Notes
AugmentationPoint	xs:any	—	—	extension point (AugmentationPoint)
DistributionChain	DistributionChainType	✓	—
PayloadAttributes	IATA_PayloadStandardAttributesType	—	—
POS	POS_Type	—	—
Request	OrderCreateRequestType	✓	—
Signature	DigitalSignatureType	—	—

Build it with the SDK

The @oms/ndc-24-4 package is a reference SDK — build, serialize, parse, and validate this message in code:

import { IATA_OrderCreateRQ } from '@oms/ndc-24-4';

const xml = IATA_OrderCreateRQ.toXML(payload, { pretty: true });
const obj = IATA_OrderCreateRQ.parseXML(xml);    // round-trips
IATA_OrderCreateRQ.schema.parse(obj);            // strict Zod validation

Related

• All Order Management messages
• Postman collection & SDK · OpenAPI contract