Blog / 3DS & SCA

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

 Strong Customer Authentication is required in more and more countries around the world. Here’s a quick explanation of the key differences between the 3D Secure versions.

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). Europe’s Second Payment Services Directive (PSD2) requires SCA on most payments. 3D Secure is a method for 2-factor authentication recognized as SCA compliant by the European Banking Authority (EBA).

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 started to be decommissioned by card schemes, starting with Mastercard. Even when still available, merchants lost the liability shift advantage with 3DS1.

It's always 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. What does 3DS2 do differently? 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 is key to keeping the checkout processes friction-free for the majority of low-risk transactions from trusted customers.

3DS2 can also recognize 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 – e.g. 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.

SCA map
Explore Ravelin's SCA mandates map to see where Secure Customer Authentication is required around the world.

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, e.g. 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 has also announced that it has enabled 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, e.g. a desktop computer.

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

The version that is supported by the issuer will be used instead, even if earlier.

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.

SCA around the world

It's not just on the Old Continent – countries from around the world are adopting SCA, including many in Asia. Browse the SCA Mandates section of our global interactive map to find out where merchants have to follow SCA for online payments.

Ravelin's 3DS product is certified for 3DS2.

Ravelin Logo

Ravelin is prepared for 3DS v2.3

We continue to be proactive in our support of 3DS. See the advantages of Ravelin's 3DS products.

Author