3DS Frequently Asked Questions
1. 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.
2. 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
3. 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.
4. 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 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
4. 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.
6. 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).
7. 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.
8. Wwhat is 3D Secure?
3D Secure is the authentication protocol used for authenticating online card payments.
9. 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
10. 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.
Firstly, a transaction can be authenticated using the airline Payment Service Provider (PSP)’s technology. British Airways already supports 3D Secure version 1 using the “airline-initiated authentication” model.
Secondly, a transaction can also be authenticated by the seller (an agency) itself using their own PSP. British Airways is implementing this and will be able to support the newest functionality of 3D Secure version 2.
Card scheme providers tend to agree that the seller-initiated authentication approach as the most suitable model for airline indirect distribution channels.
11. How is British Airways NDC implementing 3DS?
We have implemented 3D Secure 1 into our 17.2 NDC APIs (OrderCreate and OrderChange) to support all booking flows scenarios, and are working on implementation for 3D Secure 2. Please be advised 3D Secure authentication will only be available on 17.2 NDC APIs.
For airline-initiated authentication (supporting V1 only), the flow is:
A Seller calls OrderCreate/ OrderChange NDC API with payment details and specifies a 3D Secure 1.0 authentication
An Airline sends an error message asking to complete 3DS first
A Seller redirects the customer to complete authentication
A Seller passes customer completed authentication details to us via OrderCreate/ OrderChange NDC API
An Airline authorises payment and issues a ticket
For seller-initiated authentication (supporting V1 & V2) the flow is:
A Seller calls OrderCreate/ OrderChange NDC API with payment details and completed authenticated detials
An Airline authorises payment and issues a ticket
12. Are you implementing 3D Secure 2.0 (known as EMVCo 3D Secure v2.0)?
We will be releasing new versions of our 17.2 OrderCreate and OrderChange to enable 3D Secure 2 in the seller-initiated authentication flow.
13. How do I know a particular transaction will be prompted to be 3DS-authenticated 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.
14. Which NDC schema versions support 3DS authentication?
We will only support 3D Secure in our 17.2. and higher NDC API schema.
15. Will there be a new version of your individual APIs enabling 3DS?
We are deploying new versions of our 17.2 APIs. Please be advised that end-points need to be changed - even for “offline” sellers. The APIs will be released as Version 2. You will see that the only difference in the end-points is the /V4 as opposed to /V2.
16. 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. For 16.1 (and earlier versions) customers, since 14 September, 2019, British Airways no longer accepts card payments.
17. How do I integrate 3D Secure into our front-end?
British Airways provides all technical documentation on its NDC Helpdesk, including XML examples and test samples as well as integration guidance. Please click here to access it.
For testing purposes and UAT in your development, you may find useful this documentation provided by CyberSource. The documentation accessible here features various test cases of 3D Secure 1.0 scenarios, including negative scenarios.
We have also integrated 3D Secure V1 functionality into our testing NDC Booking Tool front end.
18. 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.
19. Where can I find more information?