3D Secure Payment Gateway: How 3DS2 Protects Merchants From Fraud
3D Secure is an authentication protocol developed by the card schemes that adds a layer of identity verification to online card transactions. When a customer pays through a 3D Secure enabled gateway, their issuing bank verifies the transaction before it is authorised, either through a frictionless background check or by prompting the customer for authentication via their banking app. For merchants, 3D Secure provides two critical benefits: it significantly reduces fraud losses on online transactions, and it shifts chargeback liability for fraud disputes from the merchant to the issuing bank. This guide explains how 3D Secure works, how version 2 differs from version 1, and how to implement 3DS2 through RoxPay.
What 3D Secure Is and How It Works
3D Secure (3DS) is an XML-based authentication protocol for card-not-present transactions. The three domains in the name refer to the merchant domain, the acquirer domain, and the interoperability domain (the card scheme network and the issuing bank). Together, these three parties participate in verifying that the person initiating the transaction is the authorised cardholder.
Transaction flow with 3DS:
The customer enters card details at checkout and submits the payment. The merchant's gateway submits the transaction with a 3DS authentication request. The card scheme routes the request to the card issuer's Access Control Server. The issuer performs a risk assessment on the transaction. If the risk assessment indicates low risk (frictionless flow), the transaction is authenticated without customer interaction. If the risk is above the frictionless threshold, the customer is prompted to authenticate, typically by approving a push notification in their banking app, entering a one-time password, or providing biometric confirmation. The authentication result (authenticated, attempted, or failed) is returned to the merchant's gateway, which includes it in the authorisation request to the acquirer.
The liability shift: When a transaction is successfully authenticated via 3DS, and the cardholder later disputes it as fraudulent, the chargeback liability shifts from the merchant to the issuing bank. The issuing bank approved the authenticated transaction; it cannot then succeed in disputing it as unauthorised. This liability shift is the primary commercial benefit of 3DS for merchants.
For merchants operating a high risk payment gateway, implementing 3DS2 is particularly important because high-risk categories tend to have elevated fraud and friendly fraud rates, making the liability protection commercially significant.
3DS1 vs 3DS2: What Changed and Why It Matters
The original 3D Secure specification (3DS1) was introduced in the early 2000s. While it provided a liability shift mechanism, it had serious usability and conversion problems that merchants experienced as cart abandonment at the authentication step. 3DS2 (EMV 3DS) was developed to address these problems.
3DS1 problems:
3DS1 required a redirect to the issuer's authentication page, which was often poorly designed and confusing to customers. The static password model used by many issuers (Verified by Visa, MasterCard SecureCode) was easy to forget and created friction on every transaction. On mobile devices, the redirect and pop-up-based flow was particularly problematic. Many merchants disabled 3DS1 specifically because the authentication step was causing more transaction abandonment than the fraud losses they were trying to prevent.
3DS2 improvements:
3DS2 introduces a rich data sharing model. The merchant's gateway sends up to 150 data points with the authentication request, including device fingerprint, browser characteristics, order history, and behavioural signals. The issuer uses this data to make a risk decision. For low-risk transactions, the issuer can grant a frictionless authentication, meaning the customer is never asked to do anything and the transaction proceeds seamlessly.
Authentication methods in 3DS2: When authentication is required, 3DS2 supports modern methods: push notifications to a banking app with biometric confirmation, one-time passcodes via SMS, and in-app authentication without redirect. These are significantly less disruptive than the 3DS1 pop-up redirect.
PSD2 and Strong Customer Authentication: The EU's Revised Payment Services Directive (PSD2) mandates Strong Customer Authentication (SCA) for most European card-not-present transactions. 3DS2 is the primary mechanism for SCA compliance. Issuers are required to apply SCA to transactions that do not qualify for an exemption. Merchants who do not support 3DS2 find that transactions are soft-declined by issuers who require SCA but cannot complete it because the gateway does not pass 3DS2 authentication data.
How 3D Secure Reduces Chargeback Liability for Merchants
The liability shift provided by 3D Secure authentication is the mechanism through which merchants reduce chargeback losses on fraud disputes.
How the liability shift works in practice: A customer completes a purchase and authenticates via 3DS2 (for example, by approving a push notification in their banking app). The transaction is processed and the goods are delivered. A month later, the customer contacts their issuing bank claiming the transaction was unauthorised. The bank initiates a chargeback under a fraud reason code (Visa 10.4, Mastercard 4853).
When the merchant's gateway submits the rebuttal, it includes the 3DS2 authentication record: the Authentication Transaction ID (ATID), the authentication status (authenticated), and the ECI value indicating full authentication. This record demonstrates that the cardholder's issuing bank itself authenticated the transaction. The bank's dispute team sees that the same bank that is now processing the dispute was the one that authenticated the transaction. In practice, this results in reversal of the chargeback in the vast majority of cases.
Transactions that do not benefit from liability shift: Not all 3DS2 outcomes provide liability shift. A transaction that goes through the authentication process but results in an "attempted" authentication status (the card does not support full authentication) provides limited protection compared to a fully authenticated result. Liability shift applies most strongly to transactions with a successful authentication result and an ECI value of 05 (Visa) or 02 (Mastercard).
Exemptions and liability: Certain 3DS2 exemptions (low-value transactions under 30 euros, trusted beneficiary listings, recurring transactions) allow transactions to proceed without SCA. The liability position for exemption-based transactions varies by exemption type. Low-value exemption transactions where the issuer applies the exemption retain liability with the merchant. Transactions where the merchant requests an exemption that the issuer subsequently approves can result in the liability remaining with the merchant.
When 3D Secure Is Required vs Optional
Under PSD2's Strong Customer Authentication mandate, 3D Secure is required for most European card-not-present transactions, but a range of exemptions and out-of-scope scenarios define when SCA does not apply.
When 3DS is required (SCA applies):
All standard card-not-present payments initiated by the customer (customer-initiated transactions, or CITs) for amounts above the low-value threshold are subject to SCA. The default position is that SCA is required; exemptions are the exceptions.
Exemptions that allow transactions without 3DS:
Low-value transactions: Transactions below 30 euros may qualify for a low-value exemption. However, issuers track cumulative amounts and transaction counts; once five consecutive low-value exemptions have been applied or the cumulative amount exceeds 100 euros, SCA is required for the next transaction.
Transaction risk analysis (TRA): Issuers and acquirers can apply TRA exemptions to transactions they assess as low risk based on fraud rate benchmarks. To apply a TRA exemption at the acquirer level, the acquirer must meet specific fraud rate thresholds defined by PSD2.
Recurring transactions: The initial payment in a recurring series requires SCA. Subsequent merchant-initiated transactions (MITs) in the same recurring mandate can proceed without SCA, provided the initial transaction was authenticated and the subsequent transactions follow the stored credential framework.
Trusted beneficiary: Cardholders can add merchants to a whitelist with their issuer, applying a trusted beneficiary exemption to future transactions with that merchant.
Out of scope for SCA: Transactions initiated by the merchant without customer interaction (MIT), transactions where one party is outside the EEA (one-leg out transactions), and corporate card transactions are out of scope for PSD2 SCA in specific circumstances.
Implementing 3DS2 With RoxPay
RoxPay's payment gateway supports 3DS2 natively. The implementation is handled within the existing integration architecture, with no requirement for a separate 3DS provider or additional contract.
Drop-in UI approach: If you use RoxPay's drop-in UI (JavaScript-based card input), 3DS2 is handled automatically. When the issuer requires authentication, the library manages the redirect to the issuer's authentication environment, handles the response, and continues the payment flow without additional code on the merchant side. This is the simplest path to 3DS2 compliance.
API integration approach: For merchants using a direct API integration, 3DS2 authentication data is passed via the payment intent parameters. The API returns the authentication result and required action for the merchant's frontend to handle, following the standard 3DS2 challenge flow. Full documentation is available at app.roxpay.eu/api/v4/docs.
Frictionless rate optimisation: RoxPay passes the maximum available data in the 3DS2 authentication request to support high frictionless rates. Frictionless authentication means the customer is never asked to confirm anything; the issuer approves the transaction in the background. The higher the frictionless rate, the better the conversion impact of 3DS2.
Testing in sandbox: The RoxPay sandbox provides test scenarios for every 3DS2 outcome: frictionless authentication, challenge authentication, authentication failure, and card not enrolled. Test all scenarios before going live to ensure your checkout handles each outcome correctly.
To start your RoxPay application and begin testing 3DS2 in the sandbox, registration takes under ten minutes and sandbox credentials are issued immediately. RoxPay is PCI DSS Level 1 certified (QS83A47X629) and ISO 27001 certified.
Frequently Asked Questions
Does 3D Secure reduce conversion rates?
3DS2 with proper implementation has minimal conversion impact compared to 3DS1. The frictionless authentication flow, where the issuer authenticates the transaction in the background without customer action, represents 80-90% of authenticated transactions for well-configured merchants. The remaining transactions that require a challenge (typically bank app push notification or OTP) do see some drop-off, but this is significantly lower than the drop-off experienced with 3DS1's redirect and static password model.
What is the ECI value in 3DS authentication?
The Electronic Commerce Indicator (ECI) value in a 3DS authentication response indicates the level of authentication achieved. ECI 05 (Visa) or 02 (Mastercard) means full authentication was completed and provides full liability shift. ECI 06 or 01 means the card attempted authentication but the issuer did not support it, providing limited liability shift. ECI 07 means authentication was not performed; no liability shift applies.
What happens if a customer fails 3D Secure authentication?
If the customer fails to complete the 3DS2 challenge (cancels the banking app push, enters the wrong OTP, or lets the session time out), the authentication fails and the payment is not processed. Your gateway should display a clear error message and allow the customer to retry or use a different payment method. Failed authentication is not a chargeback; the transaction is simply not authorised.
You might also like
High Risk Payment Gateway
Secure payment processing for high-risk industries with multi-acquirer routing and chargeback protection.
Small Business Payment Solutions
Transparent IC++ pricing, free Smart POS terminal, and 24-hour activation for small businesses.
E-commerce Payment Integrations
One-click plugins for Shopify, WooCommerce, Magento, and PrestaShop with full API access.
Optimize your payments today
RoxPay supports native 3DS2 with frictionless rate optimisation, liability shift for authenticated transactions, and full sandbox testing. PCI DSS Level 1 certified, IC++ pricing from 0.45%.
✓ No monthly fixed costs · ✓ Activation in 24 hours · ✓ Dedicated technical support
