What is 3D Secure Authentication? Definition & Explanation

Quick Definition

3D Secure (3DS) is an authentication protocol that adds a verification step to online card payments. When triggered, the customer is asked to confirm their identity, typically through a one-time code sent to their phone, a banking app push notification, or biometric authentication.

The "3D" refers to the three domains involved: the merchant, the card network, and the issuing bank. You will recognize it by its brand names: Visa Secure, Mastercard Identity Check, and American Express SafeKey.

For subscription businesses, 3DS introduces a tension: it reduces fraud and chargebacks, but it adds friction that can increase payment failures, especially on recurring charges where the customer is not actively present at checkout.

Why this matters for SaaS: In Europe, 3DS is not optional. Strong Customer Authentication (SCA) regulations require it. Globally, card networks are increasingly pushing 3DS adoption. If you sell internationally, this affects your payment failure rate.

How 3D Secure Works

The authentication flow

1. Customer initiates payment (or a recurring charge fires).
2. The gateway sends the transaction to the card network with a 3DS request.
3. The issuing bank evaluates risk. If authentication is required, the customer is prompted.
4. Customer authenticates. They enter an OTP, approve a push notification, or use biometrics.
5. Authentication result returns. Approved, failed, or attempted.
6. Payment proceeds (if authenticated) or fails (if not).

3DS1 vs 3DS2

3DS2 is a significant improvement. It allows "frictionless" authentication where the bank evaluates risk using device data and transaction history, and approves low-risk transactions without asking the customer to do anything. The customer never sees a prompt. Only high-risk transactions trigger the interactive challenge.

3DS and Subscription Payments

Here is where 3DS gets complicated for recurring billing.

The first payment

On the initial subscription charge, 3DS works like any other online transaction. The customer is present, can complete the authentication challenge, and the payment goes through (or does not).

Subsequent recurring payments

After the first authenticated payment, recurring charges can qualify for a Merchant Initiated Transaction (MIT) exemption. This means subsequent charges do not require the customer to authenticate again, as long as:

• The initial transaction was properly authenticated with 3DS
• The subscription was set up with a setup_intent or payment_intent that stored the authentication
• The recurring amount and interval match what was originally agreed

Stripe handles this automatically when you use their Subscription and SetupIntent APIs correctly.

When 3DS breaks recurring billing

Problems arise when:

The issuing bank requires re-authentication. Some banks, especially European ones under SCA, periodically require the customer to re-authenticate even on recurring charges. The bank sends back a soft_decline with a code like authentication_required.

The original 3DS was not properly stored. If the initial payment was not set up correctly (e.g., missing the off_session parameter in Stripe), subsequent charges cannot claim the MIT exemption.

The amount changes. Upgrades, downgrades, or prorated charges that differ from the original amount may trigger a new 3DS challenge, and the customer is not there to complete it.

Card replacement. When a customer gets a new card, the 3DS mandate associated with the old card does not transfer. The next charge on the new card may require fresh authentication.

The Impact on Failed Payments

3DS adds a category of failed payments that did not exist before: authentication failures.

Failure rates with 3DS

The recurring re-authentication scenario is the most damaging. The charge fails because the bank wants the customer to verify, but the customer is not online at that moment. Without intervention, this payment stays failed until someone reaches the customer.

Authentication failure vs payment failure

It is important to distinguish between these two:

The authentication_required soft decline is a unique challenge for dunning. A standard "update your payment method" email is not quite right because the card itself may be fine. What the customer needs to do is authenticate the charge.

SCA and European Compliance

What is SCA?

Strong Customer Authentication is a European regulation (part of PSD2) that requires two-factor authentication for most online payments within the European Economic Area. It took effect in 2020-2021 across EU member states.

SCA requirements for subscriptions

The SCA impact in numbers

When SCA was first enforced, European subscription businesses saw:

• 5-10% increase in first-payment failure rates
• 2-5% increase in recurring payment failures (from re-auth requests)
• Gradual improvement as 3DS2 adoption increased and frictionless flows matured

Businesses that adapted their checkout and dunning flows for SCA recovered to pre-regulation failure rates within 6-12 months. Those that did not saw permanent increases in involuntary churn.

Handling 3DS Failures in Your Dunning Sequence

Standard dunning messages ("Your payment failed, update your card") do not work for 3DS authentication failures. The card is fine. The bank just needs the customer to verify.

Adapted dunning for 3DS failures

Email subject: "Quick verification needed for your [Product] subscription"

Email body approach:

• Explain that their bank is requesting verification (not that their card failed)
• Provide a link to a Stripe-hosted page where they can complete 3DS
• Keep the tone reassuring: this is a security feature, not a problem with their account

Stripe's approach

Stripe provides a hosted page (invoice.hosted_invoice_url) where customers can complete 3DS authentication for failed recurring payments. Including this link in your dunning messages is the most direct path to recovery.

In Stripe's API, when a recurring charge receives an authentication_required decline, the PaymentIntent moves to requires_action status. The next_action field contains the URL or data needed to complete 3DS.

Sequence timing for 3DS failures

3DS authentication failures often resolve faster than typical payment failures because the customer does not need to find a new card. They just need to tap "approve" in their banking app.

Best Practices for 3DS in Subscription Billing

1. Set up initial payments correctly

Use Stripe's setup_intent with usage: 'off_session' when storing cards. This ensures the initial 3DS authentication is properly recorded for future MIT-exempted charges.

2. Distinguish 3DS failures in your dunning logic

Do not send a "card declined" message when the issue is authentication_required. Customize your messaging based on the decline reason.

3. Use Stripe's hosted invoice page

For 3DS re-authentication, Stripe's hosted page handles the entire 3DS flow. Link directly to it from your dunning emails instead of building your own.

4. Monitor 3DS failure rates by issuing bank

Some banks require re-authentication more aggressively than others. If you see spikes from specific banks, it can inform your retry and outreach timing.

5. Prepare for increasing 3DS adoption

Even if most of your customers are in the US today, card networks are pushing 3DS globally. Building 3DS-aware dunning now prevents problems later.

Key Takeaways

1. 3DS adds a verification step that reduces fraud but can increase payment failures, especially on recurring charges.
2. MIT exemptions allow most recurring charges to skip 3DS, but banks can still request re-authentication.
3. Authentication failures need different dunning messages than card declines. The card is fine; the bank needs verification.
4. SCA makes 3DS mandatory in Europe. If you sell to European customers, this is not optional.
5. Proper setup (off_session, SetupIntents) minimizes recurring 3DS friction for subsequent charges.

Recover 3DS Failures Automatically with Rekko

When a recurring charge fails due to 3DS authentication, Rekko detects the specific failure type and sends the right message:

• Decline-code-aware sequences that distinguish authentication failures from card declines
• Direct verification links in every email and SMS
• Multi-channel outreach to reach customers before the grace period ends
• Automated recovery tracking for 3DS-specific failure rates

Start recovering failed payments.