What's the difference between 3D Secure 1, 2.1 and 2.2?

It’s hard to believe it’s been over a year since the original deadline for Strong Customer Authentication (SCA). To refresh your memory, Europe’s Second Payment Services Directive (PSD2) requires SCA on most payments - read more about the regulation here. 3D Secure is a method for 2-factor authentication, recognised as SCA compliant by the European Banking Authority (EBA). We’re now finally past the EBA’s amended SCA enforcement deadline of 31 December 2020.

Overall, 2020 was been challenging for merchants, with the global pandemic adding stress to online operations. After the difficulties of the past year, authentication may have taken a backseat among changing priorities - but now it’s time to pay attention. How can you ensure you have the best chance minimizing unnecessary friction and converting customers?

There are major differences between 3DS versions 1 and 2, and some minor differences between 2.1 and 2.2. Here’s a quick reminder of the features that each version can support…

3D Secure 1

The original version, 3DS1 can support SCA compliance for PSD2. It can also provide merchant fraud liability protection, but only until October 2021 for Visa Secure - 3DS1.

Although it’s compliant, it’s unpopular with consumers, and this causes big issues for merchants. 3DS1 comes from a time before mobile phones, so the user experience is varied at best, and frustratingly terrible at its worst. It often relies on a pop-up window where the customer must enter their details, which can make the merchant checkout page look even less secure, and can be vulnerable to cyber-criminal attack.

3DS1 also doesn’t recognise soft-declines. An issuer can use a soft-decline if they receive a request from a merchant to authorize a payment, but they want to use authentication first. With 3DS1, the issuer would have to just decline the payment and the merchant would be forced to try again and risk the customer abandoning checkout.

Given its age and limitations, it’s no surprise it’s coming to the end of its life soon. From October 2021 3DS will start to be decommissioned by card schemes, starting with Mastercard. Even if it’s still available, merchants will lose the liability shift advantage with 3DS1, so it’s important to move forward with the newer versions as soon as possible.

3D Secure 2

Like 3DS1, both 3DS 2.1 and 3DS 2.2 tick the boxes for SCA compliance and merchant fraud liability protection. Where 3DS2 is different, it can enable better customer experience through less friction.

How does this work? With 3DS2, merchants have the ability to send far more data to the issuing bank than with 3DS1. Rather than only relying on static passwords, 3DS2 enables the use of dynamic authentication through biometrics and token-based authentication methods. With the extra data, issuers can apply frictionless authentication to approve a transaction without requiring any manual input from the cardholder - this is called Frictionless Flow. This risk-based authentication will be key to keeping the checkout processes friction-free for the majority of low-risk transactions from trusted customers.

3DS2 can also recognise soft declines, which 3DS1 didn’t support. For example, if the issuer receives an authorization request on a transaction, but wants authentication to take place beforehand, 3DS2 can enable this. This means there is less chance of the transaction being declined altogether by the issuer, and less risk of the transaction being abandoned by the customer.

Unlike 3DS1, 3DS2 can be used to set up merchant-initiated transactions. This is useful for a merchant which needs to set up recurring payments from a customer eg. for a subscription. The first payment requires SCA, but subsequent identical payments will not. A merchant can use 3DS2 to authenticate the first payment, and set up the following payments as merchant-initiated transactions.

Differences between 3D Secure 2.1 and 2.2

One key difference between 3DS 2.1 and 2.2 is the ability to support exemptions.

Both versions support issuer exemptions through risk-based authentication, eg. the Frictionless Flow mentioned above.

3DS 2.2 also allows merchants to request exemptions through their acquirer. This includes the merchant or payment service provider can apply Transaction Risk Analysis (TRA) and use this data to request for a low-risk exemption. It also allows merchants to request an exemption as a Trusted merchant.

There are some variations between the schemes which are important to keep in mind. Mastercard have also announced that they will enable the low-risk exemption based on TRA. This isn’t possible with Visa on 2.1, however, Visa will allow for the secure corporate transaction exemption on 2.1.

3DS 2.2 also supports delegated authentication and decoupled authentication.

Delegated authentication

Typically, authentication is performed by the issuing bank. Delegated authentication means that issuers can allow for a third-party to do the authentication. This could be a merchant, an acquirer or a digital wallet provider.

So how does this work? An example could be if a merchant has the ability to perform SCA at login through using FIDO authentication. This information can be passed on to the issuer so that they can confirm the customer’s identity, and there’s no need to authenticate. This would involve a lot less friction and deliver a better experience for the customer, and allows the merchant more control over how SCA is performed. You can read up on the delegated authentication requirements for Visa here (page 530).

Decoupled authentication

Though the name is similar, this is not to be confused with delegated authentication.

Decoupled Authentication is when a user conducts authentication through a methodology that is separate from the main authentication flow. This can take place even if the cardholder is offline. An example use case could be if a customer completes SCA on their smartphone, to allow for authorization on another device, eg. a desktop computer.

What happens if 3DS is attempted, but the issuer is not enrolled in the version requested?

So, let’s imagine a customer makes a payment and you request 3DS 2.2, but the customer’s issuer is only enrolled in version 2.1. In this case, 2.1 will be used instead. If the issuer is not enrolled in version 2, then 3DS1 will be used.

If the issuer is not enrolled in 3DS at all, then the card scheme Attempts Server will stand in on behalf of the issuer.

For details on where SCA will be enforced from January 1st 2021, check out the current updates on dates and deadlines in our global map. It’s important to note that the deadline is not the same across the whole European Economic Area, and some countries are implementing a phased approach throughout 2021, such as France and the UK.

Ravelin Accept's 3DS2 Server is certified for 3DS2 - find out more about this here.