Pay: Pay for an Existing Unpaid Order or Order Items [PAYORD]

Guidance for Schema Version:


Definition of Capability


This capability allows an Airline to accept payment for an existing Order or Order Items


This capability allows the Seller to provide payment information for an existing Order or Order Items. Payment may be for some or all Order Items.

NOTE: System Providers will use the above definition that pertains to their customers for Capabilities Verification.

Links to EASD Implementation Guidance

This capability document is currently in the SOSB Ballot process. Once the capability has been approved in the voting process, the links will be updated.

Update links: Capability: Pay for an Existing Unpaid Order or Order Items

Text from Pay for an Existing Unpaid Order or Order Items:

▪ An order exists
▪ Unpaid Order Items exist within an order
▪ Unpaid Order Items are within their
‒ Price Guarantee Time Limit (if used)
‒ Payment Time Limit

  1. A payer attempts to pay for the unpaid Order Item or Items
    a) Providing payment intent via
    i) Offline Payment Process (e.g., redirect / BSP) OR
    ii) Online Payment Process (e.g., customer card)

  2. A payee attempts to validate and accept the payment

Post Condition
▪ Seller receives a view of the confirmed Order with payment confirmation success and document details if applicable
▪ The Order details are returned with a warning message indicating the failed payment with reason for failure
Relevant Messages
▪ OrderChangeRQ
▪ OrderViewRS

Related Concepts, Capabilities and Worked Examples:

NOTE: Retailing Capabilities Verification Guidance will align to the published EASD Implementation Guidance at all times. From time to time when new guidance is published this will be updated and supersede any Retailing Capabilities Verification Guidance listed below.

Retailing Capabilities Verification Guidance

Paying for an existing Order, often referred to as “deferred payment”, allows the Seller to request the creation of an Order without having to commit payment instructions. When an Airline supports deferred payments, payment can be collected by the Seller/customer via a subsequent OrderChangeRQ message.

While an Order is being presented (in OrderViewRS) with unpaid OrderItems, the Airline would normally still disclose what are the supported forms of payment possible to the Seller. This can be done globally for the entire Order, or on a per-OrderItem-level.

The payment functions possible through OrderChangeRQ are the same as for OrderCreateRQ, except for the payment redirection mechanism, which is only supported as part of deferred payments flows.

Deferred payments can also take place following a reshopping flow, whereby certain new services or changes to existing OrderItems are committed into the Order by the airline, but paid for subsequently via another OrderChangeRQ. Again, the principles around allocating payments to existing OrderItems applies in the same way as for “instant payments” for Offers/OfferItems at the time of Order creation.

The Airline is expected to define payment time limits for any unpaid or partly-paid OrderItems:


Minimum Requirements



Minimum Requirements



NOTE: For all versions prior to that listed above (generally the most recent), the verification will be based on the guidance available for that version. In the case that no guidance is available, verification will be at IATA’s discretion.