Introduction

British Airways offers different card authentication options in the NDC APIs to protect our partners and British Airways from fraud and to be compliant with the European Payment Services Directive (PSD2)

The following authentication mechanisms are available in the 17.2  OrderCreate v4 and OrderChange v3 APIs

 Seller Initiated Authentication (3DS2)

• Benefit 1: Most efficient authentication process
• Benefit 2: Fully compliant with PSD2
• Benefit 3: Protects agent and airline from fraud - we recommend to authenticate all card transactions 

 Airline Initiated Authentication (3DS1)

• Seller must request airline to initiate card authentication
• Not 100% compliant with PSD2
• Suitable for sellers that don't have their own Payment Services Provider 
• May be decommissioned in the future 

 Offline Agents / Transactions that are excluded from authentication

• Offline agents are brick-and-mortal travel agencies that create and manage bookings on behalf of their customers. Bookings created through an offline process doesn't require authentication 

 Frequently Asked Questions

Seller Initiated Authentication (3DS2)

Pre-requisite for seller initiated authentication 

Authentication Process

Step 1

<TravelAgencySender>
><Type>Online</Type>
...
<TravelAgencySender>

Step 2

• AuthenticationMerchantName
• AuthenticationTokenValue
• AuthenticationValue
• CardNumberCollectionCode
• DirectoryServerTrxID
• ElectronicCommerceInd
• PayerAuthenticationExemptionCode
• PayerAuthenticationFailureToCompleteCode
• PaymentTrxChannelCode
• ProgrammProtocolText
• TrxStatusReasonText
• TrxStatusText

Step 3

API Flows

Prime Sale  

 Confirm Held Booking  

Airline Initiated Authentication (3DS1)

Pre-requisite for British Airways airline initiated authentication 

<TravelAgencySender>
 <Type>Online</Type>
... 
<TravelAgencySender>

<AugmentationPoint>
<BP_SP_172:SecurePayment>
<BP_SP_172:PaymentMethodCriteria>
<BP_SP_172:PaymentCardCriteria>
<BP_SP_172:CardBrandCode>VD</BP_SP_172:CardBrandCode>
<BP_SP_172:SecurePaymentAuthenticationVersion>
<BP_SP_172:SupportedVersionText>3DS1</BP_SP_172:SupportedVersionText>
</BP_SP_172:SecurePaymentAuthenticationVersion>
</BP_SP_172:PaymentCardCriteria>
<BP_SP_172:TypeCode>CC</BP_SP_172:TypeCode>
</BP_SP_172:PaymentMethodCriteria>
</BP_SP_172:SecurePayment>
</AugmentationPoint>

Authentication Process

Step 1

The seller calls OrderCreateRQ v4 (Prime Sale) or OrderChangeRQ v3 (Confirm Held Booking) with the itinerary, passenger and card details requesting British Airways initiated card authentication (3DS1). The seller must specify 3DS1 authentication and Online agent status

Step 2

• AuthenticationTrxID
• MerchantDataText
• PayerAuthenticationRequestText
• RedirectionURI

Step 3

The agent will redirect the customer to the RedirectionURI and the customer enters the data.

You should post RedirectionURI with the following query parameters:

• PayerAuthenticationRequestText  from  OrderViewRS
• TermUrl = The URL to which the PARES should be sent back (User Interface URL to where you would want to receive the PARES) Warning: For the postback, TermUrl must be able to process an HTTP POST request. It cannot receive the PARES through an HTTP GET request. 
• MD = Merchant name. This should always be “BA” – This is an optional parameter, so you don’t need to pass
• Screensubmit = should always be “true” - This is an optional parameter, so you don’t need to pass

The RedirectionURI includes the merchant/banks URL, and will be structured as follows: https://merchantacsstag.cardinalcommerce.com = RedirectionURI

You must submit these values through an HTTP Form POST to the bank service. It is advised to not use query strings in your URL i.e. '?MD=BA&Screensubmit=true'

  <form id="3DSEC" method="post" action="@Model.Payment.ACSURI">
                <div>
                    <input type="hidden" name="PaReq" value="@Model.Payment.PAREQ" />
                    <input type="hidden" name="TermUrl" value="@Model.Payment.TermUrl" />
                    <input type="hidden" name="MD" value="BA" /><br />
                    <br />
                    <br />
                    Contacting Your Bank...<br />
                    <br />
                    <br />
                    <input type="submit" value="Submit" />
                    <script type="text/javascript">
                        document.forms["3DSEC"].submit();
                    </script>"
                </div>
</form>

Step 4

• PARes (Obtained from Step 3)
• ACS_TxnReference   (This is the  AuthenticationTrxID  that has been returned in step 2 in the OrderView response )
• SPM_TxnReference  (This is MerchantDataText  that has been returned in the OrderViewRS in step 2)

Step 5

API Flow

Prime Sale

 Arline initiated authentication - Prime Sale - XML samples
 

Confirm Held Booking

 Offline Agents / Transactions that are excluded from authentication

<TravelAgencySender>
 <Type>Offline</Type>
... 
<TravelAgencySender>

 Frequently Asked Questions

 What is PSD?

The revised Payment Services Directive (PSD2) is the EU legislation which sets regulatory requirements for firms that provide payment services. An important element of PSD2 is the requirement for Strong Customer Authentication (SCA) on most electronic payments. 
 

 What is SCA?

Strong Customer Authentication is a mandatory requirement for authenticating online payments that came into effect in the European Economic Area (EEA) on 14 September, 2019, under Payment Services Directive 2. Since this all payment service providers are required to apply strong customer authentication when a customer accesses their payment account online or makes an electronic payment unless one of the permitted exemptions applies. 

It requires payments to be authenticated using at least two of the following three elements:  

• Something that only the customer knows 

• Something that only the customer has or possesses 

• Something that the customer is

Unauthenticated payments that require Strong Customer Authentication risk being declined by the customer’s bank. Merchants will be liable if it sends the transactions directly to authorisation without EMV 3DS authentication check. Where merchants request authentication from the issuer, liability shifts to the issuer. Where merchants send transactions straight to authorisation, liability remains with the merchant.  

More information can be found here  https://www.fca.org.uk/firms/revised-payment-services-directive-psd2   

To receive the latest PSD2 updates from the UK FCA by email please sign up here  https://www.fca.org.uk/psd2-email-updates   

What is the scope of PSD2 EU Directive?

An issuer needs to determine PSD2 RTS geographical scope based on the acquirer's location. Even when a merchant is located outside of EEA, an acquirer in EEA will require the issuer to apply SCA. Most transactions in British Airways NDC will be subject to SCA. SCA regulation will be enforced in the UK, regardless of the outcome of Brexit. 

Please get in touch with your card scheme provider to discuss your individual requirements and specific queries about the scope of PSD2 for your business.  

 What is considered to be out of scope for PSD2/SCA?

• Anonymous prepaid cards
• Mail Order/Telephone Order (MOTO)
• One leg out transactions (where one of issuer/acquirer sits outside of the EEA)
• MOTO transactions  

MOTO transactions are out of PSD2 RTS scope and do not require SCA. MOTO are reservations that have been made through mail or telephone order for which no authentication is required. Such NDC transactions need to be flagged as “offline” in the API calls. 

Secure Corporate Payments   

Please see below question about lodged and virtual corporate cards.  Payments made from a ‘Secure Corporate Environment’ will not be automatically exempt from SCA as the exemption is not due to the card type, rather the additional security the environment provides. As such, an exemption flag would need to be provided for these transactions and accepted by the issuer/acquirer in order to utilise the exemption.

More information about the scope and exclusions of PSD2 is defined by Financial Conduct Authority (FCA) UK here  https://www.fca.org.uk/firms/scope-exclusions-changes-under-psd2    

What about Lodged cards and virtual cards? Are they out of scope for SCA?

According to FCA (UK) this exemption may cover payments that are made with “lodge cards” (e.g. when a corporate card used for managing employee travel expenses is held directly with a travel agency). FCA (UK) does not distinguish between ‘physical’ and ‘virtual’ lodged cards hence physical lodged corporate cards should benefit from the exemption.   

Mastercard’s position on the use of virtual cards is that: 

“Where merchants* request authentication, issuers should respond to the authentication requests with silent/passive authentication (no cardholder challenge) based on the product being exempt. However, some issuers may not provide an authentication response for exempt products. “ 

In addition, this exemption may cover corporate payments made using virtual corporate cards or VCNs (e.g. used within access-controlled corporate travel management or corporate purchasing system). 

A large proportion of the transactions expected to fall under the Secure Corporate Payment exemption are currently processed as MOTO e.g. in the travel space.

What about Physical Corporate Cards issued to employees?

Corporate cards issued in an individual’s name are subject to SCA and therefore may require the cardholder to authenticate themselves. ‘True’ corporate cards issued in the name of a corporate which are not subject to SCA will be determined by the issuing bank and any authentication requests will be handled accordingly (no cardholder challenge).
 

Will all payment require SCA?

Strong Customer Authentication will apply to customer-initiated online payments within the European Economic Area (EEA). Transactions in scope are those involving a customer’s card that has been issued in the EEA and where the transaction is acquired in the EEA. Most transactions in NDC will be processed within the EEA, therefore, will be subject to 3D Secure authentication. 
 

What is 3D Secure?

3D Secure is the authentication protocol used for authenticating online card payments.   
 

What are the differences between 3D Secure 1.0 and 2.0+??

3D Secure V2 (the new version of the 3D Secure authentication standard) will be the main method for authenticating card payments and meeting Strong Customer Authentication requirements. This new version introduces a better user experience that will help minimise some of the friction that authentication adds into the booking flow. 

 Source: Mastercard Academy Webinar, 20 June 2019 
 

What is the difference between an airline-initiated vs seller-initiated authentication?

In NDC indirect distribution we differentiate between two flows to authenticate a payment transaction.   

Airline initiated authentication is when a transaction is authenticated using the airline Payment Service Provider (PSP)’s technology. 

Seller initiated authentication is when  a transaction is authenticated by the seller (an agency) itself using their own  Payment Service Provider (PSP). 

Card scheme providers recommend that the seller-initiated authentication approach as the most suitable model for airline indirect distribution channels.  

How do I know a particular transaction will be prompted to be authenticated using airline initiated authentication in NDC?  

If the transactions originate from an “offline” seller, they will follow the current booking flow and only current BA authentication checks will be in place.   

If the transactions originate from an “online” seller, they will be prompted for 3DS authentication challenge. It is up to the bank to determine if the card is 3D Secure-enabled and decide the subsequent authentication flow.  

If neither online or offline are specified, then online will be the assumed default
 

Which NDC schema versions support 3DS authentication?  

We will only support 3D Secure in our 17.2. and higher NDC API schema. 

Will there be a new version of your individual APIs enabling 3DS?  

We advise you to implement the latest versions of the OrderCreate API which is version 4 and the OrderChange API, version 3. The versions have all British Airways capability. We are planning to de-commision the earlier version in the near term future
 

What is going to happen with 16.1 and earlier versions of BA NDC APIs?  

We advise that you switch to the latest schemas as 3DS will only be available in British Airways NDC APIs schema version 17.2. All 16.1 APIs will be de-commissioned in H1 2021. 
 

What happens if my Service Provider has not updated to British Airways NDC API schema version 17.2?  

It will not be possible to make card payments. We advise getting in touch with your Service Provider to discuss this further.  
 

Where can I find more information?  

• Mastercard Academy: “Corporate & Travel Segment - Authentication Guidelines”, 20th June 2019  https://mastercardeacademy.adobeconnect.com/piyvjk1805ub/   
• Mastercard Academy – Great source of information, webinars  www.mastercardacademy.com   
• Financial Conduct Authority FCA UK – PSD2  https://www.fca.org.uk/firms/revised-payment-services-directive-psd2   

I am an Online agent with my own PSP. Can I send a request without providing authentication details but seller type online?

It is up to the bank to decide whether to accept or reject the transaction. If accepted, booking will be created and tickets will be issued. If rejected, an unique error message will be returned advising the agent to complete 3DS2 authentication and call OrderCreateRQ  or OrderChangeRQ again. XML samples are available for this scenario
 

How can I test seller initiated authentication in NDC?

We have a designated Test Page which provides all details needed to test effectively.