3D Secure (3DS)

The name refers to the three domains involved in the authentication process: the merchant domain, the acquirer domain, and the issuer domain. Each plays a distinct role in verifying the transaction before authorization is granted.

How Does 3D Secure Work?

When a customer initiates an online payment on a 3DS-enabled checkout, the authentication process runs alongside the standard authorization flow:

The merchant's payment gateway sends a 3DS authentication request to the card network, which routes it to the cardholder's issuing bank. The issuing bank evaluates the transaction using a combination of real-time risk signals device fingerprint, behavioral data, transaction history, IP address, purchase amount and determines whether the transaction can be authenticated silently or whether additional cardholder verification is required.

Frictionless authentication occurs when the issuing bank's risk engine determines the transaction is low-risk based on the available data signals. The authentication completes invisibly in the background the cardholder experiences no interruption and the transaction proceeds directly to authorization. The majority of 3DS transactions in a well-configured implementation complete frictionlessly.

Challenge authentication is triggered when the issuing bank requires additional verification typically when the transaction presents elevated risk signals or when regulatory requirements mandate step-up authentication regardless of risk score. The cardholder is presented with a verification step an OTP (one-time password) sent to their registered phone number, a biometric confirmation, or a push notification in their banking app before the transaction can proceed.

3DS1 vs. 3DS2

The original 3D Secure protocol 3DS1, introduced in the early 2000s required a redirect to the issuing bank's authentication page for every transaction. The redirect experience was disruptive, poorly designed, and consistently increased cart abandonment rates. Many merchants chose not to implement 3DS1 precisely because the conversion cost outweighed the fraud reduction benefit.

3DS2, introduced in 2019 and now the dominant version, fundamentally redesigned the protocol around the frictionless flow. Rather than defaulting to a redirect, 3DS2 sends a rich data package up to 150 data elements including device fingerprint, transaction history, shipping address match, and behavioral signals to the issuing bank's risk engine, enabling the vast majority of low-risk transactions to authenticate without any visible interruption to the checkout experience.

The result is a protocol that reduces fraud and shifts liability without the conversion-destroying redirect experience of its predecessor. 3DS2 is the standard against which all modern authentication implementations are measured.

Liability Shift: The Core Commercial Incentive

The most commercially significant aspect of 3D Secure is the liability shift it creates. In a standard card-not-present transaction without 3DS authentication, fraud liability sits with the merchant if a fraudulent transaction is disputed, the merchant bears the chargeback cost.

When a transaction is successfully authenticated via 3DS, fraud liability shifts from the merchant to the issuing bank. If a 3DS-authenticated transaction is subsequently disputed as fraudulent, the issuing bank not the merchant absorbs the chargeback cost.

This liability shift is the primary commercial driver of 3DS adoption. For merchants with significant fraud exposure or high chargeback rates, the fraud liability transfer achieved through 3DS authentication can represent a material improvement in net profitability beyond the direct reduction in fraudulent transactions.

3DS and PSD2 Strong Customer Authentication

In Europe, 3DS implementation is not optional for most online transactions. The EU's Payment Services Directive 2 (PSD2) mandates Strong Customer Authentication (SCA) for electronic payments requiring that transactions be authenticated using at least two of three factors: something the cardholder knows (password, PIN), something they have (phone, hardware token), and something they are (biometric).

3DS2 is the primary technical mechanism through which SCA compliance is achieved for card payments in the European Economic Area. Merchants processing card transactions for European cardholders without SCA-compliant authentication face declined transactions issuing banks in the EEA are required to decline non-SCA-compliant payment attempts on in-scope transactions.

SCA exemptions exist for low-value transactions (under €30), merchant-initiated transactions, trusted beneficiaries, and transactions assessed as low-risk by the issuing bank under a transaction risk analysis exemption. Managing these exemptions intelligently applying SCA where required and claiming exemptions where eligible is one of the more technically nuanced aspects of European payment optimization.

3DS and Conversion Rate

The relationship between 3DS and conversion rate is nuanced and depends heavily on implementation quality:

• A poorly configured 3DS implementation one that triggers challenge authentication on a high percentage of transactions, presents a disruptive verification flow, or fails to pass sufficient data to enable frictionless authentication will increase cart abandonment and reduce conversion rate.
• A well-configured 3DS implementation one that passes rich transaction data to maximize frictionless rates, applies exemptions intelligently, and presents challenge flows only when genuinely necessary can achieve high authentication rates with minimal conversion impact.

The gap between a poor and a well-optimized 3DS implementation in terms of conversion rate impact can be 3% to 8% of transactions a commercially significant difference that makes implementation quality a payment performance decision as much as a security one.

Related words

• Network token
• Payment Token
• Interchange Fee‍
• Payout Fee
• Chargeback Fee

‍