Pay: Refund Amount for Any Change to an Order [PAYREF]

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 the Airline to provide the refundable amount due for an existing Order that the Customer wishes to cancel or change, including proof of refund as a payment transaction.

Seller

This capability allows the Seller to request the refundable amount due for an existing Order that the Customer wishes to cancel or change, including proof of refund as a payment transaction.

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

Links to EASD Implementation Guidance

Worked Example: Customer requests a change of a paid order prior to travel resulting in a refund: https://standards.atlassian.net/wiki/spaces/EASD/pages/842268768

Worked Example: Customer requests a cancellation to paid Order or OrderItems resulting in full refund: https://standards.atlassian.net/wiki/spaces/EASD/pages/817594417

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

All refund scenarios can be considered within ARM index validation for PAYREF. The use of penalties, forfeited amounts, and residual values are not reviewed or validated within PAYREF.

Servicing functionalities as of v19.2 make it possible for refunds to be requested by Sellers cancelling or replacing OrderItems by either omitting or setting the Respend Indicator to “false” during an OrderReshopRQ request:

If the RespendInd is set to true, the customer is instead requesting that any residual values on a change or cancellation be maintained within the Order so they can be reused at a later stage in subsequent reshopping.

For details on servicing functionality, see the following section of the Online Implementation Guide:

Once the Seller states their intention regarding any residual amounts (in this case, to be refunded), the reshopping operation is confirmed via OrderChangeRQ and the Airline would proceed with an instant refund of whatever refundable amounts are detailed within OrderReshopRS’s price differential:

The price differential factors in all pricing components, comparing the old OrderItem being changed versus the new OrderItem replacing it (including refundable or non-refundable taxes and fare components). This amount, together with any applicable penalty fees, drives the total refundable amount that the Seller can expect to receive.

The resulting OrderViewRS from a refund request will present the successful refund as a payment transaction with a negative amount:

Note - pre-21.3 implementations may still use OrderCancelRQ/RS, though this is not recommended, as the function for full Order cancellations has been moved to OrderChangeRQ as of 19.2+

Airline

Minimum Requirements

Optional Messages

OrderRetrieveRQ/OrderViewRS

OrderCancelRQ/RS

OrderReshopRQ/RS

OrderChangeRQ/OrderViewRS

Seller

Minimum Requirements

Optional Messages

OrderRetrieveRQ/OrderViewRS

OrderCancelRQ/RS

OrderReshopRQ/RS

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.