Pay: Pay using Payment Gateway [PAYGTW]

Guidance for Schema Version:

20.2

Definition of Capability

Airline

This capability allows the Airline to instruct the Seller to forward the customer to the Airline's payment capability. (e.g. payment redirection)

Seller

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)

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

Links to EASD Implementation Guidance

Provide a link to the published capability specific guidance or state Not Available

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

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).

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 sent to the Seller at time of Order creation regarding where to pay and by when.

This mechanism is typically used by a merchant (the Airline) to leverage their Payment Service Provider (PSP) to capture the payment, so that the airline does not need to worry about collecting and processing sensitive payment card details. This simplifies adherence to PCI-DSS requirements on the merchant’s side.

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-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 payment card not inherently 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.

  • /IATA_AirShoppingRS/Response/PaymentFunctions/PaymentSupportedMethod/PaymentRedirection/PaymentRedirectionInd

• 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. The Seller therefore withholds from sending any actual payment details to the Airline.

  • Due to a known issue with v20.2 of the standards, the indicator needed for the Seller to confirm payment redirection as a payment mechanism (which drives the Airline to construct a redirection URL for payment processing) is missing. As a workaround, it is recommended to simply include the PaymentRedirection (even if left empty) - its presence in the XML document would constitute a Seller’s confirmation to use this payment mechanism This issue is isolated to OrderCreateRQ (the element is present in OrderChangeRQ).

    • /IATA_OrderCreateRQ/Request/PaymentFunctions/PaymentProcessingDetails/PaymentMethod/PaymentRedirection

• Airline returns an Order confirmation together with a URL.

• 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.

• Once the payment is successfully processed, the PSP notifies the Airline of the transaction and the Airline sends an OrderChangeNotificationRQ message to the Seller to update the Order with the successful payment transaction.

  • If OCN is not available, the Seller could also OrderRetrieveRQ at regular intervals to assess the status of the payment.

  • The Seller can request the Airline that the customer be redirected back to a prespecified page on the OTA’s website as soon as the payment is processed on the PSP’s site. This is done at the earlier step above, when the Seller acknowledges the use of payment redirection and provides their “ReturnURI” at this location:

    • /IATA_OrderCreateRQ/Request/PaymentFunctions/PaymentProcessingDetails/PaymentMethod/PaymentRedirection/ReturnURI

• 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 an Online Travel Agent:

In case alternate forms of payment are supported by the Airline through redirection, these can be listed using the OtherPaymentMethod structure (to be used in combination with payment redirection):

• /IATA_AirShoppingRS/Response/PaymentFunctions/PaymentSupportedMethod/OtherPaymentMethod/Remark/RemarkText

Airline

Demonstrate ability to list support 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).

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.