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
<TravelAgencySender>
><Type>Online</Type>
...
<TravelAgencySender>
<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>
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
The agent will redirect the customer to the RedirectionURI and the customer enters the data.
You should post RedirectionURI with the following query parameters:
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>
Arline initiated authentication - Prime Sale - XML samples
<TravelAgencySender>
<Type>Offline</Type>
...
<TravelAgencySender>
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.
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
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.
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
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.
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).
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.
3D Secure is the authentication protocol used for authenticating online card payments.
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
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.
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
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
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.
It will not be possible to make card payments. We advise getting in touch with your Service Provider to discuss this further.
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
We have a designated Test Page which provides all details needed to test effectively.