EMV 3-D Secure: authenticating an online purchase without losing the customer

Authentication is one decision in a longer payment

An online merchant cannot inspect the person holding a physical card. Card details can be entered by a legitimate customer or by someone using stolen information. EMV 3-D Secure, usually shortened to EMV 3DS, provides a standardized way to exchange information and obtain an authentication outcome for card-not-present transactions. It is maintained by EMVCo and implemented through payment-network programs and service providers. [1]

Authentication asks whether the person using the credential can be accepted as the legitimate cardholder in the relevant transaction. Authorization separately determines whether the payment can be approved, taking account of matters such as available funds or credit and issuer controls. Visa's own explanation explicitly separates these decisions. An authenticated customer can therefore still have a payment declined. Neither authentication nor authorization is the later clearing and settlement of the merchant's proceeds. [7]

This article concerns transaction authentication at checkout. Tokenization addresses how credentials are represented and protected; login credentials address access to an account. Those technologies can contribute evidence, but none makes every checkout decision interchangeable.

The actors behind the three domains

The merchant or other party requesting authentication is the 3DS Requestor. A 3DS Server handles its authentication messaging. A Directory Server, or DS, connects the request to the appropriate issuer-side environment. The Access Control Server, or ACS, performs authentication on the issuer's side, often using a specialist provider. Browser and app-based channels supply different ways to gather context and conduct any interaction with the cardholder. [2, 9]

The names describe functions, not necessarily independent companies. A payment service provider may operate a merchant-facing server; an issuer may use a hosted ACS; a network program supplies the interoperability rules. Outsourcing the software does not merge the merchant's, issuer's and acquirer's responsibilities into one decision-maker.

The PCI Security Standards Council's introduction to its 3DS security standard identifies the ACS, DS and 3DS Server as critical components requiring security controls. That is a different layer from the EMVCo protocol itself. A protocol defines interoperable messages and behavior; protecting the systems that generate, process and store those messages is another task. Both matter to the reliability of an authentication result. [9]

Context can reduce unnecessary challenges

The issuer-side system can evaluate the transaction using information such as amount, currency, merchant, customer history and device context. EMVCo's frictionless-flow explanation describes risk-based assessment that can authenticate without asking the customer to perform another visible step. A familiar purchase on a recognized device may provide different evidence from an unusual transaction on a new device. [3]

Frictionless does not mean that no authentication process occurred. It means the process reached its outcome without the additional cardholder interaction of a challenge. Nor does it mean every invisible data exchange proves identity with absolute certainty. Risk-based decisions combine signals and tolerate some uncertainty, and criminals can sometimes control apparently credible credentials or devices.

The value of additional context depends on its quality. A stale customer history, inconsistent merchant information or a missing device signal can change the assessment. More fields are not automatically better evidence if they are inaccurate or misunderstood. This is a useful way to understand why two merchants can use the same protocol and see different challenge rates: their customers, transactions, data and issuer mix may all differ.

A challenge asks the cardholder to do something more

A challenge flow introduces additional interaction when the issuer-side ACS requires it. EMVCo describes examples such as a one-time code or authentication through a banking application. The challenge can be a rational response to higher risk or another applicable requirement. It should not be interpreted automatically as an accusation of fraud. [4]

The result can fail for different reasons. The customer may decline to proceed, enter the wrong information, lose connectivity, miss a notification or be unable to return from the banking app. A fraudster may also fail because the extra evidence is unavailable. From the merchant's perspective, all may appear as lost purchases, but their economic and security meanings differ.

This is why minimizing the challenge rate alone is not a complete objective. Removing a challenge that blocks a stolen-card transaction is not a conversion improvement in the same sense as removing an unnecessary challenge from a legitimate customer. The relevant tradeoff is between supported legitimate purchases, prevented fraud and the effort imposed on people who should be able to pay.

Browser and app handoffs are part of the security outcome

Out-of-band authentication moves the customer's verification to another channel, such as a mobile banking app. EMVCo's February 4, 2026 explanation describes a browser flow in which the issuer's interface appears within the merchant checkout, the customer switches to the banking app and then returns to complete the browser step. The transaction crosses a user-interface boundary as well as a system boundary. [5]

That handoff can create failure even after the customer successfully authenticates in the banking app. If the checkout does not learn that result, or the customer does not return to the original session, the shopping journey may remain incomplete. A success message in one application is not necessarily a success state in every other component.

A hypothetical customer approving a purchase in a bank app and then closing the browser illustrates the difference. The authentication event may have occurred, but the merchant still needs the relevant result and a valid authorization path before treating the order as paid. Good user-interface continuity is therefore part of operational correctness, not merely decorative polish. It helps keep the customer's action, the authentication result and the intended purchase associated with one another.

Data moves through a defined security boundary

EMVCo's technical discussion of app-based device information describes collection through the software development kit, or SDK, and encryption using the Directory Server's public key. The 3DS Server forwards the encrypted information; the DS processes it for delivery to the ACS. The purpose is to make device context available for risk assessment while preserving the intended confidentiality and integrity boundaries. [2]

This does not mean every participant can freely see or retain every signal. Device permissions, operating-system restrictions and applicable privacy obligations still shape what is available and how it can be used. EMVCo's overview explicitly leaves responsibility for privacy-law compliance with the merchants and issuers using the data. [1]

The separation is economically important. A merchant may want a reliable outcome rather than access to all the issuer's underlying risk evidence. An issuer may want a trustworthy device signal rather than a merchant-entered assertion about the device. Authentication works by coordinating evidence under defined roles, not by creating one unrestricted pool of personal information visible to every participant.

A technical standard is not a universal liability rule

EMVCo defines protocol capabilities. Network rules determine when particular dispute rights or liability protections apply. In the Visa public rulebook dated April 18, 2026, the card-absent fraud provisions identify a qualifying ECI 5 transaction with an issuer authentication confirmation and a CAVV in the authorization request as one route to an invalid Condition 10.4 dispute. The same rulebook contains exceptions and separate treatment for some U.S. domestic merchant categories. [8]

ECI is the electronic-commerce indicator; CAVV is Visa's cardholder authentication verification value. Their presence and correct use connect the authentication outcome to the subsequent payment record. A merchant cannot infer every applicable protection merely from having shown a challenge screen. The network, geography, transaction category, authentication outcome and transmitted data matter.

This is a bounded Visa example, not a statement that all card brands shift all losses after any 3DS attempt. Fraud-related protection also does not establish that goods were delivered or that every other dispute is invalid. Authentication is evidence about the use of a payment credential; it does not fulfill the merchant's commercial promises. The distinction protects readers from confusing a technical success result with blanket immunity from customer claims.

Authentication, authorization and completion have different denominators

Imagine a hypothetical merchant beginning 10,000 3DS authentications. Suppose 8,000 finish frictionlessly and 2,000 require challenges. If 85% of challenges succeed, there are 1,700 successful challenges and 9,700 successful authentications overall. If 96% of those subsequently obtain authorization, 9,312 purchases are authorized. These are deliberately invented rates, with arithmetic shown to distinguish the stages.

The authentication success rate is 97% of starts. The challenge success rate is 85% of challenged attempts. The authorization rate is 96% of successful authentications, while the authorized share of the original cohort is 93.12%. None of these is necessarily the final fulfilled-sale rate. Some authorized orders can later be cancelled, refunded or disputed.

Now improve challenge completion from 85% to 90%, holding all other assumptions fixed. That adds 100 successful authentications and, at the same 96% authorization rate, 96 authorized purchases. The illustration shows the potential leverage of a better challenge experience. It does not estimate the actual effect of an EMVCo feature, because changing the challenged population or fraud mix could also change the subsequent outcomes.

Scroll horizontally to see all columns.

Versions and deployment dates are different facts

The EMVCo technology page reviewed October 4, 2026 lists a June 3, 2026 version 2.4 draft with a July 1 comment deadline. It also lists August 2025 specification bulletins covering versions 2.2.0 through 2.3.1.1. A draft listing is not proof of a final production standard or universal deployment. The March 2025 whitepaper expressly explains capabilities across supported versions and notes that implementations can vary by 3DS program. [1, 6]

This matters when reading claims about a feature such as device binding, an out-of-band handoff or an extension. A capability can exist in a specification before all servers, ACSs, SDKs and network programs support it. A provider saying it supports a newer version does not establish that the other side of every transaction will negotiate and use all those features.

The analysis here therefore uses the published whitepaper for established concepts and identifies the 2.4 material as a draft encountered during research. It does not extrapolate the draft into a mandatory migration deadline. Protocol publication, testing availability, network requirements and actual merchant or issuer adoption are separate milestones.

The economic balance is broader than conversion

An authentication service has direct costs, integration and maintenance work, but its largest effects may be indirect. It can prevent losses, allow legitimate purchases that would otherwise be declined, reduce or redistribute certain dispute exposure, and impose friction that causes some customers to abandon. The distribution of those benefits and costs differs between merchant, issuer, acquirer and customer.

A merchant may value additional approved sales, but the contribution margin on those sales matters more than gross checkout value. An issuer may value lower fraud but still need to control credit exposure. A liability protection can change who absorbs a loss without making the underlying fraud disappear. Customer trust and the ability to complete a purchase are also affected by how understandable the process feels.

The strongest interpretation of EMV 3DS is consequently specific: it provides interoperable evidence and interaction for online cardholder authentication. Frictionless flows and challenges are two ways to reach that result. Network rules determine the legal consequences of qualifying outcomes, and authorization and settlement remain separate steps. Keeping those boundaries visible explains both the protocol's value and why merely switching it on cannot guarantee a safe, approved and completed purchase.

Sources

1. EMVCo, EMV 3-D Secure technology overview and specification index; checked October 4, 2026SourceBack to text: ↑1↑2↑3
2. EMVCo, March 2025 whitepaper technical features; device information and message rolesSourceBack to text: ↑1↑2
3. EMVCo, Frictionless Flow business overview; March 2025 whitepaperSourceBack to text: ↑
4. EMVCo, Challenge Flow business overview; March 2025 whitepaperSourceBack to text: ↑
5. EMVCo, browser-based out-of-band authentication; February 4, 2026SourceBack to text: ↑
6. EMVCo, Whitepaper V2 introduction; March 2025 version and implementation caveatsSourceBack to text: ↑
7. Visa, How authentication protects digital payments; authentication versus authorizationSourceBack to text: ↑
8. Visa Core Rules and Product and Service Rules; April 18, 2026 edition, section 11.7.5 and Tables 11-27/11-28Source · PDFBack to text: ↑
9. PCI Security Standards Council, 3DS core-security standard introduction; historical component definitionsSourceBack to text: ↑1↑2