Capabilities

Generated from the gateway's capability registry (apps/ndc-api/src/capabilities.ts) — the same registry its /healthz reports and the IATA comparison sheet's column K is regenerated from (pnpm ndc:capabilities). 52 implemented, 8 partial, 10 not implemented.

Every implemented or partial capability names its sandbox scenario: an automated test under apps/ndc-api/test/ that sends the NDC XML in, checks the business content and the XSD validity of what comes out. Run them with pnpm --filter @oms/ndc-api test.

Shop

SHPFLT — Shop for flights

Status	Implemented
Messages	AirShoppingRQ, OfferPriceRQ
Sandbox scenario	apps/ndc-api/test/capabilities/SHPFLT.test.ts
Simulated supply	inventory

SHPOPE — Multi-city / open jaw

Status	Implemented
Messages	AirShoppingRQ, OrderCreateRQ
Sandbox scenario	apps/ndc-api/test/capabilities/SHPOPE.test.ts
Simulated supply	inventory

SHPITL — Flights operated by other airlines

Status	Implemented
Messages	AirShoppingRQ, OfferPriceRQ
Sandbox scenario	apps/ndc-api/test/capabilities/SHPITL.test.ts
Simulated supply	inventory

SHPANC — Shop for / with ancillaries

Status	Implemented
Messages	AirShoppingRQ, ServiceListRQ, OfferPriceRQ, OrderCreateRQ, OrderRetrieveRQ
Sandbox scenario	apps/ndc-api/test/capabilities/SHPANC.test.ts
Limits	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.
Simulated supply	inventory

SHPAN2 — Airline ancillaries

Status	Implemented
Messages	ServiceListRQ, OfferPriceRQ, OrderCreateRQ
Sandbox scenario	apps/ndc-api/test/capabilities/SHPAN2.test.ts
Limits	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.
Simulated supply	inventory

SHPAN3 — 3rd-party ancillaries

Status	Partial
Messages	ServiceListRQ, OfferPriceRQ, OrderCreateRQ, OrderRetrieveRQ
Sandbox scenario	apps/ndc-api/test/capabilities/SHPAN3.test.ts
Limits	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).
Simulated supply	inventory

SHPMOD — Transportation ancillaries

Status	Implemented
Messages	ServiceListRQ, OfferPriceRQ, OrderCreateRQ
Sandbox scenario	apps/ndc-api/test/capabilities/SHPMOD.test.ts
Limits	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).
Simulated supply	inventory

SHPSRV — Airline Taxonomy

Status	Partial
Messages	ServiceListRQ, SeatAvailabilityRQ, OfferPriceRQ, OrderRetrieveRQ
Sandbox scenario	apps/ndc-api/test/capabilities/SHPSRV.test.ts
Limits	The airline services, the pre-reserved seat, the rides (SHPMOD) and the partner products (SHPAN3) sold over NDC each carry their IATA Airline Taxonomy node, where one is classified (AirlineTaxonomy: TaxonomyCode + the codeset path as DescText), on their ServiceDefinition — and a service, ride or partner product also on its offer / priced / order item — from the versioned D8 table (packages/marketplace-shared airline-taxonomy), whose every code is checked against the public IATA/EASD Airline Taxonomy Codeset (page version 3 of 2026-02-11, checked in beside the table); a marketplace airline product is classified by what it is — its type, refined by its own attribute where its instances differ (priority scope, pet carriage, equipment type, IFE plan) — and a partner product by its marketplace category, stamped by the marketplace on its eligibility feed: lounge access (1B58), fast track (26AC), airport transfers (2CEC Ground / Transport — they are cars and trains), train and bus transfers (2E7C, 2FA8), car rental (2D50), hotel vouchers (3138), eSIM (319C), travel insurance and baggage protection (3200), carbon offset (0E10). ServiceListRQ ServiceCriteria select by TaxonomyCode (a parent node matches the nodes below it), RFIC or RFISC, partner products included. Sold with NO node — and so never returned to a criterion that selects by node, RFIC or RFISC, while an exclusion keeps them: a pet shipped as cargo (the codeset has no cargo concept), an airline product with no registered type, and every partner product whose node depends on what no partner product records. The codeset’s food, drink and shopping nodes are tied to where the product is consumed (on board, within the terminal, within a lounge) and the marketplace records no point of consumption for a partner product (only the airports it is offered at), so these carry none: food and drink (coffee shop, restaurant and pre-flight dining categories), duty free (on board, collected in the terminal or shipped home), retail (apparel, electronics, general: a terminal shop or shipped), airport parking (the codeset’s only parking node is offsite), destination experiences (passes, travelcards and meet & greets share no node) and the generic buckets (partner vouchers, services, travel services); a partner category added later carries none until the table keys it. Bilateral TaxonomyFeature sub-codes are not used.

SHPSTO — Seat options

Status	Partial
Messages	SeatAvailabilityRQ, OfferPriceRQ, OrderCreateRQ, OrderReshopRQ, OrderChangeRQ
Sandbox scenario	apps/ndc-api/test/capabilities/SHPSTO.test.ts
Limits	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).
Simulated supply	inventory, payment

SHPSTA — Seat map and availability

Status	Implemented
Messages	SeatAvailabilityRQ
Sandbox scenario	apps/ndc-api/test/capabilities/SHPSTA.test.ts
Simulated supply	inventory

SHPSTP — Seat price points

Status	Implemented
Messages	SeatAvailabilityRQ
Sandbox scenario	apps/ndc-api/test/capabilities/SHPSTP.test.ts
Simulated supply	inventory

SHPPER — Personalised offers (PTC, loyalty, agreements)

Status	Implemented
Messages	AirShoppingRQ
Sandbox scenario	apps/ndc-api/test/capabilities/SHPPER.test.ts
Limits	Passenger types (the request's PTC) and ages, the authenticated seller's agreements (optionally a ContractID from OfferCriteria/ProgramCriteria of this airline's programmes) and this airline's loyalty tiers price offers through the Staff Console promotions engine, for rules that target the NDC channel. Member pricing is all-or-nothing per party — a product choice, fail-closed: it applies only when every fare-paying passenger carries this airline's account with the account holder's name (checked by the platform; an unknown or unverified account is priced exactly as no account), otherwise the party is priced as guests with a Warning; there is no per-passenger tier pricing within a party. Every offer of a member-priced shop is bound to those accounts (kept internal, as keyed MACs): OrderCreate must carry them in the holders' names, else it is refused (753); the tier is the one priced at shop (the offer's lifetime) and is not re-read at OrderCreate. An offer priced for a seller can be booked by that seller only. Personalised pricing is given to the NDC gateway alone — a shop that does not present the gateway's own credential is priced as an anonymous public shop, with no adjustments at all. If the platform credentials the offer and ordering services share do not match, an offer's binding cannot be read and it is REFUSED at OrderCreate rather than booked unbound. Reshop alternatives (OrderReshop) are priced without member or agreement adjustments, so a flight change re-prices the changed bound at the public fare: a member or agreement discount carried on it is clawed back in the change quote (and any surcharge on it refunded). A ProgramCriteria without such a ContractID, and any ProgramAccount, is reported in a Warning, not applied.
Simulated supply	inventory

SHPLOC — Localised offers

Status	Implemented
Messages	AirShoppingRQ, OfferPriceRQ, ServiceListRQ, SeatAvailabilityRQ, OrderCreateRQ, OrderRetrieveRQ, OrderChangeRQ, OrderReshopRQ
Sandbox scenario	apps/ndc-api/test/capabilities/SHPLOC.test.ts
Limits	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.
Simulated supply	inventory

SHPBND — Bundled offers

Status	Implemented
Messages	AirShoppingRQ, OfferPriceRQ
Sandbox scenario	apps/ndc-api/test/capabilities/SHPBND.test.ts
Simulated supply	inventory

SHPREV — Price points with dynamic adjustments

Status	Implemented
Messages	AirShoppingRQ, OfferPriceRQ
Sandbox scenario	apps/ndc-api/test/capabilities/SHPREV.test.ts
Limits	The price points are the offer engine's fares and fare-brand ladder; the adjustments are the Staff Console promotions engine's auto-apply rules that explicitly target the NDC channel — discounts down and surcharges up — itemised as Discount and Surcharge per offer and item and recorded on the order (its lines at what they cost, so refunds, bound cancels and divides work from what was paid; OrderViewRS states the breakdown only while the order stands at the total it was recorded for). Whenever the promotions engine cannot be asked for a shop — promotion criteria not switched on, or the engine unreachable, slow or refusing — that shop is priced with NO adjustments at all and a Warning says so: it is all-or-nothing, so SURCHARGES are dropped along with discounts (an unpriced surcharge is never added later). A surcharge is part of what the order costs: the seller's commission and the traveller's loyalty earn are both computed on the order total INCLUDING it — a deliberate rule, not an oversight. A fixed amount or cap applies only to offers priced in its own currency (never converted): elsewhere the rule is not applied and a Warning says so. Reshop alternatives (OrderReshop) are priced without these adjustments, so a flight change re-prices the changed bound at the unadjusted fare: a surcharge carried on it is refunded in the change quote (and a discount on it clawed back). Continuous (demand-shaped) pricing is a separate capability, SHPCPR.
Simulated supply	inventory

SHPDSC — Discounts / promotions

Status	Implemented
Messages	AirShoppingRQ, OfferPriceRQ, OrderCreateRQ
Sandbox scenario	apps/ndc-api/test/capabilities/SHPDSC.test.ts
Simulated supply	inventory

SHPRMD — Rich media

Status	Implemented
Messages	AirShoppingRQ, OfferPriceRQ
Sandbox scenario	apps/ndc-api/test/capabilities/SHPRMD.test.ts
Simulated supply	inventory

SHPOR1 — Offer conditions and restrictions

Status	Partial
Messages	AirShoppingRQ, OfferPriceRQ, OrderRulesRQ
Sandbox scenario	apps/ndc-api/test/capabilities/SHPOR1.test.ts
Limits	Every flight offer on this channel carries its fare brand’s own conditions — the airline’s brand policy, the terms the servicing engine applies once booked: changeable and refundable from the policy, cancellable and renameable as the engine allows. An offer whose brand policy cannot be read keeps the supplier’s conditions and says so (fare_conditions_supplier). Those conditions are frozen onto the order at booking and read back by the engine, so a booking is serviced by the terms it was sold under and not by a later edit of the policy or a rename of the brand; an order booked before they were stored falls back to today’s policy and every quote and listing says so. Changeability is judged per direction, so a round trip sold Light out and Plus back is not refused on the strength of its outbound, and OrderRulesRS states each direction’s terms when they differ. An order holding an active, unused Flexibility service is changeable under that service’s terms whatever its fare says, and the service is consumed once. OrderRulesRQ answers a booked order (OrderStructureKey: its fare conditions, servicing fees, cutoffs and live eligibility) and a quoted fare before booking (FareRef, with the OfferID it was quoted in as FareRefText: the conditions its offer carries, the brand policy and the servicing terms per time-to-departure band). No Penalty states a fee for what the fare does not allow, and the machine channels refuse a change on a fare that is not changeable (fare_not_changeable). Fares are priced per offer, not filed: a fare basis alone is refused (missing_offer_id). STILL PARTIAL: (1) the platform holds no airport time zones — the only such data in the repo covers 62 of the 112 airports it sells and belongs to a storefront package — so departure times are read as UTC and every cutoff and band edge (72h / 24h) is out by the origin’s UTC offset, up to 13 hours; (2) the change fee the engine charges (25/50/75 by band) is not keyed by fare brand, so it is charged on Plus too, contradicting that brand’s published “Free changes” benefit — a data inconsistency between the catalogue and the rule table, not a mapping gap; (3) servicing fees are rule-table integers with no currency of their own and are charged as the same raw number in every currency, so 2500 is EUR 25.00 on one order and SEK 25.00 or JPY 2500 on another; (4) only CHANGES are judged per direction — a cancel’s refundability, and the conditions OrderRulesRS states for the order as a whole, still come from the outbound direction alone, so a round trip sold non-refundable out and refundable back is refunded as non-refundable. By design rather than a gap: the airline’s own staff are never refused by the fare. An agent may change a fare that forbids it, and the engine records the override on the quote and in the audit trail instead of turning the customer away; a customer’s Flexibility is spent only when the agent asks for it.
Simulated supply	inventory

SHPAFF — Affinity shopping

Status	Not implemented
Not in scope	We are the airline, not an OTA; offer-api requires an origin and destination.

SHPCMF — Comparative shopping (fares)

Status	Not implemented
Not in scope	We are the airline, not an OTA.

SHPCMA — Comparative shopping (ancillaries)

Status	Not implemented
Not in scope	We are the airline, not an OTA.

SHPCPR — Continuous pricing

Status	Not implemented
Not in scope	Roadmap W3 (demand-shaped pricing) — needs a pricing engine, not a gateway mapping.

SHPDVC — Device types

Status	Not implemented
Not in scope	No commercial behaviour until personalisation consumes the device.

Order

ORDWPM — Create order without payment

Status	Implemented
Messages	OrderCreateRQ
Sandbox scenario	apps/ndc-api/test/capabilities/ORDWPM.test.ts
Simulated supply	inventory

ORDCRE — Order with instant payment

Status	Implemented
Messages	OrderCreateRQ
Sandbox scenario	apps/ndc-api/test/capabilities/ORDCRE.test.ts
Limits	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.
Simulated supply	inventory, payment

ORDMSK — Masked prices

Status	Not implemented
Messages	OrderCreateRQ

ORDRSH — Change needing reshop

Status	Partial
Messages	OrderReshopRQ, OrderChangeRQ
Sandbox scenario	apps/ndc-api/test/capabilities/ORDRSH.test.ts
Limits	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.
Simulated supply	inventory, payment

ORDRE2 — Reshop for ancillaries

Status	Partial
Messages	OrderReshopRQ, OrderChangeRQ, ServiceListRQ
Sandbox scenario	apps/ndc-api/test/capabilities/ORDRE2.test.ts
Limits	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.
Simulated supply	payment

ORDNAM — Name change via reshop

Status	Implemented
Messages	OrderReshopRQ, OrderChangeRQ
Sandbox scenario	apps/ndc-api/test/capabilities/ORDNAM.test.ts

ORDPEN — Change / cancel with penalties

Status	Implemented
Messages	OrderReshopRQ, OrderChangeRQ
Sandbox scenario	apps/ndc-api/test/capabilities/ORDPEN.test.ts

ORDFOR — Change / cancel with forfeited amounts

Status	Implemented
Messages	OrderReshopRQ, OrderChangeRQ
Sandbox scenario	apps/ndc-api/test/capabilities/ORDFOR.test.ts

ORDPAX — Change without reshop

Status	Partial
Messages	OrderChangeRQ
Sandbox scenario	apps/ndc-api/test/capabilities/ORDPAX.test.ts
Limits	UpdatePax changes the booking contact (email, phone) directly; loyalty accounts and SSRs are not updated this way, and a new name is reshopped (ORDNAM).

ORDCAN — Cancel order item

Status	Implemented
Messages	OrderReshopRQ, OrderChangeRQ
Sandbox scenario	apps/ndc-api/test/capabilities/ORDCAN.test.ts

ORDREU — Cancel with reusable amount

Status	Implemented
Messages	OrderReshopRQ, OrderChangeRQ
Sandbox scenario	apps/ndc-api/test/capabilities/ORDREU.test.ts

ORDCA2 — Cancel full order

Status	Implemented
Messages	OrderChangeRQ, OrderReshopRQ
Sandbox scenario	apps/ndc-api/test/capabilities/ORDCA2.test.ts
Simulated supply	payment

ORDRET — Order retrieve

Status	Implemented
Messages	OrderRetrieveRQ
Sandbox scenario	apps/ndc-api/test/capabilities/ORDRET.test.ts
Limits	The full OrderViewRS (passengers, segments, journeys, services, seats, tickets / EMDs with coupon status, payments, refunds, statuses). An e-ticket carries all its coupons: past four flown segments the ordering module issues conjunction tickets with consecutive numbers, rendered as one TicketDocInfo of up to four Tickets — the schema maximum, so one traveller’s trip is documented up to 16 coupons.

ORDHIS — Order history

Status	Implemented
Messages	OrderHistoryRQ
Sandbox scenario	apps/ndc-api/test/capabilities/ORDHIS.test.ts

ORDLST — Order list

Status	Implemented
Messages	OrderListRQ
Sandbox scenario	apps/ndc-api/test/capabilities/ORDLST.test.ts

ORDOCN — Airline-initiated change notification

Status	Implemented
Sent to you	OrderChangeNotifRQ
Sandbox scenario	apps/ndc-api/test/capabilities/ORDOCN.test.ts

ORDOC2 — Notification with advanced features

Status	Implemented
Sent to you	OrderChangeNotifRQ
Sandbox scenario	apps/ndc-api/test/capabilities/ORDOC2.test.ts

ORDDEL — Fulfilment notification (no tickets / EMDs)

Status	Implemented
Sent to you	ServiceDeliveryNotifRQ
Sandbox scenario	apps/ndc-api/test/capabilities/ORDDEL.test.ts
Limits	A service delivered with no ticket or EMD behind it is notified on its own: a seat sold for nothing when its flight flies, a partner (marketplace) product when its partner fulfils it (the marketplace's own fulfilment, delivered by the partner, read back every few minutes). Arcube connector offers are not sold over NDC (SHPAN3), so there is no fulfilment of theirs to notify.
Simulated supply	operations

ORDSTS — Status change for service delivery

Status	Implemented
Messages	ServiceDeliveryRQ
Sent to you	ServiceStatusChangeNotifRQ
Sandbox scenario	apps/ndc-api/test/capabilities/ORDSTS.test.ts
Simulated supply	operations

ORDST2 — Fulfilment notification to seller

Status	Implemented
Sent to you	ServiceStatusChangeNotifRQ, ServiceDeliveryNotifRQ
Sandbox scenario	apps/ndc-api/test/capabilities/ORDST2.test.ts
Simulated supply	operations

ORDGRP — Group orders

Status	Not implemented
Not in scope	The NDC group flow is its own design (next prompt).

ORDCWT — Orders without tickets / EMDs (standalone)

Status	Not implemented
Not in scope	A flight-less NDC order is out of scope; marketplace lines ride on flight orders.

Payment

PAYSET — Settlement platform

Status	Partial
Messages	OrderCreateRQ, OrderChangeRQ
Sandbox scenario	apps/ndc-api/test/capabilities/PAYSET.test.ts
Limits	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.
Simulated supply	settlement

PAYCPC — Customer card

Status	Implemented
Messages	OrderCreateRQ
Sandbox scenario	apps/ndc-api/test/capabilities/PAYCPC.test.ts
Simulated supply	payment

PAYGTW — Payment gateway

Status	Not implemented
Messages	OrderCreateRQ, OrderChangeRQ

PAYVCH — Vouchers

Status	Implemented
Messages	OrderCreateRQ, OrderChangeRQ
Sandbox scenario	apps/ndc-api/test/capabilities/PAYVCH.test.ts

PAYORD — Pay for an unpaid order

Status	Implemented
Messages	OrderChangeRQ
Sandbox scenario	apps/ndc-api/test/capabilities/PAYORD.test.ts
Simulated supply	payment

PAYREF — Refund amount on changes

Status	Implemented
Messages	OrderReshopRQ, OrderChangeRQ
Sandbox scenario	apps/ndc-api/test/capabilities/PAYREF.test.ts
Simulated supply	payment

PAYMIX — Mixed payment instruments

Status	Implemented
Messages	OrderCreateRQ
Sandbox scenario	apps/ndc-api/test/capabilities/PAYMIX.test.ts
Limits	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.
Simulated supply	payment

PAY3D2 — Seller authenticates payer (3DS2)

Status	Implemented
Messages	OrderCreateRQ
Sandbox scenario	apps/ndc-api/test/capabilities/PAY3D2.test.ts
Simulated supply	payment

PAYSUM — Payment transaction summary

Status	Implemented
Messages	OrderRetrieveRQ, OrderCreateRQ, OrderChangeRQ
Sandbox scenario	apps/ndc-api/test/capabilities/PAYSUM.test.ts
Limits	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.
Simulated supply	payment

PAYRCV — Payment recovery

Status	Implemented
Messages	OrderChangeRQ
Sent to you	OrderChangeNotifRQ
Sandbox scenario	apps/ndc-api/test/capabilities/PAYRCV.test.ts
Limits	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).
Simulated supply	payment

PAYCOM — Disclosure of commission

Status	Implemented
Messages	OfferPriceRQ, OrderRetrieveRQ, OrderCreateRQ
Sandbox scenario	apps/ndc-api/test/capabilities/PAYCOM.test.ts

PAYCMT — Commitment for clearance of commission

Status	Not implemented
Not in scope	Depends on clearance running against a real clearing house.

Settlement

STTCAP — Payment clearance — capture

Status	Implemented
Messages	PaymentClearanceRQ
Sent to you	PaymentClearanceNotif
Sandbox scenario	apps/ndc-api/test/capabilities/STTCAP.test.ts
Limits	The platform is the ORA and a simulated Clearance Manager (no real Settlement Manager is connected): a captured settlement-plan payment is requested for clearance at capture, and PaymentClearanceRQ clears one that is not yet — one clearance per payment, of exactly its amount.
Simulated supply	settlement

STTSUM — Payment clearance — summary

Status	Implemented
Messages	PaymentClearanceListRQ
Sandbox scenario	apps/ndc-api/test/capabilities/STTSUM.test.ts
Limits	The caller sees its own clearances, by ClearanceID, CommitmentID (the OrderID) or filter criteria; AgreementIDs are not recorded.
Simulated supply	settlement

STTCAN — Payment clearance — cancellation

Status	Implemented
Messages	PaymentClearanceCancellationRQ
Sent to you	PaymentClearanceNotif
Sandbox scenario	apps/ndc-api/test/capabilities/STTCAN.test.ts
Simulated supply	settlement

STTHST — Payment clearance — history

Status	Implemented
Messages	PaymentClearingListRQ
Sent to you	PaymentClearingNotif
Sandbox scenario	apps/ndc-api/test/capabilities/STTHST.test.ts
Limits	Clearing is a scheduled simulated batch: no bank moves anything.
Simulated supply	settlement

Accounting

ACCREP — Order sales information reporting

Status	Implemented
Sent to you	OrderSalesInformationNotifRQ
Sandbox scenario	apps/ndc-api/test/capabilities/ACCREP.test.ts
Limits	Sent on every sale, change, refund and void to the subscriptions that name accounting.sales_info (the airline's ndc:accounting grant), for every order — NDC-sold or not.

ACCRE2 — Sales reporting without tickets / EMDs

Status	Implemented
Sent to you	OrderSalesInformationNotifRQ
Sandbox scenario	apps/ndc-api/test/capabilities/ACCRE2.test.ts
Limits	A ticketless line (a marketplace / partner product, a free seat) is reported by its services with their internal values.

ACCSTS — Status change for revenue recognition

Status	Implemented
Sent to you	OrderClosingNotifRQ
Sandbox scenario	apps/ndc-api/test/capabilities/ACCSTS.test.ts
Limits	An order closes when every service is delivered, no-show or removed and the money is settled (payments captured, clearances cleared).
Simulated supply	operations, settlement

Setup

STPTST — Sandbox

Status	Implemented
Sandbox scenario	apps/ndc-api/test/capabilities/STPTST.test.ts
Limits	The public sandbox is https://ndc.retailaer.com: the NDC endpoints at /24.4/<Message>, the OAuth token at /oauth/token and these public docs at /docs/ (the Postman sandbox environment targets it). Sandbox clients are registered by the airline (client credentials); the supply behind it is simulated and flagged on the wire.
Simulated supply	inventory, payment

STPNEG — Negative test cases

Status	Implemented
Sandbox scenario	apps/ndc-api/test/capabilities/STPNEG.test.ts
Limits	One request per documented error (credentials, scope, foreign order, stale offer, card number, decline, 3-D Secure, payment time limit, rules unavailable, checked-in, stale reshop) in the Postman Negative tests folder; rules_unavailable cannot be forced in the sandbox.

STPNTF — Notification message setup

Status	Implemented
Sent to you	OrderChangeNotifRQ
Sandbox scenario	apps/ndc-api/test/capabilities/STPNTF.test.ts

STPDOC — Documentation

Status	Implemented
Sandbox scenario	apps/ndc-api/test/capabilities/STPDOC.test.ts

STPDC2 — Documentation (message reference)

Status	Implemented
Sandbox scenario	apps/ndc-api/test/capabilities/STPDC2.test.ts

STPOPM — Order-level permissions

Status	Implemented
Sandbox scenario	apps/ndc-api/test/capabilities/STPOPM.test.ts