As eCommerce grows, more and more payments that once happened in cash now happen digitally, both online and in stores. The history of online payments can be traced back to 1994, when the Stanford Federal Credit Union offered its members online banking. The rapid growth of online shopping, online banking, and other services, coupled with technological advancements, has led to a spike in digital payments. According to Statista, digital payments worldwide are projected to reach $37.45 trillion in transaction value in 2026.
With the rise of online transactions comes growth in online payment fraud. According to Juniper Research, the value of eCommerce fraud was estimated at around $44 billion in 2024 and is projected to rise to $107 billion in 2029. To reduce the risk of loss, fraud, and identity theft, payment systems are introducing new authentication technologies. 3D Secure (3DS) is the card industry’s standard for this. Below, we explain how 3DS works, what changed with 3DS2 and how it affects approvals and checkout drop-off.
What is the 3D Secure Protocol and how does it work?
3DS is an authentication protocol for online card payments: before a payment is authorized, the cardholder’s bank checks that the person paying is the real cardholder. For example, a user needs to make a payment on an eCommerce platform. The user enters their data and CVV code and then needs to enter the code sent to their phone number on a pop-up page. This is confirmation that the user behind the screen is the real owner of the card since the given telephone number is associated with the card.
The name “3D Secure” has nothing to do with augmented reality. It stands for three domains: the acquiring domain (an eCommerce platform), the issuing domain (the banks), and the interoperability domain. Card schemes run 3DS under their own names: Visa Secure (formerly Verified by Visa), Mastercard Identity Check and American Express SafeKey.
The original 3D Secure 1.0 message flow across the three domains.
- Issuing domain refers to banks where users can issue their cards and then use them for buying different products or services. Within the 3DS protocol, the issuing bank has to deploy an Access Control Server (ACS) to process 3D Secure messages and authenticate a user.
- Interoperability domain is the mediating layer between the issuing and acquiring domains. The domain allows for exchanges of information between parties via the Directory server and supports the 3DS process. The Directory Server receives messages from the MPI and verifies the card number against the BIN range directory before sending the message to the correct issuing bank. The issuing bank then takes its part and authenticates the user.
- Acquiring domain refers to the payment gateway, the merchant, and acquiring banks. It initiates the transaction that needs to be verified. An MPI (a merchant plug-in) needs to be deployed.
In 3DS2, the 3DS Server takes over the merchant plug-in role, and a 3DS SDK supports authentication inside mobile apps. The industry still often calls this component an MPI, and it can run in-house or as an external MPI.
3DS was first introduced in 2001, but it implied that every customer should go through the authentication process and get forwarded to a security pop-up page. Since customers needed to complete many steps every time they shopped online, the rate of cart abandonments began to rise. 3DS2 replaced it, and Visa retired 3D Secure 1.0 on October 15, 2022; most other major card schemes switched it off the same month.
3D Secure 2.0 (3DS2)
3D Secure 2 (3DS2), also written 3DS 2.0 and formally called EMV 3DS, is the current version of the 3D Secure protocol. EMVCo published it in 2016 to replace 3DS1. 3DS2 gives the issuer far more data about each payment, so low-risk payments can pass without a challenge. The protocol is also the main way online card payments meet the strong customer authentication rules under PSD2.
3DS2 doesn’t rely on static passwords. It allows for dynamic authentication via one-time codes, banking-app confirmation or biometrics, and it also works with tokenized cards. In many cases, there is no need for manual data input. The protocol is fully integrated into the merchant’s checkout experience and creates a smoother payment flow for shoppers. In the frictionless flow, all the authentication activities happen in the background. This lowers drop-off at checkout.
Card schemes ended support for EMV 3DS 2.1 in September 2024. As of 2026, 2.2 is the minimum version, and schemes are adding support for 2.3.1.
A typical 3DS2 authentication runs in six steps:
- Data collection. At checkout, the merchant gathers transaction details along with browser or device data. In mobile apps, a 3DS SDK collects the device data.
- Authentication request. The merchant’s 3DS Server sends an Authentication Request (AReq) to the card scheme’s Directory Server, which passes it to the issuer’s Access Control Server (ACS).
- Risk assessment. The ACS scores the payment and replies with an Authentication Response (ARes) through the Directory Server. The response says whether the payment is authenticated, needs a challenge, or is rejected.
- Frictionless flow. If the issuer rates the payment as low-risk, the ARes already carries the result, and the customer does nothing. In the EEA and the UK, this needs an SCA exemption unless the payment is outside SCA’s scope, for example, when the card was issued outside the region.
- Challenge flow. Otherwise, the ACS challenges the customer through Challenge Request and Response messages (CReq/CRes). The customer confirms in a banking app, enters a one-time code, or uses biometrics. The ACS then sends the outcome through the Directory Server to the 3DS Server in a Results Request (RReq), and the 3DS Server confirms receipt with a Results Response (RRes).
- Authorization. The merchant sends the authorization request through its acquirer with the authentication data attached (the ECI value and the authentication value, called CAVV at Visa and AAV at Mastercard), and the issuer approves or declines the payment.
The table below shows how 3DS2 differs from 3DS1.
| Aspect compared | 3DS1 | 3DS2 |
|---|---|---|
| How the customer is authenticated | A static password or one-time code on a separate page, for almost every payment | Risk-based. Low-risk payments can pass without customer action, in the EEA and the UK only under an SCA exemption. The rest get a challenge in a banking app, by one-time code or with biometrics |
| Data shared with the issuer | A small set of card and transaction details | Much richer data, including device, browser and transaction details |
| Checkout experience | A pop-up or redirect at most payments, which raised cart abandonment | A challenge only when the issuer asks for one, shown within the checkout |
| Mobile and in-app support | Built for desktop browsers, with no native in-app flow | Native in-app authentication through a 3DS SDK |
| Messages used | VEReq/VERes and PAReq/PARes | AReq/ARes, CReq/CRes and RReq/RRes |
| Status today | Retired by Visa on October 15, 2022, and by most other major schemes the same month | Version 2.2 is the minimum, and schemes are adding support for 2.3.1 |
Why implement 3D Secure 2.0 authentication?
3DS 2.0 is a better version of 3DS 1.0 as it provides consistent payment experiences to consumers regardless of the devices they are using. Merchants can benefit greatly from the changes brought about by 3D Secure 2 to drive their sales. Here are the main 3DS2 benefits for online merchants.
More approvals
Issuers get far more data about each payment. That helps them approve more legitimate transactions and decline fewer by mistake.
Lower drop-off rates
3D Secure 2 lets many low-risk payments go through without a challenge. When a challenge is needed, it appears inside the checkout or the banking app, not on a separate page. So fewer customers abandon their carts. When Visa announced 3DS2 support in May 2017, it cited studies suggesting cart abandonment could fall by as much as 70%. This matters in the EEA, where the EBA set December 31, 2020 as the deadline for SCA in e-commerce card payments. It matters for merchants selling in the UK too, where the FCA has expected full SCA compliance for e-commerce since March 14, 2022.
But before you can reap the benefits of 3DS2, you need to integrate it into your payment system. From a technical point of view, there could be some challenges. That’s why we recommend using a white-label payment gateway platform like Akurateco, which provides the infrastructure and functionality needed to deliver a smooth and secure payment experience.
Fraud liability shift
When a payment is authenticated through 3D Secure, liability for fraud-related chargebacks generally moves from the merchant to the card issuer. The exact rules depend on the card scheme and the region. The shift usually does not apply when the merchant or its acquirer requests an SCA exemption and the payment goes through without a challenge.
How Akurateco supports 3DS 2.0 authentication
Akurateco supports 3DS2 through three models, and it isn’t tied to one protocol version. It processes whichever version the connector supports. In the main model, 3DS runs on the acquirer’s side. The acquirer owns the 3DS Server, and the platform handles the redirect, browser data collection and the challenge. PSPs can also use an external MPI managed by Akurateco. Merchants with their own MPI can send the result (ECI, CAVV and DS Transaction ID) through the API. App-based authentication works too, with the merchant getting instructions through the API or SDK.
This also illustrates how a white-label gateway works in practice. The platform handles authentication logic and transaction routing in the background, while PSPs and merchants keep control of the customer-facing experience.
There is no automatic switch to a non-3DS flow, because not every MID accepts payments both with and without 3DS. If authentication succeeds but the authorization gets a soft decline, the platform cascades the payment to another MID. The 3DS result is reused, so no new authentication is needed.
In one of our cases, an external MPI made cascading simpler. The payer needed to authenticate only once and was not asked again when the payment moved to another provider. After that, cascading was fully frictionless for them. So the payment had a better chance of succeeding with another provider than when the payer had to enter a one-time code three times or more.
The external MPI also lets the platform ask for a specific type of 3DS, though not a specific version. The options are Not Enrolled, Frictionless, Challenge Needed and No Liability Shift. If the platform asks for Frictionless but the issuer won’t process the payment that way, the MPI falls back to Challenge automatically.
Summing up
The banking world is developing and offering more and more new products that are transforming the online payment ecosystem. No one can deny that the 3DS system is a sophisticated payment authentication solution that has the potential to greatly improve transaction security and the user journey. These factors are important for customers and for keeping conversion rates high for merchants. So implementing the 3DS 2.0 authentication protocol is a win-win for both parties.
FAQ
What is 3D Secure (3DS)?
3D Secure is a security protocol that adds an extra layer of authentication to online card payments, for example, confirming a one-time code sent to the cardholder’s phone, to verify that the person paying is the genuine cardholder.
What does the “3D” in 3D Secure stand for?
It refers to three domains, not augmented reality: the acquiring domain (the merchant and acquiring bank), the issuing domain (the cardholder’s bank), and the interoperability domain that mediates between them.
What is 3DS2?
3DS2, also called 3DS 2.0 or EMV 3DS, is the current version of the 3D Secure protocol, published by EMVCo in 2016. It sends the issuer far more data about each payment. Low-risk payments can pass without a challenge, in the EEA and the UK only under an SCA exemption. The rest are confirmed in a banking app, with a one-time code or biometrics. 3DS2 also works inside mobile apps.
What is the difference between 3DS1 and 3DS2?
3DS 1.0 required customers to complete authentication on a redirect pop-up, which raised cart abandonment. 3DS 2.0 shares much more data with the issuer, so low-risk payments can pass in a frictionless flow, and the rest get a challenge via a banking app, one-time code, or biometrics. Visa retired 3DS 1.0 on October 15, 2022, and most other major card schemes switched it off the same month.
Why should merchants implement 3D Secure 2.0?
3DS 2.0 gives issuers access to more data points, so they can approve more legitimate transactions and reduce false declines, while its frictionless flow lowers drop-off rates. When Visa announced 3DS2 support in 2017, it said studies showed cart abandonment could fall by as much as 70%.
Is 3DS 1.0 still supported?
No, not for the major card schemes. Visa retired 3DS 1.0 on October 15, 2022, and most other major schemes switched it off the same month. Support for EMV 3DS 2.1 ended in September 2024, so 2.2 is now the minimum. Akurateco isn’t tied to one 3DS version. It processes whichever version each connector supports and collects the data that version requires.
