3-D Secure (3DS)

What 3DS checks, and who decides

3-D Secure is an authentication protocol for card-not-present purchases. EMVCo, which maintains the EMV 3DS specifications, describes it as an exchange of messages between the merchant and the card issuer carrying data about the transaction, the payment method and the device. The issuer uses that data to judge whether the person paying is the legitimate cardholder. The decision belongs to the issuer, not to the merchant or to the payment gateway that carries the message.

Source: EMVCo, “EMV® 3-D Secure” (protocol scope and authentication outcomes), accessed 2026-09-04.

Frictionless and challenge outcomes

EMVCo describes two broad results. For many purchases the submitted data is enough and the shopper simply completes the order. For higher-risk ones the issuer may require a challenge — a one-time passcode, knowledge-based questions, biometrics or another method. Adyen documents the same split in its native implementation as a frictionless flow and a challenge flow, and offers a redirect implementation that sends the shopper to the issuer’s site instead. Which path a given payment takes is the issuer’s call, so a checkout has to handle both.

Source: EMVCo, “EMV® 3-D Secure” (protocol scope and authentication outcomes); Adyen, “3D Secure 2 authentication” (this provider’s native, redirect, frictionless and challenge flows), accessed 2026-09-04.

Authentication is not authorization

A completed authentication does not settle whether the payment will be approved. Authentication and payment authorization are separate steps, and an authenticated transaction can still be refused. Adyen’s refusal-reason list includes “3D Not Authenticated” for authentication that was not executed or did not succeed, “3DS Authentication Error” for a failure at the card network or issuer, and “Authentication required” where the issuing bank declined an exemption request. Those names are Adyen’s; other providers label the same conditions differently.

Source: Adyen, “Refusal reasons” (this provider’s refusal-reason names), accessed 2026-09-04.

How liability moves under scheme rules

The liability shift is a dispute rule, not a payment feature. Under the Visa rules, a card-absent fraud dispute is invalid where the transaction carried Electronic Commerce Indicator 5, the issuer answered the authentication request with an authentication confirmation using Visa Secure with EMV 3DS, and the Cardholder Authentication Verification Value (CAVV) was in the authorization request. A separate entry covers an attempt response with ECI 6 and excludes non-reloadable prepaid card transactions. Both entries are listed under Country/Region “All”; other entries in the same table apply only to named countries. That closes one fraud chargeback condition; it says nothing about non-fraud dispute reasons, and each scheme publishes its own rules.

Source: Visa, “Visa Core Rules and Visa Product and Service Rules, §11.7.5.3 Dispute Condition 10.4: Other Fraud – Card-Absent Environment – Invalid Disputes (edition 18 April 2026)” (Visa rules only, other schemes publish their own; the ECI 5 and ECI 6 entries are listed under Country/Region “All”, while other entries in the same table are country-specific); Visa, “Visa Core Rules and Visa Product and Service Rules, §5.8.4.4 Visa Secure Acquirer and Merchant Participation Requirements (edition 18 April 2026)” (Visa rules only; clearing-record requirement, no region limit stated), accessed 2026-09-04.

What to record on an authenticated payment

A 3DS dispute defense depends on the evidence you can produce later, not only on having the feature switched on. Record these fields with the order, not only in the provider dashboard.

Source: Visa, “Visa Core Rules and Visa Product and Service Rules, §5.8.4.4 Visa Secure Acquirer and Merchant Participation Requirements (edition 18 April 2026)” (Visa rules only; clearing-record requirement, no region limit stated); Visa, “Visa Core Rules and Visa Product and Service Rules, §11.7.5.3 Dispute Condition 10.4: Other Fraud – Card-Absent Environment – Invalid Disputes (edition 18 April 2026)” (Visa rules only, other schemes publish their own; the ECI 5 and ECI 6 entries are listed under Country/Region “All”, while other entries in the same table are country-specific); Adyen, “Refusal reasons” (this provider’s refusal-reason names), accessed 2026-09-04.

Where the rules differ

Whether 3DS is required depends on where the card was issued and where the business operates. Visa sets acquirer obligations country by country in a table, with some entries applying only to listed merchant category codes, and a footnote to the same section states that a merchant must adhere to an issuer’s requested authentication method. Visa also requires participants to have their EMV 3DS components pass the EMVCo compliance testing program and Visa’s own test suite. In Europe the requirement is strong customer authentication under PSD2, detailed in the European Banking Authority’s regulatory technical standards, Regulation (EU) 2018/389, which also govern exemptions. Stripe states that card payments require 3D Secure to meet SCA, and that 3DS is optional in other regions.

Source: Visa, “Visa Core Rules and Visa Product and Service Rules, §5.8.4.3 Acquirer Support of Visa Secure (edition 18 April 2026)” (Visa rules only; obligations set country by country in Table 5-17); Visa, “Visa Core Rules and Visa Product and Service Rules, §10.15.1.1 Visa Secure Participation Requirements (edition 18 April 2026)” (Visa rules only; participation and testing requirements, no region limit stated); European Banking Authority, “Regulatory Technical Standards on strong customer authentication and secure communication under PSD2” (EU regulatory basis and exemptions); Stripe, “Strong Customer Authentication readiness” (this provider’s SCA scope guidance); Stripe, “3D Secure authentication” (this provider’s statement that 3DS is optional outside SCA regions), accessed 2026-09-04.

• Check the country rules for every card you accept, not only your home market.
• Ask your acquirer which authentication outcomes qualify under the invalid-dispute entries.
• Store the ECI and CAVV alongside the order record, not only in provider reports.
• Monitor a redirect challenge separately, because abandonment there looks like a decline.
• Re-check exemption handling whenever your provider changes its authentication behavior.

Source: Visa, “Visa Core Rules and Visa Product and Service Rules, §5.8.4.3 Acquirer Support of Visa Secure (edition 18 April 2026)” (Visa rules only; obligations set country by country in Table 5-17); Visa, “Visa Core Rules and Visa Product and Service Rules, §5.8.4.4 Visa Secure Acquirer and Merchant Participation Requirements (edition 18 April 2026)” (Visa rules only; clearing-record requirement, no region limit stated); Adyen, “3D Secure 2 authentication” (this provider’s native, redirect, frictionless and challenge flows), accessed 2026-09-04.

Read Address Verification Service (AVS) and Card Verification Value (CVV) for the other card-absent checks that sit next to authentication.