Pay: Pay Using Payment Gateway [PAYGTW]

Guidance for Schema Version:


Definition of Capability


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)

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

Links to EASD Implementation Guidance

Update links: Capability: Pay Offline Using Redirection

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

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

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

  • Once the payment is successfully processed, the PSP notifies its merchant (the Airline) of the transaction and the Airline sends an OrderChangeNotificationRQ (OCN) 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 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 at the earlier step above, when the Seller acknowledges the use of payment redirection and provides their “ReturnURI” at this location:

  • 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 need to be included in payment summaries (reference to ATSB Codeset “PAYS“): /IATA_OrderViewRS/PaymentFunctions/PaymentProcessingSummary/PaymentStatusCode


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

Minimum Requirements

Optional Messages

AirShoppingRS or OfferPriceRS


OrderCreateRQ or OrderChangeRQ



Minimum Requirements

AirShoppingRS or OfferPriceRS


OrderCreateRQ or OrderChangeRQ



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.