Skip Navigation

Supported Forms of Payment

Supported forms of payment in the Revenue Booking (B2C) flow include:

  • Apple Pay
  • Alternative Forms of Payment (AFOP) - forms other than typical forms of payment (e.g. major Credit Card, Travel Bank) with two-staged authorization
  • AFOP by PayPal
  • Credit Card - 3-DS or non-3-DS
  • Direct Debit SEPA
  • Gift Card
  • E-Voucher
  • Instalment Credit Card
  • Non-major Credit Cards (known as local Credit Cards)

    Tests were performed using AFOP (Alternative Form of Payment) when tickets are paid by using the respective local Credit Cards.
  • PagaTodo
  • PayPal
  • Points (Award Payment)
  • Remote Payment
  • Retail Payment
  • Third-Party payment
  • Travel Bank

Apple Pay

Digital Connect /purchase service enables airlines to offer Apple Pay as a payment option to their customers. Apple Pay is a way in which customers can store their credit cards with Apple in a way that syncs between Apple products such as the iPhone, iPad, or Mac. Apple Pay features a ‘Wallet’ which securely holds the customer’s credit card data and allows to use the data on-demand with different merchants and providers.

There are two ways to use Apple Pay in Digital Connect:

  1. The airline obtains the Apple Pay token and decrypts it to get the card details – card number, CAVV and ECI. The authentication data is then populated in the Payment Request with the card number to Sabre Payment Web Services (PWS) for authorization.
  2. The airline obtains the Apple Pay token and passes it via DC to the Payment Request. The payment service (PWS) decrypts the blob to obtain the card number and authentication data and sends the authorization request to the vendor with the authenticated data.

Apple Pay feature is currently available only in Digital Connect Shop and Book workflows, as a Single and Multiple Form of Payment. Supported Multiple Forms of Payment types include:

  • Loyalty Points (LP) + ApplePay (AP), with reversal for points if AP fails
  • Travel Bank (BT) + ApplePay (AP), with reversal for points if AP fails
  • ApplePay (AP) + Credit Card (CC), without reversal
  • ApplePay (AP) + 3DS, without reversal

In order to activate this functionality, please reach out to your designated Sabre Delivery contact before integration.

Alternative Forms of Payment (AFOP)

AFOP is a form of payment other than typical ones (e.g. major Credit Card, Travel Bank) with two-staged authorization.

If the airline's storefront has been configured to support alternate forms of payment; any alternate forms of payment applicable to the passenger's itinerary will appear when the passenger reaches the Payment step. The passenger can choose an alternate form of payment from the list and follow the redirect process through to Digital Experience's Confirmation step.

The experience of a passenger choosing an alternate form of payment is as follows: 

  • If the airline's storefront has been configured to support alternate forms of payment and any alternate forms of payment are applicable to the passenger's itinerary, the applicable forms of payment will be available when the passenger reaches the Payment step. If the storefront is configured to apply a surcharge for using any of the alternate forms of payment, it will be listed.
  • In the "Other Forms of Payment" section, the passenger sees a form of payment that he or she is independently authorized to use (for example, the passenger has a PayPal account), and chooses it by clicking the matching "Pay With" button (for example, the "Pay With PayPal" button).
  • Depending on the payment provider's requirements, Digital Experience will do one of the following:
    • Open a modal that informs the passenger that her or she is about to be redirected to the website of the chosen payment provider. For example, a passenger choosing to pay with PayPal will see something like the following:

The passenger clicks the "Continue to" button and is redirected to the payment provider's web site.

At the payment provider's web site, the passenger provides any required authentication and input to complete the transaction, and the provider approves the transaction.

  • Open a modal that prompts the passenger for an information that the payer requires to authenticate the passenger as a customer. For example, a passenger choosing to pay with China Union will see something like the following:

The information supplied by the passenger is passed to the payment provider as part of the request for payment authorization.

After the payment is authorized, the passenger is directed to Digital Experience's Confirmation step.

If the passenger cancels at this stage, he or she is redirected to the Digital Experience Payment step.

  • The Confirmation step displays the standard confirmation information.

Highlights

Airlines can offer AFOP as a single Form of Payment with the following sequence of Digital Connect service calls:

  1. The airline calls /paymentOptions GET and obtains a list of payment options for the current itinerary, including any applicable AFOPs (with fopCode and fopSubCode which are subsequently used in purchase request).
    The current itinerary is the list of flights selected by the passenger and held in the current session.
    The airline formats this information for display to the passenger.
  2. The passenger chooses AFOP as the payment option.
  3. The Airline initiates the purchase and ticketing process by calling /purchase POST with the two-staged authorization:
    The airline calls /purchase POST with payment type AFOP in order to retrieve data needed for 3rd party payment authorization.
    The airline calls /purchase POST with payment using the data retrieved from headers after redirecting from the 3rd party authorization page.
  4. If the authorization is successful, the /purchase service will create a PNR, EMD(s), etc.
  5. The response indicates whether the purchase is successful.
    The airline formats this information for display to the passenger.
  6. The airline can call /pnr GET to PNR details, which can be formatted for display to the passenger.

Airlines can also offer AFOPs as a final Form of Payment (in MFOP) with the following sequence of Digital Connect service calls:

  1. The airline calls /paymentOptions GET and obtains a list of payment options for the current itinerary, including any applicable AFOPs (with their fopCodes and fopSubCodes, which are subsequently used in purchase request).
    The current itinerary is the list of flights selected by the passenger and held in the current session.
    The airline formats this information for display to the passenger.
  2. The passenger chooses a combination of a standard FOP and alternate FOP as the payment option.
  3. The airline initiates the purchase and ticketing process by calling /purchase POST with the two forms of payment. The AFOP should be listed as the second (final) form of payment.
    The payment process authorizes the first form of payment and retrieves the information needed for the 3rd party authorization of the AFOP.
    If the first form of payment is authorized successfully, the payment process initiates the two-staged authorization for the AFOP.
    If the authorization of the AFOP is successful, and the 3rd party redirects back to the airline with a successful message, the airline calls /purchase POST with using the data retrieved from headers that redirected from the 3rd party authorization page.
  4. If the complete authorization process is successful, the /purchase service will proceed create a PNR, EMD(s), etc.
  5. The response indicates whether the purchase is successful and the PNR was created.
    The airline formats this information for display to the passenger.
  6. The airline can call /pnr GET to PNR details, which can be formatted for display to the passenger.

Direct Debit SEPA

The passenger is able to purchase the booking with Direct Debit (form of payment supporting the new SEPA requirements).This Form of Payment (FOP) allows customers to purchase their travel arrangements using electronic withdrawals from their personal bank accounts. It additionally provides the passengers with the benefit of not paying any FOP surcharge.

There is also support for purchasing the booking with combination of Direct Debit and Credit Card or E-Voucher. In multiple form of payment scenarios, the JSON request should send the Direct Debit payment as the second (final) FOP. In order to do that Airline needs to properly configure combinability property for the FOPs involved.

In case of combination with the E-Voucher, the E-Voucher is authorized first, before the Direct Debit. This behavior is required for any Multiple FOP with the E-Voucher.

The Rules Engine makes it possible to set up additional conditions for when Direct Debit will be offered as an FOP. The possible rules include: the transaction currency, market and the purchase time before departure.

The direct debit FOP is offered based upon 3 conditions. These conditions are configured by the client. The criteria is;

  1. Markets configured for this payment option (SEPA aligned countries Germany, Austria, Netherlands)
  2. Lead time of purchase prior to departure of OB flight ( 7+ days prior)
  3. Currency

As a customer the direct debit option for payment to be offered as a method for purchase without incurring a service fee related to CC FOP.

Highlights

Airlines can offer Direct Debit SEPA as a single form of payment with the following sequence of Digital Connect service calls:

  1. The airline calls /paymentOptions GET and obtains a list of payment options for the current itinerary including Direct Debit SEPA (if applicable). The current itinerary is the list of flights selected by the passenger and held in the current session.
    • The airline formats this information for display to the passenger.
  2. The passenger chooses Direct Debit as the payment option.
  3. The Airline initiates the purchase and ticketing process by calling /purchase POST; if the authorization is successful, the /purchase service creates a PNR, EMD(s), etc.
  4. The response indicates whether the purchase is successful.
    • The airline formats this information for display to the passenger.
  5. The airline can call /pnr GET to PNR details, which can be formatted for display to the passenger.

Airlines can also offer Direct Debit SEPA in multiple form of payment scenarios, combined with a credit card or an E-Voucher, with the following sequence of Digital Connect service calls:

  1. The airline calls /paymentOptions GET and obtains a list of first payment options for the current itinerary. (The current itinerary is the list of flights selected by the passenger and held in the current session.)
  2. The passenger chooses the first form of payment.
  3. The airline calls /paymentOptions GET and obtains a list of second (final) payment options that are combinable with the selected first payment option. The airline has been configured so that Direct Debit is combinable with a credit card or an E-Voucher, which makes Direct Debit an option for the second form of payment.
    • The airline formats this information for display to the passenger.
  4. The passenger selects Direct Debit as the final payment option.
  5. The Airline initiates the purchase and ticketing process by calling /purchase POST; the Direct Debit must be listed as the second (final) form of payment. If the authorization is successful, the /purchase service will create a PNR, EMD(s), etc.
  6. The response indicates whether the purchase is successful.
    • The airline formats this information for display to the passenger.
  7. The airline can call /pnr GET to PNR details, which can be formatted for display to the passenger.

E-Voucher / Gift Card

The passenger is able to purchase the booking with the E-Voucher or Gift Card.

There is support for purchasing the booking with combination of the E-Voucher/ Gift Card and Credit Card or Direct Debit.

For multiple forms of payment scenarios, there is a difference in the authorization sequence for the E-Voucher and Gift Card:

  • Gift Card is authorized first, then Credit Card.
  • Credit Card or Direct Debit is authorized before the E-Voucher.

Highlights

When the E-Voucher/ Gift Card balance is equal/higher than requested total amount - Airlines can offer E-Voucher/Gift Card as a Single Form of Payment with the following sequence of Digital Connect service calls:

  1. The airline calls /paymentOptions GET and obtains a list of payment options for the current itinerary including E-Voucher/ Gift Card (if applicable).
    • The current itinerary is the list of flights selected by the passenger and held in the current session.
    • The airline formats this information for display to the passenger.
  2. The passenger chooses E-Voucher/ Gift Card as the payment option.
  3. The passenger provides in case of:
    • E-Voucher - number and PIN;
    • Gift Card - number and expiry date.
  4. The Airline calls /paymentOptions/details/GC POST to retrieve the balance for the E-Voucher/ Gift Card.
    • The airline formats this information for display to the passenger. (In case of the remaining balance Airline formats also this information - the remaining balance will be kept on the E-Voucher/Gift Card for future use).
  5. The Airline initiates the purchase and ticketing process by calling /purchase POST with payment data based on /paymentOptions and /paymentOptions/details/GC; if the authorization is successful, the /purchase service will create a PNR, EMD(s), etc.
  6. The response indicates whether the purchase is successful.
    • The airline formats this information for display to the passenger.
  7. The airline can call /pnr GET to PNR details, which can be formatted for display to the passenger.

When the E-Voucher/ Gift Card balance is less than requested total amount (there is remaining balance for the trip), Airline can enable additional payment options and process payment with the following sequence of Digital Connect service calls:

  1. The airline calls /paymentOptions GET and obtains a list of payment options for the current itinerary including Direct Debit SEPA (if applicable).
    • The current itinerary is the list of flights selected by the passenger and held in the current session.
    • The airline formats this information for display to the passenger.
  2. The passenger chooses E-Voucher/ Gift Card as the payment option.
  3. The passenger provides E-Voucher number and PIN or Gift Card number and expiry date.
  4. The Airline calls /paymentOptions/details/GC POST to retrieve the balance for the E-Voucher/ Gift Card.
  5. The airline populates the E-Voucher/ Gift Card section of the payment options display with the E-Voucher/ Gift Card balance and the maximum amount that can be used to pay for the booking.
  6. The airline calls /paymentOptions POST and obtains information about which secondary forms of payment can be combined with the first selected payment option (E-Voucher/Gift Card).
    • The airline formats this information (with amounts – residual values) for display to the passenger.
  7. The passenger selects a second form of payment from the available options.
  8. The Airline initiates the purchase and ticketing process by calling /purchase POST with payment data based on /paymentOptions and /paymentOptions/details/GC; if the authorization is successful, the /purchase service will create a PNR, EMD(s), etc.
  9. The response indicates whether the purchase is successful.
    • The airline formats this information for display to the passenger.
  10. The airline can call /pnr GET to PNR details, which can be formatted for display to the passenger. 

Local Card Support

Airlines can offer local cards as forms of payment with Digital Connect services.

Note that each type of local card an airline would like to offer must be set up and configured in advance.

Prerequisites

  • FOPs must be configured correctly – each type of local credit card should be added to the configuration as a new FOP. Local credit cards must be configured in STAN and PWS.
  • The Multiple Forms of Payment feature must be activated.

Highlights

The passenger is able to pay with:

  • A single local credit card;
  • A combination of the two local credit cards;
  • Combination of one local credit card and one major credit card (e.g. American Express or Visa).

Airlines can offer combination of two local credit cards or local credit card and major credit card with the same sequence of Digital Connect service calls like we have for Multiple Forms of Payment .

Authorization:

  • If the passenger chooses two local cards, the /purchase service will authorize the cards in the same order in which they are sent.
  • If the passenger chooses a local card and a major card, the /purchase service will authorize the major credit card first, then the local credit card.

Travel Bank

Airlines can offer Travel Bank as a Form of Payment with the following sequence of Digital Connect service calls:

The passenger is logged in (at any time) before the Payment Options display:

  1. The airline calls /paymentOptions GET and obtains a list of payment options for the current itinerary (the current itinerary is the list of flights selected by the passenger and held in the current session).
  2. The passenger chooses Travel Bank as the first form of payment.
  3. The airline calls /paymentOptions/details/BT GET to retrieve Travel Bank balance for the passenger (this will only succeed if passenger logged in and the /login response indicated that the passenger has a Travel Bank account.
  4. The airline populates the Travel Bank section of the payment options display with the passenger's account balance and the maximum amount that can be used to pay for the booking.
  5. The airline calls /paymentOptions POST and obtains information about which secondary forms of payment can be combined with the first selected payment option (Travel Bank).
    • The airline formats this information (with amounts – residual values) for display to the passenger.
  6. The passenger selects a second form of payment from the available options.
  7. The Airline initiates the purchase and ticketing process by calling /purchase POST; if authorization is successful, the /purchase service will create a PNR.

The passenger is not logged in before the Payment Options are displayed

  1. The airline calls /paymentOptions GET and obtains a list of payment options for the current itinerary. (The current itinerary is the list of flights selected by the passenger and held in the current session.)
  2. The passenger chooses Travel Bank as the first form of payment.
  3. The airline prompts the passenger to log in with his account credentials (user ID and password).
  4. The airline calls /login POST to get the authentication for the user in the Travel Bank.
  5. The airline calls /paymentOptions/details/BT GET to retrieve Travel Bank balance for the user (only succeeds after the passenger is logged in and the /login response has indicated that the passenger has a Travel Bank account).
  6. The airline calls /paymentOptions POST and obtains information about what secondary forms of payment can be combined with the first selected payment option (Travel Bank).
    • The airline formats this information (with amounts – residual values) for display to the passenger.
  7. The passenger selects a second form of payment from the available options.
  8. The airline initiates the purchase and ticketing process by calling /purchase POST; if authorization is successful, the /purchase service will create a PNR

POLi

To offer more flexible payment options the passenger can pay for the booking using their Internet banking account through the POLi payment gateway. POLi - a common Australian form of payment provides a seamless and secure payment experience by connecting the passenger directly to their respective bank account, without any registration needed.

Additionally, according to the Australian regulation it is required that at least one form of payment has to be free of any additional surcharges. In case of Virgin Australia this is POLi payment.

  • POLi payment can be used only as a Single Form of Payment in the Revenue Booking Flow (B2C).
  • POLi can be used for payment of air fare, taxes, ancillaries and seats, if an airline is a Merchant of Record.
  • POLi cannot be used to pay for insurance if Merchant Travel Solutions (MTS) is used.

Prerequisites

  • POLi has to be set up as a payment type.
  • POLi is a 3rd party payment. Merchant and Authorization codes has to be put into Digital Connect configuration. URL to communication with POLi webservice has to be configured. Return URL will be provided by the UI.
  • Airline has to be POLi’s customer.

Highlights

Airlines can support passenger paying with POLi (as a single Form of Payment) with the following sequence of Digital Connect service calls:

  1. The airline prompts the passenger for search criteria and performs a booking search by initiating /products/air/search request. The service returns available flight offers. The airline formats this information for display to the passenger.
  2. The passenger continues shopping by selecting flights, seats, and ancillaries, according to the airline’s shopping sequence. Product cart is updated accordingly.
  3. When the passenger indicates that shopping is complete, the airline calls the /paymentOptions GET service and obtains a list of payment options for the current itinerary, including POLi (the current itinerary is the list of flights selected by the passenger and held in the current session.) The airline formats this information for display to the passenger.
  4. The passenger selects POLi form of payment, reviews the amount to be paid and continues with the payment.
  5. Digital Connect initiates a request with POLi by passing the authentication credentials, amount to be authorized and other information. This web service request is called InitiateTransaction and its main purpose is for POLi to authenticate Digital Connect.
  6. After Digital Connect is authenticated, POLi generates a unique TransactionRefNo and passes it to Digital Connect along with a URL to which the passenger is redirected to start the online payment. The TransactionRefNo is an identifier that makes it possible for Digital Connect and POLi to associate the PNR with the online payment transaction. This operation returns a token and a unique redirection URL. We then log the PNR, token and a timestamp to the database. The status of the PNR is set to 'open'. The passenger is redirected to the provided URL.
  7. The passenger is brought to the URL provided by POLi, where he/she is requested to select bank account, provide credentials and confirm the payment.
  8. The passenger is redirected back to the UI and the second /purchase POST call is sent.
  9. Digital Connect initiates another web service request to POLi to check the status of the payment. This request is called GetTransaction and Digital Connect is required to pass in it the corresponding TransactionRefNo that was earlier generated.
  10. If the transaction is successful, the passenger is directed to the Confirmation page. POLi is displayed as payment type in the Payment Summary component.

Error Handling Scenarios

First /purchase POST call:

  • InitiateTransaction fails (hard fail) – for all statuses other than Initiated
  • Poller behavior (initiated during first /purchase POST call) 
    GetTransaction statuses: FinancialInstitutionSelected, EULAAccepted, InProcess, Unknown - Polling is being continued unless the limit is reached (time and number of queries). If the limit is reached and the PNR is still active then Digital Connect stops the polling.
    • Cannot read GetTransaction response or unknown code is received (soft fail);
    • GetTransaction status: Completed, Cancelled, Timeout, Failed, ReceiptUnverified:
      • Completed:
        • Digital Connect proceeds with ticketing and sends confirmation email (if enabled);
        • Digital Connect queue place PNR in POLi Successful Queue (if configured);
        • Digital Connect stops polling.
      • Cancelled:
        • Digital Connect cancels PNR;
        • Digital Connect stops polling.
      • Timeout:
        • Digital Connect cancels PNR;
        • Digital Connect stops polling.
      • Failed or ReceiptUnverified:
        • Digital Connect checks configuration on how to handle Failed FOP Authorization configuration (HARD/SOFT fail).
        • Digital Connect stops polling.

Second /purchase POST call: 

  • For any other statuses:
    • TransactionStatusCode=Completed – the booking is finished:
    • TransactionStatusCode=Initiated (no redirect to POLI has been done)
      • Digital Connect adds FOP FAILED remarks;
      • Hard fail scenario
        • Digital Connect cancels PNR.
    • Hard fail
      • Http status: 500;
      • Digital Connect cancels the itinerary;
      • Digital Connect adds FOP FAILED remark.
    • Soft fail
      • Http status: 200;
      • Digital Connect keeps the itinerary.
      • Digital Connect adds PWS remarks.

Merchant Hosted vs. PSP

Hosted Merchant Hosted model is where all available Payment Methods are presented to the shopper on the merchant site. The shopper can select the specific payment method and may need to input some details depending of the payment method.

PSP Hosted model is where the shopper is simply redirected to a payment page hosted by the PSP. The PSP will list all available payment methods for the shopper to select. A hybrid model is also possible where some payment methods are hosted on the merchant site and others on the PSP site.

Redirect vs. Direct

Most alternative payment methods are redirect (also often referred to as Push Payment), where the shopper is redirected to another site to complete the payment request and redirected back to the merchant site upon completion. This is also the case for PSP Hosted model.