3D Secure (3DS)

3D Secure (3DS) is an authentication protocol used in card-not-present transactions to verify cardholder identity before payment authorization. The protocol prompts the cardholder to confirm their identity through a secondary authentication method (one-time password, biometric verification, or device-based push notification) at checkout.

‍

Card networks implement 3DS under different brand names: Visa Secure, Mastercard Identity Check, and American Express SafeKey. The current version, 3DS 2.0, supports mobile-first authentication flows, biometric methods, and risk-based authentication that can reduce friction for low-risk transactions.

‍

‍

Why 3D Secure Matters

‍

Payment providers, acquirers, and merchants face two core challenges that 3DS addresses:

‍

Fraud Liability in Card-Not-Present Transactions

Without cardholder authentication, merchants bear liability for fraudulent transactions. Chargebacks resulting from unauthorized use create direct financial loss and increase processing costs. In card-present environments, EMV chip technology provides authentication. In online transactions, 3DS serves as the digital equivalent.

‍

Regulatory Requirements for Strong Customer Authentication

In the European Economic Area (EEA), the Revised Payment Services Directive (PSD2) mandates Strong Customer Authentication (SCA) for most electronic payments. SCA requires authentication using at least two of three factors: knowledge (password), possession (phone or token), or inherence (biometric). 3DS is the primary method payment providers use to meet this requirement for card transactions.

‍

Friction vs. Security Trade-offs

Authentication steps add friction to checkout. Conversion rate impact is a documented concern for merchants. We see this trade-off surface in decisions around when to apply 3DS, which exemptions to use, and how to configure risk thresholds. 3DS 2.0 introduced "frictionless" authentication for transactions the issuer deems low-risk, but the final authentication decision rests with the issuing bank, not the merchant or acquirer.

‍

‍

How to Implement 3D Secure Effectively

‍

Implementing 3DS requires coordination between merchants, acquirers, payment gateways, and card issuers. We recommend the following approach:

‍

1. Enable 3DS 2.0 Across All Payment Flows

3DS 1.0 was browser-based and created significant friction, particularly on mobile devices. 3DS 2.0 supports in-app and mobile-web authentication, uses richer data signals (device fingerprinting, transaction history, behavioral data), and enables frictionless flows. Payment service providers should ensure their systems support 3DS 2.0 and that merchants are not routing transactions through legacy 3DS 1.0 protocols.

‍

2. Configure SCA Exemptions Where Applicable

PSD2 allows exemptions from SCA in specific scenarios: low-value transactions (under €30), recurring payments after the initial authenticated transaction, trusted beneficiaries (whitelisted merchants), and transactions with low fraud risk based on the acquirer's or issuer's fraud rate. Acquirers and merchants should configure systems to request these exemptions where appropriate, but understand that issuers may still require authentication even when an exemption is requested.

‍

3. Monitor Authentication Rates and Issuer Responses

Not all transactions that enter the 3DS flow result in successful authentication. Issuers may decline to authenticate, customers may abandon the authentication step, or technical failures may occur. We track three metrics: authentication request rate (percentage of transactions sent to 3DS), authentication success rate (percentage that complete authentication), and authorization rate post-authentication. A drop in any of these signals a problem in the flow (technical integration issue, issuer configuration, or user experience problem).

‍

4. Implement Liability Shift Tracking

When a transaction is successfully authenticated via 3DS, liability for fraud-related chargebacks shifts from the merchant to the issuer in most cases. However, liability shift is not automatic. It depends on proper 3DS implementation, correct passing of authentication values (such as the Electronic Commerce Indicator and Authentication Value), and issuer participation. Payment operations teams should track which transactions received liability shift and flag any patterns where liability shift did not occur despite successful authentication.

‍

5. Test Authentication Flows Across Devices and Browsers

3DS authentication can fail due to browser compatibility issues, mobile app integration errors, or network timeouts. We usually advise teams to test authentication on iOS and Android native apps, mobile web browsers (Safari, Chrome), and desktop browsers, and to monitor real-world failure rates by device type. If one device category shows higher abandonment or failure rates, that points to a technical issue in the integration.

‍

‍

Example: 3DS in a High-Risk Merchant Scenario

‍

An acquirer onboards a merchant selling high-value electronics (average transaction value: €800). The merchant operates in the EEA, so SCA applies. Without 3DS, the merchant would bear full liability for fraudulent card transactions, and the acquirer would face regulatory risk for non-compliance with PSD2.

‍

The acquirer implements 3DS 2.0 with the following configuration:

‍

• All transactions above €30 trigger 3DS authentication

‍

• Transactions under €30 request the low-value exemption but still pass transaction data to the issuer

‍

• Returning customers who complete one authenticated transaction can save the merchant as a trusted beneficiary, reducing friction on subsequent purchases

‍

In the first 90 days, the merchant processes 5,000 transactions. 4,200 trigger 3DS authentication. Of those, 3,800 complete authentication successfully (90% authentication completion rate), and 3,600 are authorized by the issuer (95% authorization rate post-authentication). Liability for fraud shifts to the issuer on the 3,600 authenticated transactions. The merchant experiences two fraud-related chargebacks on transactions that bypassed 3DS due to technical errors, which the merchant must cover.

‍

The acquirer's risk team identifies that authentication completion is lower on mobile web (85%) compared to desktop (94%). Investigation reveals that the merchant's checkout page has a session timeout issue on mobile browsers. After fixing this, mobile authentication completion increases to 92%.

‍

‍

Strategic Context: 3DS as a Risk and Compliance Tool

‍

For acquirers, PayFacs, and independent sales organizations (ISOs), 3DS is both a fraud mitigation control and a compliance requirement. The decision to enforce 3DS (and when to apply it) depends on multiple factors: merchant risk profile, transaction type, regulatory jurisdiction, and issuer behavior.

‍

In markets where SCA is required (EEA, UK), 3DS is effectively mandatory for most transactions. In other regions (United States, Canada, parts of Asia), 3DS is optional but may be required by card networks for certain merchant categories or transaction types (high-risk MCCs, high-value transactions, cross-border payments).

‍

We see acquirers struggle with two specific issues:

‍

Issuer Authentication Rates Vary

Not all issuers support 3DS 2.0, and some issuers authenticate a lower percentage of transactions than others. If an issuer declines to authenticate, the liability remains with the merchant or acquirer (depending on the agreement). This creates inconsistency in risk exposure. Tracking issuer-level authentication and authorization rates helps identify which issuers are creating higher risk.

‍

3DS Does Not Prevent All Fraud

Authentication confirms that the person completing the transaction has access to the cardholder's authentication method (password, phone, biometric). It does not confirm that the payment is legitimate. Account takeover fraud, where a fraudster gains access to the customer's credentials and authentication factors, can bypass 3DS. Social engineering attacks that trick customers into authenticating fraudulent transactions also bypass 3DS. We recommend layering 3DS with other fraud controls: transaction velocity checks, device fingerprinting, behavioral analytics, and post-authorization transaction monitoring.

‍

3DS is a component of a broader risk management framework. It reduces certain fraud types (stolen card credentials, card testing) and shifts liability in many cases, but it is not a complete fraud prevention solution.

‍

‍

Related Concepts and Tools

‍

Implementing effective authentication and fraud prevention requires understanding several interconnected areas:

‍

• Strong Customer Authentication (SCA): The regulatory framework that mandates two-factor authentication for electronic payments in the EEA. For a detailed explanation of SCA requirements and exemptions, see our merchant underwriting solution, which helps acquirers assess merchant compliance with authentication requirements.

‍

• Merchant Risk Monitoring: Authentication is one control in a multi-layered fraud prevention system. Continuous monitoring of merchant transaction patterns, dispute rates, and authentication performance is necessary to detect emerging fraud trends. Learn more about how risk teams monitor authentication and fraud metrics in our merchant monitoring solution.

‍

• Chargeback Liability: Understanding when liability shifts and when it does not is critical for acquirers and merchants. 3DS shifts liability in many cases, but not all. Liability depends on proper implementation, issuer participation, and transaction type.

‍