Recovery Rate

50–70%

Soft Decline

Stripe Decline Code · Glossary

authentication_required

Recoverable·50–70%·Updated May 2026

What It Means

What authentication_required actually means.

authentication_required fires when the issuing bank or card network requires the cardholder to complete additional identity verification — typically 3D Secure (3DS) — before the transaction can be authorized. Unlike most decline codes that represent a final decision, authentication_required is a redirect signal, not a rejection — the bank is willing to approve the transaction, but only after the customer completes an authentication challenge. It is one of the most recoverable decline codes in the taxonomy because the underlying card is valid, the account is funded, and the only obstacle is completing a verification step.

Not sure if this code is recoverable for your specific situation? Use the Stripe Failure Lookup →

Why It Happens

The root causes.

1SCA / PSD2 mandate in EU and UK — Strong Customer Authentication regulations require explicit cardholder verification for online transactions — issuers in Europe are legally required to demand 3DS authentication for e-commerce and subscription charges, and return authentication_required when a transaction arrives without it
2RBI mandate in India — The Reserve Bank of India mandates Additional Factor Authentication (AFA) for card transactions — Indian issuers consistently return authentication_required on charges that don't pass through a 3DS flow, particularly on recurring MIT charges
3MIT (Merchant-Initiated Transaction) rejected by issuer — A recurring subscription charge sent as an MIT without prior CIT authentication — or with a stale authentication reference — is rejected by some issuers who require fresh cardholder verification before approving any recurring billing arrangement
4Issuer risk-scoring the transaction — The bank's fraud engine flagged this specific transaction as elevated risk and escalated from a silent approval to a required authentication challenge — common on first recurring charges, large amounts, or charges after a period of inactivity
5Mastercard issuer decline post-authentication — Some Mastercard issuers decline already-authenticated payments with authentication_required — a known issuer-specific behavior where the bank overrides a passed 3DS authentication and demands additional verification
63DS not passed on checkout — stale or missing setup intent — The customer completed checkout without a 3DS challenge being triggered (or it was skipped), and the bank is now demanding it retroactively on the first recurring charge

What NOT to Do

Common mistakes that make it worse.

✕ Don't treat it as a hard decline and abandon the payment

authentication_required is explicitly a recoverable, action-required signal — not a final refusal. The bank is willing to authorize the transaction — it just requires the customer to authenticate first. Treating it as a final hard decline and routing it to a payment method switch email discards a highly recoverable payment unnecessarily.

✕ Don't retry silently without triggering a customer authentication flow

Silent background retries — the correct first response for soft declines like try_again_later — are entirely wrong for authentication_required. A silent retry fires the same charge with the same authentication gap and gets the same decline every time. The only valid retry for this code is one that brings the customer back to complete a 3DS challenge.

✕ Don't skip the 3DS integration audit before building customer outreach

A significant portion of authentication_required failures in EU, UK, and Indian markets are caused by a broken or incomplete 3DS integration on your Stripe implementation — particularly for recurring MIT charges. Sending customer emails before auditing your 3DS setup means you're pushing customers through authentication flows that may still be broken, generating frustration without resolution.

Retry Timing

Optimal retry schedule.

authentication_required is a customer-authentication-required retry code — all retries must be paired with a 3DS challenge flow, not a silent background attempt.

Recovery Benchmark

What good looks like.

Metric	Result
Overall recovery rate	50–70%
Recovery via 3DS authentication link (customer completes)	60–75% of those who click
Recovery via 3DS integration fix (developer-side)	80–90% of the tech-issue subset
Recovery via alternate payment method	+12–18% additional lift
Recovery with silent retry (no 3DS)	~5–8%
authentication_required as % of EU/IN failed payments	25–40% in regulated markets

A 65%+ overall recovery rate is achievable with a correctly implemented authentication link workflow and a fast Day 0 email. The most impactful split is identifying the 3DS integration bug subset — teams that audit their 3DS setup and fix broken recurring payment flows recover the entire affected cohort in one engineering push, often recovering 80–90% of that specific failure group instantly.

At Scale

How to handle it at scale.

Automated

✓Webhook trigger: invoice.payment_failed → check failure_code === 'authentication_required' → immediately run two checks: (1) customer geography — EU/UK/IN? (2) is this an MIT charge on a subscription with a prior CIT authentication reference?
✓3DS audit gate (internal): Before any customer outreach, check whether your Stripe integration is correctly passing setup_future_usage: 'off_session' on the initial CIT, and whether the mandate parameter is correctly attached to MIT recurring charges — a missing or malformed mandate is a developer bug, not a customer issue
✓Authentication link email — Day 0: Generate a Stripe-hosted payment link (stripe.paymentLinks.create) with payment_method_types: ['card'] and after_completion redirect — send to customer with subject: "Complete your payment verification — 1 quick step needed" — body explains a one-time security verification is needed to process their subscription
✓Zero silent retries: Add authentication_required to your no-silent-retry list — every retry must be paired with customer authentication; a non-authenticated retry is guaranteed to fail
✓Post-authentication immediate retry: Configure a webhook on payment_intent.succeeded (triggered when customer completes 3DS) → immediately apply the new payment method to their subscription and process the outstanding invoice → do not wait for the next billing cycle
✓Alternate method parallel track — Day 3: Surface PayPal, bank transfer, and UPI prominently alongside the authentication link from Day 3 — customers in markets with mandatory 3DS who cannot complete authentication (lost phone, no OTP access) need a non-card fallback
✓Recurring MIT setup fix: After any successful CIT re-authentication, ensure the new PaymentMethod is saved with the correct setup_future_usage: 'off_session' parameter and that the subscription's default payment method is updated — this prevents the same authentication_required failure on the next billing cycle

Manual Escalation

→3DS integration bug identified: Assign to engineering immediately — a broken 3DS or mandate implementation affects every customer in the impacted geography systematically; one developer fix recovers the entire cohort; this is the highest-leverage manual action for this code
→High-ACV accounts in EU/IN: Personal outreach within 2 hours — "Hi [name], your bank requires a quick one-time verification to process your subscription payment. Here's a secure link that takes about 30 seconds to complete." — high-value customers appreciate human-sent authentication links over automated emails
→Customers who can't complete OTP/3DS: For customers who report difficulty completing 3DS (phone number changed, no OTP access), offer a direct ACH bank transfer or PayPal as a permanent payment method — these options bypass 3DS entirely and are permanently immune to authentication_required failures
→Mastercard post-authentication declines: For the Mastercard-specific variant where 3DS passed but authentication_required is still returned, escalate directly to Stripe support — this is an issuer-specific behavior that Stripe can advise on; it may require a different charge approach or a network-specific exemption

FAQs

Frequently asked questions.

What does the Stripe authentication_required decline code mean?

authentication_required means the issuing bank requires the cardholder to complete additional verification — typically 3D Secure — before authorizing the transaction. It is not a final rejection; the bank is willing to approve the payment once authentication is completed. The card is valid, the account may be funded, and recovery is highly achievable by sending the customer a 3DS authentication link.

What are the most common causes of an authentication_required error in Stripe?

Common causes include SCA and PSD2 mandates requiring 3DS authentication in EU and UK markets, RBI Additional Factor Authentication mandates in India, recurring MIT charges rejected by issuers requiring fresh CIT authentication, the bank's fraud engine escalating to a required authentication challenge, and broken or incomplete 3DS integration on your Stripe checkout or subscription setup.

How do I recover a payment after a Stripe authentication_required decline?

Send the customer a Stripe-hosted payment link that triggers a fresh Customer-Initiated Transaction with a 3DS challenge. Once the customer completes authentication, immediately charge the outstanding invoice against the newly authenticated payment method. After successful re-authentication, update the subscription's default payment method with correct setup_future_usage parameters to prevent the same failure on the next billing cycle.

Can authentication_required be caused by a Stripe integration issue?

Yes, and this is one of the most impactful root causes. If your Stripe integration doesn't correctly pass setup_future_usage: 'off_session' on the initial CIT, or if the mandate parameter is missing on MIT recurring charges, issuers in EU, UK, and Indian markets will systematically return authentication_required on every recurring charge. Fixing this integration bug recovers the entire affected customer cohort instantly.

What is the recovery rate for Stripe authentication_required failures?

Overall recovery rates are 50–70%. Customers who complete the 3DS authentication link convert at 60–75%. Developer-side 3DS integration fixes recover 80–90% of the technical subset immediately. Alternate payment methods like PayPal and bank transfer add 12–18% additional lift for customers who cannot complete 3DS authentication.

What to do next

You are here

authentication_required

Decline code reference

↓→

Check recoverability

Stripe Failure Lookup

See what's recoverable — and what isn't →

↓→

Then

Automate recovery for every decline code →

Before you retry

Most authentication_required failures are retried on the wrong schedule — which recovers the payment about 30% of the time. The other 70% leaves permanently. See what this code is actually costing at your MRR before deciding how to handle it.

See what authentication_required costs me →

Stop leaving revenue on the table

authentication_required is recoverable. Most teams don't have the retry logic to prove it.

Recurflux handles code-specific retry scheduling, adaptive dunning, and dispute intelligence across all 30 Stripe decline codes. Connect in under 5 minutes.

See what's leaking →All 30 decline codes →