3D Secure (3DS) is an authentication step for online credit and debit card payments. It confirms that the person entering a card is the actual cardholder before the transaction completes, usually by sending the customer through a verification challenge controlled by their card issuer.
3DS comes in two generations. 3DS 1.0 was the original version, but it added enough friction to checkout that it hurt conversion. 3DS 2.x replaced it with a design meant to authenticate customers with less disruption, often without a visible challenge at all when the issuer already trusts the transaction.
It matters most in regions that require Strong Customer Authentication (SCA), such as the EU and UK under PSD2. Under that regulation, many online transactions where a customer is actively checking out need multi-factor authentication, and 3DS is the mechanism that delivers it. Whether a specific transaction triggers a challenge is decided by the card issuer, not by the merchant or by Recurly. Some transactions pass through with no visible challenge; others prompt the customer for a one-time code, biometric confirmation, or another verification step defined by their bank.
3DS applies to customer-initiated transactions, where the customer is present and active, such as signing up for a subscription or updating billing information. It does not apply to merchant-initiated transactions like scheduled subscription renewals, which are handled separately from an SCA standpoint.
Why it matters
Card-not-present fraud is a persistent cost for subscription businesses, and 3DS shifts some of that liability from the merchant to the card issuer when a transaction is properly authenticated. For merchants operating in the EU or UK, 3DS support is not optional: PSD2 compliance requires it for in-scope transactions, and failing to support it can mean failed payments or regulatory exposure.
Beyond compliance, 3DS 2.x is designed to protect conversion rather than hurt it. Because issuers can often authenticate a low-risk transaction without an explicit challenge, a well-implemented setup can add fraud protection without adding friction for legitimate customers.
Recurly surfaces 3DS authentication outcomes directly in the transaction record on supported gateways, alongside AVS and CVV results, so merchants get fraud and authentication visibility without a separate reporting tool.
How to use
Confirm your payment gateway supports 3DS 2.x and that it's enabled in your gateway settings. Setup steps vary by gateway, and some legacy gateways only support 3DS through certain integration paths.
Integrate through Recurly.js, a hosted payment page, or Checkout, since these are the paths that trigger 3DS challenges. Payments created directly in the Recurly dashboard don't trigger 3DS. If you're integrated purely through the API without one of these frontends, you'll need Recurly.js to complete a challenge when a gateway requests one.
Make sure your checkout flow collects the customer data issuers use for authentication, including billing details, browser data, and IP address. Card networks have tightened requirements around this data in recent years, and missing or generic data can affect authentication outcomes.
For SCA-sensitive actions outside a normal checkout, such as reactivating or resuming a subscription, use the verify billing info endpoints to re-run authentication against an existing account or billing info ID rather than asking the customer to re-enter their card.
Monitor authentication outcomes in your transaction details to see whether a payment was authenticated, attempted, exempted, or failed, and use that visibility to diagnose decline patterns tied to 3DS.
Benefits and examples
Shifts fraud liability toward the issuer for properly authenticated transactions, reducing a merchant's exposure to certain chargeback types.
Supports compliance with PSD2 and SCA requirements for merchants operating in the EU and UK.
Authenticates many low-risk transactions without an explicit customer-facing challenge, preserving checkout conversion.
Gives merchants a defined, bank-controlled verification step for new subscription signups and billing information changes, the moments most exposed to card testing and fraud.
Lets merchants verify an existing account code or billing info ID for SCA flows tied to reactivating or resuming a subscription, including through Recurly.js when a gateway requires it, so customers don't have to re-enter their card just to satisfy re-authentication.
Recurly spans multiple gateways, with gateway-specific options including Stripe, Adyen, Braintree, Cybersource, and Chase Orbital, with gateway-specific configuration options for how aggressively to apply 3DS to a given transaction.
Frequently asked questions
Does 3DS apply to every payment on my account? No. 3DS applies to customer-initiated transactions, where the customer is actively in session, such as signing up or updating billing information. Scheduled subscription renewals are merchant-initiated and are handled differently.
Who decides whether a transaction requires a 3DS challenge? The card issuer, not the merchant or Recurly. The issuer evaluates the transaction and decides whether to request additional authentication.
Will 3DS work if I only integrate with the Recurly API? Not on its own. 3DS challenges require a frontend that can render them, such as Recurly.js, a hosted payment page, or Checkout. Payments created directly in the Recurly dashboard don't trigger 3DS.
Does enabling 3DS slow down checkout for every customer? Not necessarily. 3DS 2.x is designed so issuers can authenticate many transactions without a visible challenge, reserving explicit verification steps for transactions the issuer considers higher risk.
What happens if a customer's bank requires 3DS but I'm not set up to support it? The transaction is likely to fail. This is a common cause of unexpected declines for merchants in the EU and UK, since PSD2 gives issuers the ability to require SCA on qualifying transactions regardless of the merchant's own setup.
