3-D Secure Authentication Flow

What Is the 3-D Secure Authentication Flow?

The 3-D Secure authentication flow is the message exchange sequence that verifies a cardholder's identity during an online payment. Originally developed by Visa under the name "Verified by Visa" and now governed by EMVCo, the protocol adds an authentication layer between the payment gateway authorization and the final capture. Mastercard brands it as "Identity Check," and American Express calls it "SafeKey."

The "3-D" in the name refers to three domains that participate in the protocol: the acquirer domain (the merchant and its acquiring bank), the issuer domain (the cardholder and their issuing bank), and the interoperability domain (the card network infrastructure that connects them). Understanding this flow is essential for any merchant accepting card-not-present payments, because it directly affects fraud liability, checkout conversion rates, and compliance with regulations like Strong Customer Authentication.

How It Works

The 3DS2 authentication flow involves three server-side components communicating through structured messages. Each component sits in one of the three domains:

• 3DS Server: operated by or on behalf of the merchant, it collects transaction and device data, then initiates the authentication request
• Directory Server (DS): operated by the card network (Visa, Mastercard, etc.), it routes authentication messages to the correct issuer and maintains card range data
• Access Control Server (ACS): operated by or on behalf of the issuing bank, it evaluates risk and decides whether to authenticate frictionlessly or challenge the cardholder

The Frictionless Flow

In the frictionless path, the cardholder never sees an authentication prompt. The issuer approves based solely on the data provided:

1. The cardholder enters their card details at checkout. The merchant's 3DS Server collects device data, browser fingerprint, IP address, and transaction context: over 100 data elements in total.
2. The 3DS Server sends an Authentication Request (AReq) to the card network's Directory Server.
3. The Directory Server identifies the issuing bank from the card range and forwards the AReq to the issuer's ACS.
4. The ACS runs the transaction through its risk engine. For low-risk transactions (recognized device, normal spending pattern, low amount), it returns an Authentication Response (ARes) with a "frictionless" status and a cryptographic authentication value (CAVV).
5. The 3DS Server passes the CAVV and Electronic Commerce Indicator (ECI) to the payment processor, which includes them in the authorization request sent to the issuer.

The entire exchange happens in the background while the cardholder waits at checkout, typically completing in under two seconds.

The Challenge Flow

When the ACS determines a transaction is higher risk, it triggers a challenge that requires cardholder interaction:

1. Steps 1 through 3 proceed identically to the frictionless flow.
2. The ACS returns an ARes indicating a challenge is required, along with a transaction ID for the challenge session.
3. The merchant's 3DS SDK renders the challenge interface: either a browser iframe or a native mobile component. In 3DS2, this appears inline rather than as a full-page redirect.
4. The cardholder completes the challenge: typically a one-time password sent via SMS or push notification, an in-app biometric confirmation, or a response to a security question. The challenge exchanges happen directly between the cardholder's device and the ACS through Challenge Request (CReq) and Challenge Response (CRes) messages.
5. Upon successful verification, the ACS sends a Results Request (RReq) to the Directory Server, which forwards it to the 3DS Server. The 3DS Server now has the CAVV and can proceed with authorization.

Message Flow Diagram

The following pseudocode illustrates the decision points in the authentication flow:

Cardholder -> Merchant:       card details + checkout
Merchant   -> 3DS Server:     initiate authentication
3DS Server -> Directory Server: AReq (100+ data fields)
Directory Server -> ACS:       AReq (routed by card range)

ACS risk engine evaluates:
  if low_risk:
    ACS -> Directory Server -> 3DS Server: ARes (frictionless, CAVV)
  else:
    ACS -> Directory Server -> 3DS Server: ARes (challenge required)
    Cardholder <-> ACS:  CReq / CRes (OTP, biometric, etc.)
    ACS -> Directory Server -> 3DS Server: RReq (final result, CAVV)

3DS Server -> Payment Processor: authorize with ECI + CAVV

3DS1 vs 3DS2

The original 3-D Secure protocol (version 1) relied on full-page browser redirects. When authentication was required, the merchant's gateway returned a URL pointing to the issuer's ACS. The cardholder's browser was redirected there, they completed authentication, and the browser redirected back. This approach had several problems:

• Every transaction was challenged: 3DS1 lacked a frictionless path, meaning every enrolled cardholder saw an authentication prompt regardless of risk level
• Mobile breakage: full-page redirects disrupted native app checkout flows and often broke on mobile browsers, driving cart abandonment
• Limited data: merchants sent minimal context to the issuer, reducing the accuracy of fraud assessments
• Poor UX: the redirect to an unfamiliar bank page confused cardholders and eroded trust in the merchant's checkout

3DS2 (EMV 3-D Secure) addressed each of these with risk-based authentication (the frictionless flow), native mobile SDKs that render challenge UI inline, and a dramatically richer data model. The result is higher authentication rates with lower checkout friction.

ECI Values and Liability Shift

The Electronic Commerce Indicator (ECI) is a value returned after 3-D Secure authentication that tells the card network and issuer what level of authentication was achieved. The ECI determines whether the liability shift applies. For Visa, the key values are:

Mastercard uses different values (02 for fully authenticated, 01 for attempted, 00 for not authenticated). ECI meanings are network-specific, so a value from one network should not be interpreted using another network's definitions.

The liability shift is the primary commercial incentive for merchants to implement 3-D Secure. When a transaction is successfully authenticated, fraud-related chargebacks become the issuer's responsibility rather than the merchant's. This shift applies to both frictionless and challenged transactions that complete authentication. However, the shift typically covers only unauthorized-transaction disputes: non-fraud disputes such as "goods not received" remain with the merchant.

There are exceptions. Merchants enrolled in network fraud monitoring programs due to high dispute rates may lose liability shift protection. Additionally, when a merchant requests an SCA exemption and the transaction goes frictionless without full authentication, the liability shift generally does not apply.

Use Cases

E-Commerce Checkout

The most common use case: every time a consumer enters card details on a website or mobile app, the merchant triggers 3-D Secure authentication. For low-risk transactions (returning customer, recognized device, moderate amount), the frictionless flow authenticates invisibly. Higher-risk transactions prompt a challenge. Merchants benefit from reduced fraud liability while maintaining conversion rates through the frictionless path.

Regulatory Compliance

In the European Economic Area and the UK, Strong Customer Authentication under PSD2 mandates two-factor authentication for most electronic payments. 3-D Secure 2 is the primary mechanism card networks use to satisfy this requirement. Merchants that fail to apply SCA face declined transactions from issuers enforcing the regulation.

Recurring and Card-on-File Payments

For recurring billing and card-on-file transactions, 3DS2 version 2.2 introduced specific transaction types. The initial payment authenticates with a full 3-D Secure flow, and subsequent charges reference the original authentication. This satisfies SCA requirements while avoiding repeated challenges for subscription payments.

High-Value and High-Risk Transactions

Merchants selling high-value goods, digital products prone to fraud, or services in high-risk categories often see the greatest benefit from 3-D Secure. The liability shift protects against costly chargebacks, and the authentication data helps issuers make more accurate approval decisions: reducing both false declines and actual fraud.

Why It Matters for Payments

The 3-D Secure authentication flow sits at the intersection of security, regulation, and checkout experience. For traditional card-not-present payments, it is the primary mechanism for reducing fraud liability and satisfying authentication mandates.

However, even with 3DS2's frictionless improvements, the protocol adds latency and complexity to checkout. Each authentication involves multiple network round-trips between the 3DS Server, Directory Server, and ACS. Challenge flows introduce user friction that can reduce conversion. This overhead is one reason alternative payment methods continue to gain ground: account-to-account payments, stablecoin rails, and cryptocurrency transactions settle using cryptographic proof rather than multi-party authentication ceremonies. For a deeper look at how newer payment rails compare, see how stablecoins reduce payment fraud and checkout conversion with crypto payments.

Risks and Considerations

Checkout Abandonment

Challenge flows interrupt the payment experience. When a cardholder is prompted for an OTP or biometric verification, some percentage will abandon checkout: either because they don't have their phone handy, the SMS is delayed, or they don't trust the authentication prompt. Merchants must balance fraud protection against conversion loss.

Issuer ACS Availability

The authentication flow depends on the issuer's ACS being online and responsive. If the ACS is down, authentication attempts may time out or fall through to a "stand-in" mode where the Directory Server handles the response. Stand-in transactions may or may not receive liability shift depending on the card network's rules.

Implementation Complexity

Integrating 3-D Secure requires handling multiple response states (frictionless approval, challenge required, authentication failed, issuer unavailable), rendering challenge UIs across browsers and native apps, managing timeouts, and passing authentication data correctly through to authorization. Most merchants rely on their payment gateway or processor to abstract this complexity.

Evolving Network Rules

Card networks periodically update their liability shift rules. For example, Mastercard introduced pilot programs in 2026 that can convert non-listed merchants to data-share-only transactions without challenge or liability shift. Merchants must stay current with network mandates or risk losing the protections they expect from authentication.

False Sense of Security

3-D Secure authenticates the cardholder but does not verify the merchant, the goods, or the delivery. Non-fraud disputes (item not received, item not as described) are unaffected by the liability shift. Merchants still need robust fraud scoring, dispute resolution, and fulfillment processes.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.