Skip Navigation

3D Secure

3D Secure is an authentication method allowing unique identification of cardholders for web transactions. Here the shopper is redirected to another site to verify the payment. It supports only single Authorization verification.

In 3DS1 we have 6 attributes in RedirectUrlData: defaultURL, pendingURL, approvedURL, declinedURL, errorURL and cancelURL.

3DS Overview of Expected Results

 For 3-D secure transactions, authorization will occur separately from ticketing.  Once the 3DS authentication values are obtained, credit authorization will be performed prior to    ticketing. An automated historical PNR remark will be created to    store the results of    the authentication and authorization results. 

 The 3D secure portion of the remarks is worded to accurately convey the level of security used when the Cardholder provided payment information to the merchant. Upon a   successful or unsuccessful authorization request, the PNR present will be automatically updated to    reflect the authentication status such as Success, Attempt, or Not participating (either cardholder or bank does not participate). 

 The remark will also contain a   date, partial credit card number (credit card code and last four digits of the card number), and currency code and amount.  On a second line the authorization results will be reflected as Approved with approval code, Do Not Honor, Referral, or Vendor Processing Error, followed by the ECI value, and the CAVV results.

Each cardholder enrolls with their Visa/MasterCard issuer or JCB for a 3D Secure password, which is then used for purchases on 3D Secure enabled websites.  American Express SafeKey is available for customers using 3D Secure with some PSP solutions.

Benefits to airlines:

  • Chargeback protection – reducing chargeback and fraud costs on 3D Secure sales
  • Possibility of qualification for lower transaction discount fees on web sales
  • Reduced operational expenses related to unauthorized use of cards for web sales
  • Improved sales by enhanced security and integrity of Internet purchase transactions
  • In summary, 3D Secure increases the confidence of cardholders to make more online purchases, while reducing fraud and chargeback exposure for merchants.

3D Secure diagram

3DS 2.0

Highlights

Airlines can offer Dynamic 3D Secure 2.0 functionality to passengers with the following sequence of Digital Connect service calls:

  1. Airline calls /paymentOptions GET and obtains a list of payment options for the current itinerary, including any applicable local card. (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 the Credit Card as the payment option.
  3. The Airline calls /purchase POST with payment type “CREDIT_CARD” in order to retrieve data needed for ADYEN payment authorization.
  4. The Airline calls /purchase POST with payment type “CREDIT_CARD” using the data retrieved from headers after redirecting from the ADYEN authorization page.
  5. The Airline initiates the purchase and ticketing process by calling /purchase POST; if authorization is successful, the /purchase service will create a PNR, EMD(s), etc.
  6. The response indicates whether the purchase is successful.
  7. The Airline formats this information for display to the passenger.

The card issuer performs the authentication within the app or payment form. The shopper's identity may be verified using passive, biometric, or a two-factor authentication approach. It supports multiple challenges.

In 3DS 2 we have 7 attributes in RedirectUrlData: defaultURL, pendingURL, approvedURL, declinedURL, errorURL, cancelURL and challengeURL.

ChallengeURL (string, optional): Holds the URL where the client would like to post the result of the 3rd party verification when the operation has been challenged.

SEPG will redirect the shopper to the POS challenge URL provided in the initial PaymentRQ and this will contain the ResponseCode=BEGINCHALLENGE and an embedded HTML form for challenge. The POS will then perform the following:

  • The POS will render the embedded HTML challengeform sent by SEPG in an iframe with ChallengeWindowSize as passed in the initial PaymentRQ.
  • The shopper will be prompted to enter some details in the challenge iframe window.
  • In the background the issuer processes the challenge and post the result to SEPG.
  • Based on the result one of the following could happen:
    • The issuer is satisfied with the challenge result and proceeds with the authorization. In this case SEPG will send the final redirection response to the POS return URL with the authorization outcome containing ResponseCode=APPROVED/ DECLINED/ERROR etc.
    • The issuer is not satisfied with the challenge result and will send another challenge request. SEPG will then send another redirection response to the POS with the ResponseCode=BEGINCHALLENGE. Multiple challenge requests from issuer is possible and, in such cases, POS will go through multiple challenges.

PaymentRQ contains the below attributes for 3DS2.0

<BrowserDetail BrowserJavaEnabled="true"
BrowserJavascriptEnabled="true"
BrowserScreenColorDepth="32"
BrowserScreenHeight="250"
BrowserScreenWidth="400"
BrowserSessionID="XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
BrowserTimeZoneOffset="-120"
ChallengeWindowSize="1">

<PaymentCard CardCode="XX" CardNumber="XXXXXXXXXXXXXXXX"
CardSecurityCode="XXX"
ExpireDate="XXXXXX" ReadyFor3DSVersion="2.0">

<ChallengeURL>http://xxx.xxx.sabre.com:7979/pwsair/afop_status?JSESSIONID=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX&amp;airline=XX&amp;paymentSequence=1&amp;status=challenge</ChallengeURL>

PaymentRS

 If the card is not enrolled for 3D Secure, the PaymentRS will have the authorization response with ResponseCode=

APPROVED/DECLINED/ERROR etc. along with the other authorization result fields.

 If the card is enrolled for 3D Secure the PaymentRS will have a RedirectHTML form and the ResponseCode field will have different values based on whether the issuer supports 3D Secure 2 or not.

 The POS should check the ResponseCode field value to determine the next action:

  •  If the value returned is “REDIRECT”, indicates that the issuer does not support 3D Secure 2 and fallback had happened to 3D Secure 1 by default and that the shopper should be redirected to an external web page to complete the authorization. Therefore, the POS proceeds with the existing 3D Secure 1 flow.
  • If the value returned is ”INITIALIZEIFRAME”, indicates that it is a 3D Secure 2 flow and the issuer requires the shopper's device fingerprint before the payment can be authenticated. In this case, POS will submit the HTML form received in the PaymentRS in a hidden 1x1 iframe. In the background the bank will perform the device fingerprinting.
<AuthorizationResult ResponseCode="INITIALIZEIFRAME" Description="IDENTIFYSHOPPER"
SupplierID="ADYEN" SupplierTransID="XXXXXXXXXXXXXXX" SupplierReferenceID="XXXXXXXXXXXXXXXX"
SupplierResponseCode="00" PaymentConfirmInd="R" PaymentRef="XXXXXXXXXXXXXXXXXXXX">
<T3DS_ResultIssuerURL="https://xxx.xxx.sabre.com/ipe/adyen3d2?merchantReference=XXXXXXXXXXXXXXXXXXXX&amp;merchantId=XX">
<AdditionalDetail>
<Field>
<Name>threeDS2Token</Name>

<Value>https://xxx.xxx.sabre.com/ipe/adyen3d2response?merchantReference=XXXXXXXXXXXXXXXXXXXX&amp;merchantId=PK</Value>
</Field>
</AdditionalDetail>
</T3DS_Result>
<RedirectHTML>&lt;html&gt;&lt;bodyonload="document.getElementById('3DSecureform').submit();"&gt;&lt;form method="POST"
action="https://xxx.xxx.sabre.com/ipe/adyen3d2?merchantReference=XXXXXXXXXXXXXXXXXXXX&amp;merchantI
d=PK" name="3DSecureform" id="3DSecureform"&gt;&lt;input type="hidden" name="threeDSServerTransID"
value="368c7ab9-d98e-4f8a-8c0d-a27339690b77" /&gt;&lt;input type="hidden" name="threeDSMethodURL"
value="https://pal-test.adyen.com/threeds2simulator/acs/startMethod.shtml" /&gt;&lt;input type="hidden"
name="threeDSMethodNotificationURL" value="https://xxx.xxx.sabre.com/ipe/adyen3d2response" /&gt;&lt;input
type="hidden" name="TermUrl"
value="https://xxx.xxx.sabre.com/ipe/adyen3d2?merchantReference=XXXXXXXXXXXXXXXXXXXX&amp;merchantId
=PK" /&gt;&lt;/form&gt;&lt;/body&gt;&lt;/html&gt;</RedirectHTML>
</AuthorizationResult>

Device Finger Printing

Based on the bank’s response after Device Finger Printing one of the following happens:

  • Challenge Flow: The issuer requests further shopper interaction, to perform additional checks/ challenges in order to verify that the shopper is indeed the cardholder.
  • Friction-Less Flow: The issuer does not need any further interaction and proceeds with frictionless 3D Secure 2 authentication and gives the payment authorization result.

Challenge Flow

SEPG will redirect the shopper to the POS challenge URL provided in the initial PaymentRQ and this will contain the ResponseCode=BEGINCHALLENGE and an embedded HTML form for challenge. The POS will then perform the following:

  • The POS will render the embedded HTML challengeform sent by SEPG in an iframe with ChallengeWindowSize as passed in the initial PaymentRQ.
  • The shopper will be prompted to enter some details in the challenge iframe window.
  • In the background the issuer processes the challenge and post the result to SEPG.

 Based on the result one of the following could happen:

  • The issuer is satisfied with the challenge result and proceeds with the authorization. In this case SEPG will send the final redirection response to the POS return URL with the authorization outcome containing ResponseCode=APPROVED/ DECLINED/ERROR etc.
  • The issuer is not satisfied with the challenge result and will send another challenge request. SEPGwill then send another redirection response to the POS with the ResponseCode=BEGINCHALLENGE.Multiple challenge requests from issuer is possible and, in such cases, POS will go through multiple challenges.

 Sample:

<input type="hidden" name="ResponseCode" value="BEGINCHALLENGE" />
<input type="hidden" name="challengeform" value="<html>

Friction-Less Flow:

In friction-less flow, there is no challenges required by the issuer, SEPG sends the final redirection response with the authorization result to POS return URL with ResponseCode=APPROVED/DECLINED/ERROR etc. as explained in the below section.

Final Response

SEPG will send the final redirection response with the authorization result to POS with ResponseCode=APPROVED/DECLINED/ERROR etc. to the appropriate return URL.

<input type="hidden" name="ResponseCode" value="APPROVED" />

Settlement Data Delivery

Credit card authorization via Direct Links– Current Payment Authorization Process :  Settlement data formatted according to the specifications of the airline’s merchant bank and sent daily, directly to bank, processor or airline.

Credit Card authorization via PSP– New Payment Authorization Process: Current  & new customers: AM, AZ, AB, ET  - Settlement data formatted into a batch file according to the specifications of the PSP and sent daily, directly to the PSP.

Sales Reporting and Reconciliation

Airlines utilizing SabreSonic Credit Suite Settlement Data Delivery receive a daily ACCB file and LCCB file for reconciliation, accounting, and reporting purposes.  This file is sent directly to the airline.

Airline Accelerated Credit Card Billing (ACCB)

  • Daily ticketing credit card sales and refund transactions from all stations including EMDs
  • PSP Reference (If applicable)
  • Supplier ID (If applicable)
  • Transaction Type & Issue Date
  • Ticket Number, Coupons 
  • Station Number    
  • Credit Card details             
  • Passenger Name and PNR
  • Routing
  • Authorization Code
  • Airline Codes & Stopover Code 
  • Ticket Amount and Fare Basis
  • Pay Plan (Number of Installments)
  • Currency Code      
  • Merchant Number
  • ECI (if 3D Secure transaction)

Airline Local Credit Card Billing (LCCB)

  • Daily ticketing credit card sales and refund transactions from all stations including EMDs
  • Mandate ID (SEPA Direct Debit Only)
  • PSP Reference (When applicable)
  • Supplier ID (When applicable)
  • Transaction Type & Issue Date
  • Ticket Number, Coupons 
  • Station Number    
  • Credit Card details             
  • Passenger Name and PNR
  • Routing
  • Authorization Code
  • Airline Codes & Stopover Code 
  • Ticket Amount and Fare Basis
  • Currency Code
  • Merchant Number

Batch File – Sent to PSP (Adyen)

  • Merchant Account Number
  • Supplier ID
  • Ticket number
  • Mandate ID (SEPA DD )
  • PSP reference Number
  • PNR
  • Airline Leg (Itinerary)
  • Currency
  • Passenger Name
  • Credit card type

Settlement Data Delivery

Significantly improves cash flows by accelerating recovery of credit card revenue by up to 11 days.

Manual Transaction Process

Auditor coupons sorted for credit card transactions: 2-3 days

Transactions transcribed and formatted into a report: 2-3 days

Report sent via mail: 1-2 days

Transactions manually entered into processor’s accounting system: 2-3 days

Credit Suite Electronic Transaction Process

Credit card data automatically captured to Sabre transaction log: 5X per day

Transactions automatically transmitted to Sabre Settlement File: 24 hours

Settlement File electronically sent to credit card processor: 24 hours

Transactions electronically downloaded into processor’s accounting system: Immediate

Credit Card Transactions Processed by Bank: 7-11 days

Sabre Credit Suite Acquirer Banks

  • Global
    • American Express
    • DinersClub
    • Discover
    • Elavon
    • Euroline
    • JCB
    • UATP (includes PayPal)
    • Wirecard
    • North AmericaChase Paymentech
    • First Data – North
    • First Data – South
    • First Data – Omaha
    • Moneris
    • National Commercial Bank
    • TSYS
  • Australia
    • ANZ via MIGs
    • Westpac via MIGs
  • Mexico
    • Banamex (includes Auth Link)
    • Banorte (includes Auth Link)
    • PagaTodo (includes Auth Link)
    • Santander (includes Auth Link)
  • Latin America / South America
    • Aval Card Costa
    • Citibank Costa Rica
    • CobreBem
    • Consorcio CrediCard
  • Europe / Middle East / Asia
    • AlfaBank
    • Banco de Oro
    • BBVA – Madrid
    • Baiduri Bank
    • JCC
    • Kasikorn Bank
    • MultiCarta
    • Vietcom Bank

The Payment Service (PaymentRQ) API is used to perform various payment-related functions.

The Payment Service API performs the following payment-related functions:

  • Authorize payment
  • Cancel payment
  • Refund payment
  • Confirm payment

Actions for this service, grouped by section:

Confirm

  • Confirm Auth
  • Original Issuance
  • Exchange With AddCollect
  • Exchange With Residual

Cancel

  • Cancel Auth
  • Void
  • Void of Refund

Deferred Payment

  • Add DeferredPayment
  • Auth And AddDeferredPayment
  • Delete DeferredPayment
  • Query DeferredPayment

Get Payment Details

  • GetEncryptKey
  • GetStatus
  • GetDcc
  • Get Balance
  • GetMcp

Auth

  • Auth