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

Guidance for Schema Version:

21.3

Definition of Capability

Airline

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

Seller

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

Capability: Pay for an Existing Unpaid Order or Order Items: https://standards.atlassian.net/wiki/spaces/EASD/pages/574226556

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

For all capabilities, please also consult the list of general guidelines for adherence to best practices that span across several capabilities and messages: https://standards.atlassian.net/wiki/spaces/ARMI/pages/584318980/General+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:

Airline

Minimum Requirements

OrderChangeRQ/OrderViewRS

Seller

Minimum Requirements

OrderChangeRQ/OrderViewRS

 

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.