Skip to main content

IATA_OrderChangeRQ

Request · Order Management · Implemented

Implemented

Delivers: SHPSTO Seat options (partial) · SHPLOC Localised offers · ORDRSH Change needing reshop (partial) · ORDRE2 Reshop for ancillaries (partial) · ORDNAM Name change via reshop · ORDPEN Change / cancel with penalties · ORDFOR Change / cancel with forfeited amounts · ORDPAX Change without reshop (partial) · ORDCAN Cancel order item · ORDREU Cancel with reusable amount · ORDCA2 Cancel full order · PAYSET Settlement platform (partial) · PAYVCH Vouchers · PAYORD Pay for an unpaid order · PAYREF Refund amount on changes · PAYSUM Payment transaction summary · PAYRCV Payment recovery.

Limits today:

  • 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.
  • ORDRSH — New flights on other dates for the booked O&D — the outbound, the return or both — each alternative a frozen quote priced by the differential and paid on acceptance; the legs of a multi-city order are not changed one by one, and a new route is agent-assisted.
  • ORDRE2 — Airline extras (the booked order's catalogue — what Manage-My-Booking sells) and seats (its flights' seat maps) are reshopped as frozen quotes and accepted, or bought directly from the order's ServiceList / SeatAvailability; a seat is one passenger, one seat and one flight per message, and seats and extras are reshopped and bought in separate messages; ground-transport rides (SHPMOD) and partner products are not added to a booked order; a change paid by the seller's settlement plan is authorised against the agency's credit before it is made and refused under a flat-amount commission agreement, which states no rule for a charge made after the sale (commission_rule_undefined), or a tiered one stated in another currency than the change (commission_currency_mismatch); a change whose voucher or loyalty payment fails to capture stands, unpaid (no EMD), and goes to staff at once — it is not captured automatically; a loyalty hold the reconciler must give back instead (points that paid for no change) is retried for about half a day before it goes to staff, and lapses by itself at the hold's expiry.
  • ORDPAX — UpdatePax changes the booking contact (email, phone) directly; loyalty accounts and SSRs are not updated this way, and a new name is reshopped (ORDNAM).
  • 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.
  • 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.
  • PAYRCV — A declined payment leaves the order held within its payment time limit and the seller retries with OrderChangeRQ; at the limit the order is cancelled and the seller is sent an OrderChangeNotifRQ (order.payment_expired).

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

Modify an existing order — add or remove services, accept reshop offers, add payment.

When to use​

For post-booking servicing changes. The airline responds with IATA_OrderViewRS.

Transport​

PropertyValue
Method & pathPOST /24.4/OrderChangeRQ
Content-Typeapplication/xml
AuthAuthorization: Bearer <token> (or X-API-Key: <key>)
Routing headerIATA-Message-Name: IATA_OrderChangeRQ

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_OrderChangeRQ 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>
<Order xmlns="http://www.iata.org/IATA/2015/EASD/00/IATA_OffersAndOrdersCommonTypes">
<OrderID>X</OrderID>
<OwnerCode>X</OwnerCode>
</Order>
</Request>
</IATA_OrderChangeRQ>

Key fields​

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

FieldTypeRequiredRepeatableNotes
AugmentationPointxs:any——extension point (AugmentationPoint)
DistributionChainDistributionChainType✓—
PayloadAttributesIATA_PayloadStandardAttributesType——
POSPOS_Type——
RequestOrderChangeRequestType✓—
SignatureDigitalSignatureType——

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_OrderChangeRQ } from '@oms/ndc-24-4';

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