This capability allows the Airline to instruct the Seller to forward the customer to the Airline's payment capability. (e.g. payment redirection)
This capability allows the Seller to receive instructions from the airline to forward the customer to the Airline's payment capability. (e.g. payment redirection)
Capability: Pay Offline Using Redirection: https://standards.atlassian.net/wiki/spaces/EASD/pages/574455927
Worked Example: Payment Via Redirection with Airline Notification of Payment Success​:
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
For all capabilities, please also consult the list of general guidelines for adherence to best practices that span across several capabilities and messages: |
Payment redirection is an asynchronous payment mechanism that allows the Airline to forward the customer to an external payment capture site (or simply a payment step taking place outside the usual synchronous payment flows of NDC messages). This feature was introduced in v19.2 and is therefore not available in any versions prior to 19.2.
The Airline can, during shopping responses, indicate that certain Payment Methods are supported, but only through payment redirection. This means the Seller is warned in advance that, at the time of Order creation, they should not send payment details (e.g. Payment Card details) and that, instead, further instructions will be provided to the Seller at time of Order creation regarding where to pay and by when.
Payment redirection is inherently not an instant payment flow, as payment is always processed after the Airline returns an Order containing instructions for processing the payment.
This mechanism can be used by a merchant (the Airline) to leverage their Payment Service Provider (PSP) to capture the payment, thus delegating the collection and processing of sensitive payment card details (simplifying adherence to PCI-DSS requirements).
The Airline is integrated with their payment gateway in order 1. pre-construct the externally-hosted payment page on their PSP with details about the required payment capture (e.g. amount, currency and OrderID for easier reconciliation) and 2. for receiving real-time confirmation that a payment has been authorized and captured for a given OrderID.
In addition to the PCI-DSS-related benefits, this payment mechanism has the added value of allowing the Airline to support any number of alternate payment methods, so long as they are enabled on their payment gateway (e.g. PayPal, WeChat Pay, or any e-wallet type FOPs not directly supported within the NDC schemas).
Below is a summary of the steps in a typical flow for payment redirection:
Airline returns Offers while disclosing supported payment methods, some of which may be enabled via payment redirection.
Seller selects Offers and requests Order creation, indicating that they acknowledge and accept the payment redirection mechanism for the payment method the customer wishes to use, as well as confirms the Payment Type Code for the FOP they intend to use. The Seller therefore withholds from sending any actual payment details to the Airline.
Optional: The Seller can request to the Airline that the customer be redirected back to a prespecified page on the Seller’s website as soon as the payment is processed on the PSP’s site. This is done when the Seller acknowledges the use of payment redirection and provides their “ReturnURI” at this location:
Airline returns an Order confirmation together with a URL for payment capture:
Seller provides this URL to the customer (in the online Order confirmation or even by email) so that the customer can proceed to the site for processing the payment.
Optional: if the Seller provided a PayerReturnURI to the Airline, the customer is returned to the specified URI by the PSP.
Once the payment is successfully processed, the PSP notifies its merchant (the Airline) of the transaction and the Airline sends an OrderChangeNotifRQ (OCN) message to the Seller to update the Order with the successful payment transaction (PaymentStatusCode).
If OCN is not available, the Seller could also OrderRetrieveRQ at regular intervals to assess the status of the payment.
The Seller confirms the Order’s payment transaction to the customer.
The diagram below illustrates a full end-to-end flow for the payment redirection mechanism between an Airline and a Seller:
In case alternate forms of payment are supported by the Airline through redirection, the Payment Type should be set to “OT”, as per the Payment Codes available.
This can then be complemented with a free-text name of the alternate form of payment under Remarks:
Payment statuses should be included in payment summaries (reference to ATSB Codeset “PAYS“):
The Payment status at the time the Seller acknowledges/accepts the payment redirection Form of Payment should be “PENDING” in its response from the airline, until it is further updated by the airline to “SUCCESSFUL” from their integration to their Payment Gateway.
Demonstrate ability to list supported forms of payment through payment redirection in a shopping response.
Demonstrate construction of URL instructions returned to Seller at the time the Seller confirms accepting payment redirection as a payment mechanism (through either of the payment message: OrderCreateRQ or OrderChangeRQ).
Demonstrate full payment redirection flow through the “SUCCESSFUL” payment status.
Minimum Requirements | One of the two following message pairs |
|---|---|
AirShoppingRQ/RS or OfferPriceRQ/RS | OrderChangeNotifRQ/Acknowledgment |
OrderCreateRQ/OrderViewRS | OrderRetrieveRQ/OrderViewRS |
OrderChangeRQ/OrderViewRS (optional, depending on workflow) |
Minimum Requirements | One of the two following message pairs |
|---|---|
AirShoppingRQ/RS or OfferPriceRQ/RS | OrderChangeNotifRQ/Acknowledgment |
OrderCreateRQ/OrderViewRS | OrderRetrieveRQ/OrderViewRS |
OrderChangeRQ/OrderViewRS (optional, depending on workflow) |