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

Guidance for Schema Version:

21.3 - Please consult the ARM index Schema version 21.3 regarding validation of capabilities within the ARM index program.

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

Worked Examples: Payment Worked Examples: https://standards.atlassian.net/wiki/spaces/EASD/pages/574488655

Related Concepts, Capabilities and Worked Examples:

• Concepts: Payment: https://standards.atlassian.net/wiki/spaces/EASD/pages/574619671

• Capabilities: Payment: https://standards.atlassian.net/wiki/spaces/EASD/pages/574717975

• Worked Examples: Payment: https://standards.atlassian.net/wiki/spaces/EASD/pages/574488655

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:

• /IATA_OrderViewRS/Response/Order/OrderItem/PaymentTimeLimitDateTime

Airline

Seller

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.