SCA and 3D Secure on subscription renewals: handling authentication_required

Most failed renewals are about money or cards: not enough funds, an expired card, a block at the bank. One kind is different. The card is fine and the money is there, but the bank wants the customer to confirm the payment. On Stripe, that shows up as the decline code authentication_required, or as an invoice waiting for customer action.

No amount of retrying fixes it. The customer has to come back and approve the payment. This guide explains why it happens, what Stripe does for you, and how to get the customer through it quickly. It is based on Stripe’s documentation and the EU rules behind it (sources accessed November 2026).

This is not legal advice. Payment regulation is complex; check your setup with Stripe and, where needed, a specialist.

Why renewals need authentication at all

Strong Customer Authentication in brief

Strong Customer Authentication (SCA) comes from the EU’s second Payment Services Directive (PSD2). It requires payers to authenticate electronic payments with two of three factors: something they know, something they have, something they are. For cards, the usual way to do this online is 3D Secure, where the bank shows a confirmation step (a code, an app approval, a fingerprint).

According to Stripe’s SCA guide and help center, SCA applies when both the business’s payment provider and the cardholder’s bank are in the European Economic Area. Stripe’s exemptions page also covers the UK and Switzerland. Payments where one side is outside the region (“one leg out”) are out of scope, though banks may still ask for authentication.

Recurring payments and merchant-initiated transactions

A subscription renewal happens when the customer is not there. The rules accommodate this:

• The EU’s technical standards, Commission Delegated Regulation (EU) 2018/389, require SCA when a payer creates, amends or first initiates a series of recurring transactions with the same amount and the same payee. Later payments in the series can be exempt (Article 14).
• Card payments that the merchant initiates under an agreement with the customer are treated as merchant-initiated transactions (MITs). Stripe’s exemptions page explains that the card should be authenticated when it is saved, and that you need the customer’s agreement (a mandate) to charge it later. Marking a payment as an MIT works much like requesting an exemption.

So, in principle, one authentication at signup covers future renewals.

Why it still fails

In practice, the issuing bank has the final say. It can decline an exemption or an MIT and ask for authentication anyway. Common situations include a change in amount (an upgrade, a price increase, usage charges), a card that was saved without authentication, or simply the bank’s own risk assessment. When that happens on an off-session renewal, nobody is there to complete 3D Secure, and the payment fails.

Stripe’s support article on authentication_required declines adds one edge case: issuers sometimes return authentication_required even on payments that already passed 3D Secure. In that case, the customer needs to contact their bank.

What Stripe does for subscriptions

If you use Stripe Billing, Stripe handles most of the mechanics:

• Renewals are marked as off-session automatically. Stripe’s on-session vs off-session article says this flag is set for you on Billing renewals.
• Saved cards become MITs. Per Stripe’s SCA readiness page, when a card is saved through the Payment Intents or Setup Intents APIs, later off-session payments are flagged as merchant-initiated.
• The invoice tells you when action is needed. Stripe sends the invoice.payment_action_required event when an invoice payment needs further customer action. Stripe’s subscription webhooks guide says your app must then notify the customer.
• The hosted invoice page handles 3D Secure. The hosted invoice page can run the authentication flow without extra work on your side.
• Stripe can send the email. In the customer emails settings, you can have Stripe send a link for customers to confirm payments when their bank requires it.

On retries, note that Stripe’s Smart Retries page lists authentication_required among the hard decline codes: Stripe will not retry it automatically without customer action.

The two ways it shows up

Signal	What it means	What to do
invoice.payment_action_required, PaymentIntent in requires_action	The bank wants 3D Secure for this payment	Send the customer the hosted invoice link (or your own page) to confirm
Decline code authentication_required on invoice.payment_failed	The issuer declined and asked for authentication	Same: bring the customer back on-session to confirm or re-enter the card

Stripe’s support article on off-session SCA failures notes that a failed off-session PaymentIntent can end up in requires_payment_method rather than requires_action. If you build your own confirmation page, handle both states: either confirm the existing payment method with 3D Secure, or collect a payment method again.

Getting the customer to confirm

The customer did nothing wrong, and they often do not know what “authentication” means. The message should be short, calm and specific.

What the email should say

• Subject: “Please confirm your [Product] payment”
• Why: “Your bank asks you to confirm this payment. This is a standard security check, not a problem with your card.”
• What: the amount, the plan, the date.
• How: one button, “Confirm payment”, leading straight to the confirmation page.
• When: “Your subscription stays active while you confirm. If we can’t confirm by [date], it will be paused.”

Avoid “your payment failed” in the subject. It is not quite true, and it makes customers think they need a new card.

Timing

Send the first message as soon as the event arrives. Unlike soft declines, waiting does not help: the bank will not change its mind on its own. A short follow-up after two or three days, then a final notice before the end of your grace period, is enough. Our dunning email templates include an authentication variant.

The confirmation page

• Works on mobile without logging in (a signed link).
• Shows the amount and the product before the bank step.
• Opens the bank’s 3D Secure step directly.
• Offers “use another card” as a fallback, for customers whose bank keeps refusing.
• Confirms success clearly, and stops all further emails on invoice.paid.

Reducing authentication failures

You cannot remove them entirely, because the bank decides. You can make them rarer.

1. Authenticate when the card is saved

Collect the card with a SetupIntent (or the first PaymentIntent) and setup_future_usage set for off-session use, so that the card is authenticated with the mandate in place. Stripe’s SetupIntents docs cover this. Stripe Checkout and the Payment Element do it for you on subscription signup.

2. Re-collect when you change the deal

Upgrades, price changes and new add-ons change the amount. Where possible, make the customer confirm the change while they are in your app, so any authentication happens on-session rather than at 3 a.m. on renewal day.

3. Be careful with free trials

If a trial starts without a charge, make sure the card is still saved through a SetupIntent with authentication. Otherwise the first real charge, after the trial, is the first time the bank sees the mandate. We cover trials in trial-to-paid conversion.

4. Handle India separately

India has its own recurring payment rules. Stripe’s India recurring payments page explains that cards need an e-mandate registered with additional factor authentication, that customers get a pre-debit notification at least 24 hours before each charge, and that recurring charges above INR 15,000 need authentication every time. If you have Indian customers, read that page; it works differently from SCA.

Measuring it

Track authentication separately from other failures. It behaves differently and has its own fix.

• Authentication requests per month, by card country.
• Confirmation rate: invoices with an authentication request that were paid within your grace period.
• Time to confirm: from the event to invoice.paid.
• Fallback rate: customers who confirmed by switching to a new card instead.

If the confirmation rate is low, look at the email first (subject, clarity, a single button), then at the page on mobile.

Checklist

• Cards are saved with off-session authentication at signup.
• invoice.payment_action_required and authentication_required both trigger a confirmation email.
• Stripe’s “confirm payment” emails are on, or your own emails replace them (not both).
• The confirmation page works on mobile without a password.
• Price changes and upgrades are confirmed on-session where possible.
• Emails stop as soon as the invoice is paid.
• Authentication is reported as its own category.
• Indian customers are handled under the e-mandate rules.

How NoChurn helps

NoChurn treats authentication requests as their own case. When a renewal needs confirmation, it skips useless retries and sends an AI-written recovery email, reviewed before sending and in the customer’s language, explaining that the bank wants a quick confirmation, with a link to confirm the payment and a hosted card update page as a fallback. Card data stays with Stripe.

It connects to Stripe in one click, or works by API with your own billing. Pricing depends only on MRR, never on recovered revenue. See failed payments and pricing.