Category: 3-D Secure

EMV 3-D Secure

Also known as: EMV 3DS, 3DS2, 3-D Secure 2, EMV 3D Secure 2, Visa Secure (as a card brand implementation)

Simply put

EMV 3-D Secure is a messaging protocol that lets an online merchant and the card issuer exchange information to help confirm that a shopper is the legitimate cardholder during a card-not-present purchase, such as an e-commerce checkout. It is intended to help reduce card-not-present fraud and add security to online payments, and it is often branded by card networks under names such as Visa Secure. It is designed to improve on the earlier 3-D Secure 1 protocol by supporting a smoother checkout experience.

Formal definition

EMV 3-D Secure is a card-not-present authentication protocol maintained by EMVCo that enables the exchange of transaction, device, and cardholder data among the three domains (merchant/acquirer, issuer, and interoperability) to support risk-based and, where needed, challenge-based authentication of e-commerce and app-based transactions. The specification (for example, 3-D Secure Specification v2.2.0) defines the messaging framework, while related components such as the 3DS SDK are governed by separate EMVCo and PCI standards; notably, the PCI 3DS SDK Security Standard applies to entities developing 3DS SDKs as defined in the EMV 3-D Secure 3DS SDK Specification. EMV 3DS addresses cardholder authentication at the transaction-initiation stage and is distinct from PCI DSS scope controls, EMV chip authentication, and multi-factor authentication; it is intended to help reduce CNP fraud but does not by itself eliminate fraud, and any associated liability or chargeback treatment is governed by card brand and network rules that vary by region and change over time. Practitioners should confirm protocol versions and requirements against the current EMVCo and PCI published specifications.

Why it matters

Card-not-present (CNP) transactions, such as e-commerce and in-app purchases, lack the physical card and chip verification available at a point-of-sale terminal, which makes confirming that a shopper is the legitimate cardholder more difficult. EMV 3-D Secure is intended to help address this gap by enabling merchants and card issuers to exchange transaction, device, and cardholder information at checkout so the issuer can assess the likelihood that a purchase is legitimate. As card networks brand and promote their own implementations, such as Visa Secure, the protocol has become a widely referenced component of online payment security.

EMV 3DS matters to practitioners because it operates at the transaction-initiation stage and can influence both fraud outcomes and the customer experience. The protocol is designed to improve on the earlier 3-D Secure 1 protocol by supporting a smoother, more integrated checkout, which addresses the friction and abandonment concerns associated with the older protocol. However, it is intended to help reduce CNP fraud rather than eliminate it, and its effectiveness depends on how risk-based and challenge-based authentication are configured and tuned.

EMV 3DS should not be treated as a substitute for other controls. It is distinct from PCI DSS scope-reduction measures, from EMV chip authentication used in card-present environments, and from multi-factor authentication generally. Any liability shift or chargeback treatment associated with an authenticated transaction is governed by card brand and network rules, which vary by region and change over time, so teams should not assume a fixed outcome from using the protocol alone.

Who it's relevant to

E-commerce merchants and acquirers

Merchants operating online or in-app checkouts and their acquirers use EMV 3DS to exchange authentication data with issuers and to support a smoother checkout experience relative to 3-D Secure 1. They should understand that liability and chargeback treatment for authenticated transactions is governed by card brand and network rules that vary by region and change over time.

Card issuers

Issuers perform the risk-based assessment at the heart of EMV 3DS and decide when to apply a frictionless flow or invoke a cardholder challenge. Tuning these decisions involves trade-offs between fraud reduction and customer friction, and the protocol is intended to help reduce CNP fraud rather than eliminate it.

Fraud analysts and merchant risk teams

Fraud and risk teams rely on the transaction, device, and cardholder signals exchanged through EMV 3DS as inputs to their CNP fraud decisioning. They should treat it as one control among several and account for the possibility of both false positives and false negatives in any risk-based authentication configuration.

3DS SDK developers

Entities that develop 3DS SDKs, as defined in the EMV 3-D Secure 3DS SDK Specification, are subject to the separate PCI 3DS SDK Security Standard. These developers should confirm applicable requirements against the current EMVCo and PCI published specifications and program guidance.

Compliance officers

Compliance staff need to distinguish EMV 3DS, which addresses cardholder authentication at transaction initiation, from PCI DSS scope controls and from the separate standards that govern related components such as the 3DS SDK. Confirming which standard governs a given control helps avoid conflating authentication with data-protection obligations.

Inside EMV 3DS

Cardholder / Consumer Device Data Sharing

EMV 3DS enables the exchange of a richer set of data elements between the merchant, the 3DS Server, and the issuer's Access Control Server (ACS) than earlier protocol versions, which is intended to support risk-based decisioning. The specific data elements exchanged depend on implementation and the channel (browser versus app-based).

Frictionless Flow

A flow in which the issuer's ACS authenticates the transaction based on the data provided without requiring additional cardholder interaction. It is intended to reduce checkout friction when the issuer's risk assessment is satisfied, though whether a given transaction is handled frictionlessly is determined by the issuer.

Challenge Flow

A flow in which the issuer requests additional cardholder interaction, such as a one-time passcode or an authentication step through a banking app, when further verification is deemed necessary. This is one mechanism by which 3DS can support additional cardholder authentication.

Protocol Roles (3DS Server, DS, ACS)

EMV 3DS defines participating components including the 3DS Server (typically on the merchant/acquirer side), the Directory Server (DS) operated by the card networks, and the Access Control Server (ACS) operated by or on behalf of the issuer. These components coordinate the authentication message flow.

Relationship to PCI 3DS

The EMV 3DS protocol is specified by EMVCo, while security requirements for certain entities performing 3DS functions are addressed by the separate PCI 3DS standard maintained by the PCI SSC. The protocol specification and the PCI security standard are distinct and should not be conflated.

Role in Card-Not-Present Authentication

EMV 3DS is an authentication mechanism applied primarily to card-not-present transactions, such as e-commerce browser and in-app purchases. It operates at the authentication point of a transaction and is distinct from EMV chip authentication used in card-present contexts.

Common questions

Answers to the questions practitioners most commonly ask about EMV 3DS.

Does EMV 3-D Secure prevent card-not-present fraud?

No. EMV 3DS is intended to help reduce certain card-not-present fraud by enabling the exchange of data between merchant, issuer, and cardholder to support risk assessment and, where needed, authentication. It may mitigate some fraud but does not eliminate it. It does not address card-present fraud, account takeover that occurs through other channels, or first-party (friendly) fraud, and its effectiveness depends on issuer risk decisions, data quality, and configuration.

Is EMV 3-D Secure the same as PCI 3DS?

No. These are distinct. EMV 3DS is a messaging protocol specification (maintained by EMVCo) that supports authentication in card-not-present transactions. PCI 3DS refers to a separate security standard governing environments and components that support 3DS functions, such as the 3DS Server, 3DS SDK, and Directory Server. One is the protocol; the other is a security standard for parts of the ecosystem. Confirm applicability of any standard against its current published version.

How does EMV 3DS relate to strong customer authentication (SCA) requirements?

EMV 3DS can serve as a technical mechanism to support authentication that may help satisfy strong customer authentication obligations in regions where such requirements apply. However, SCA is a regulatory concept, and whether a given 3DS implementation meets it depends on the applicable regional rules, the authentication factors used, and any exemptions applied. Confirm requirements against the governing regulation rather than assuming the protocol alone establishes compliance.

What is the difference between frictionless and challenge flows in an EMV 3DS transaction?

In a frictionless flow, the issuer assesses the risk data supplied during the transaction and approves authentication without prompting the cardholder for additional interaction. In a challenge flow, the issuer requests additional cardholder interaction, such as a step-up authentication, before making a decision. The choice between flows is driven by the issuer's risk evaluation and configured rules; implementations should account for both to balance fraud reduction against cardholder friction and potential abandonment.

Where do the 3DS Server, Directory Server, and Access Control Server fit in an implementation?

The 3DS Server typically integrates on the merchant or acquirer side to collect and transmit transaction and device data. The Directory Server, operated within the card brand or network ecosystem, routes messages between the 3DS Server and the issuer domain. The Access Control Server, associated with the issuer, performs risk assessment and authentication decisions. Implementation teams should clarify roles, responsibilities, and any applicable security standard obligations for the components they operate or rely upon.

Does implementing EMV 3DS change how liability for disputed transactions is handled?

It may, but liability outcomes are governed by card brand and network rules that vary by region and change over time. A successful 3DS authentication can affect how certain fraud-related disputes are allocated between parties, but this is determined by the applicable network rules and the specifics of the transaction, not by the protocol itself. Confirm current liability and chargeback rules with the relevant card brands and networks for your region.

What data quality and device information considerations affect EMV 3DS effectiveness?

Issuer risk assessment in EMV 3DS depends on the data supplied during the transaction, which can include device, transaction, and cardholder-related information. Incomplete or low-quality data may increase the likelihood of a challenge flow or a less accurate risk decision, contributing to false positives or false negatives. Implementation teams should ensure required data elements are collected and transmitted correctly, while handling any sensitive data in accordance with applicable requirements.

Common misconceptions

EMV 3DS prevents card-not-present fraud.

EMV 3DS is intended to help reduce certain card-not-present fraud by supporting cardholder authentication and richer risk data sharing, but it does not eliminate fraud. It does not address all fraud types, such as first-party or friendly fraud, and its effectiveness depends on issuer decisioning, implementation, and the flows invoked.

EMV 3DS and EMV chip authentication are the same technology.

They address different risks at different points in a transaction. EMV chip authentication applies to card-present transactions at the point of interaction, while EMV 3DS is an authentication protocol applied primarily to card-not-present transactions. They are separate mechanisms and should not be treated interchangeably.

Implementing EMV 3DS satisfies PCI 3DS or shifts all chargeback liability.

The EMV 3DS protocol, specified by EMVCo, is separate from the PCI 3DS security standard maintained by the PCI SSC, and using the protocol does not by itself demonstrate compliance with PCI 3DS requirements. Any liability shift associated with 3DS is governed by card brand and network rules, which vary by region and change over time.

Best practices

Confirm which components you operate (3DS Server, DS, or ACS functions) and determine whether the separate PCI 3DS standard applies to your entity, rather than assuming the EMV 3DS protocol alone covers your security obligations.

Treat EMV 3DS as one layer within a broader card-not-present fraud strategy, combining it with other detection and risk controls rather than relying on it to eliminate fraud.

Design and tune both frictionless and challenge flows in coordination with issuers and acquirers, weighing the trade-off between checkout friction and authentication assurance.

Verify current liability-shift and chargeback rules with the applicable card brands and networks for each region in which you operate, since these rules vary and change.

Validate the specific data elements shared in your implementation against the applicable protocol version and confirm handling of any cardholder data and sensitive authentication data consistent with the current published standards.

Monitor authentication outcomes, including challenge rates and false-positive or false-negative trade-offs, and adjust configurations as issuer decisioning and network requirements evolve.