Resources

Authentication Required: SCA Declines & Subscriptions

An authentication required decline is not really a refusal to pay. It is the issuer saying the charge might be legitimate, but it will not approve it until the cardholder proves they are present and consenting. For a one-off checkout, that is a minor detour: the customer completes a challenge in their banking app or with a one-time code and the payment goes through. For a subscription renewal, it is a trap. The renewal is designed to run while the customer is doing something else, so there is nobody present to complete the challenge, and a perfectly willing subscriber lapses because a step-up was demanded at the wrong moment.

What authentication required actually means

When a card payment is submitted, the issuer can approve it, decline it, or ask for stronger proof that the cardholder authorised it. That third outcome is the authentication required family, sometimes returned as a soft decline with an instruction to authenticate. The payment has not failed for lack of money or because the card is dead. It has stalled for lack of presence.

This distinction matters because the recovery action is completely different from other declines. An insufficient-funds failure needs time. An expired card needs new details. An authentication required failure needs the customer, in person, completing a step the billing system cannot complete on their behalf. Retrying the same charge in the same way will usually produce the same answer. Our reference on Stripe decline codes explained places this family alongside the other major decline categories so you can route each one correctly.

Why subscriptions trigger it: off-session charges

Most renewals are off-session charges. The cardholder was present when they first subscribed, agreed to recurring billing, and stored a payment method for future use. Every renewal after that is initiated by the merchant, not by the customer sitting at a checkout. Economists and regulators call these merchant-initiated transactions, and card systems treat them differently from customer-initiated ones precisely because the cardholder is absent.

Problems start when that chain of consent is weak or broken:

• The first payment was not set up as a recurring agreement. If the initial charge looks like a standalone purchase rather than the start of a subscription, later renewals have no clear mandate to stand on, and issuers are more likely to demand authentication.
• The stored credential changed. A replaced card, a new device, or a payment method added outside the original checkout flow can weaken the link between the first authorisation and the renewal.
• The renewal looks different from the pattern. A changed amount, a long gap since the last charge, or a first renewal after a trial can make an otherwise routine charge look unfamiliar to issuer risk systems.
• The issuer or region requires stronger checks. In markets where Strong Customer Authentication applies, issuers are expected to verify the cardholder more rigorously for electronic payments, with specific treatment for recurring and off-session transactions.

SCA on recurring payments, at concept level

Strong Customer Authentication, or SCA, is the framework used in the European Economic Area and the United Kingdom under payment services regulation. In plain terms, for many electronic payments the payer must authenticate using elements from different categories, such as something they know, something they have, or something they are. The familiar version is the banking app approval or one-time code a customer sees at checkout.

Recurring subscriptions were considered when these rules were designed, because a system that required a customer to authenticate every weekly or monthly renewal in person would break the subscription model. The concept-level picture is this:

• The agreement is authenticated at setup. The customer authenticates when they start the subscription and agree to the recurring terms. That first, attended step establishes the mandate.
• Later renewals under that mandate are treated as merchant-initiated. When a renewal properly references the original agreement, it can be processed as an off-session charge under that mandate rather than as a brand new unattended payment with no history.
• Exemption and out-of-scope concepts exist, but they are conditional. Recurring transactions, low-risk payments, and certain other categories can be treated differently depending on the circumstances, the issuer, and how the payment is presented. None of them is a blanket guarantee that authentication will never be requested.
• The issuer still makes the final call. Even a correctly presented renewal can receive a step-up request. Issuers retain discretion, and their risk systems weigh signals the merchant never sees.

The operator takeaway is narrow and practical: set subscriptions up properly at signup, keep the mandate chain intact, and do not assume a renewal that worked last month is immune this month. Cross-border subscriptions add another layer here, because the issuer, the merchant, and the customer may sit under different regimes — see our guide to cross-border payment failures for how geography changes issuer behaviour.

The step-up recovery path

When a renewal does return authentication required, stop thinking about retries and start thinking about a hosted step-up. The sequence that works looks like this:

1. Stop blind retrying. Do not fire the same off-session charge again hoping for a different answer. Repeated identical attempts add noise, not information, and they will not manufacture the cardholder presence the issuer asked for.
2. Contact the customer fast, in your brand. Send a branded email, and SMS in the sequence, that says plainly what happened: the bank needs the customer to confirm the payment. Vague wording like payment failed invites the customer to check their balance, find money there, and conclude your message is wrong.
3. Send them to a secure hosted page. The customer opens the link, completes the authentication step with their issuer, and, where needed, confirms or updates the payment method for future renewals. This is the one action only they can perform, so the page should ask for nothing else.
4. Retry promptly after authentication. Once the customer has completed the step-up, reattempt the charge while that fresh authentication is attached to the payment journey, rather than waiting for a generic schedule to reach it days later.
5. Protect access and goodwill in the meantime. A customer who is mid-step-up is not a non-payer. Grace handling, clear status messaging, and a pause option where your policy allows it keep a willing subscriber from churning over a regulatory detour.

Notice what this path is not: it is not a longer retry schedule. Decline-aware recovery treats authentication required as its own route. In Swipe Again, failures are read by decline code on arrival, smart retries run up to 6 attempts over ~16 days for declines where timing helps, hard declines are never retried, and authentication-style failures are routed to customer action instead of being hammered with repeat attempts.

Prevention at signup beats recovery at renewal

The cheapest authentication problem is the one that never happens. Operators can reduce how often renewals get stepped up by tightening the attended moment they fully control: signup.

• Authenticate the first charge properly. Let the customer complete any challenge at checkout without friction shortcuts. That completed authentication is the foundation later renewals stand on.
• Make the recurring terms unmistakable. Amount, frequency, and the fact that the card will be charged on an ongoing basis should be clear before the customer confirms. A clean mandate is both a compliance asset and a dispute defence.
• Keep billing details consistent. Recognisable descriptors, consistent amounts within the agreed terms, and advance notice of price changes or trial conversions all make renewals look like what they are: expected charges under an existing agreement.
• Handle card changes inside the flow. When a customer updates a card mid-subscription, treat that moment as a fresh attended opportunity to establish clean credentials for future off-session charges.

None of this eliminates step-ups. Issuers will still ask sometimes, and some customers will still ignore the request until the subscription lapses. That is why involuntary churn remains so large in aggregate: according to Recurly research, 20–40% of subscriber churn is involuntary. Authentication failures are one of the quieter contributors, precisely because the customer never decided to leave.

Staying inside the compliance lines

Authentication and dunning touch regulated ground: how you store credentials, how you present recurring terms, what your emails promise, and how long you keep retrying and messaging. Before you redesign a step-up flow, run it against a structured review such as our dunning compliance checklist, and check the flow with your payment provider documentation for your markets. This article describes concepts for operators; it is not legal advice, and regional requirements differ in ways that matter.

Two discipline points are worth stating plainly. First, never try to work around authentication: no splitting charges, re-presenting them misleadingly, or coaching customers to disable protections. Apart from the compliance risk, workarounds corrode the mandate that makes your renewals process cleanly. Second, keep records of consent and authentication at setup. If a charge is ever disputed, the mandate you established at signup is your evidence.

The bottom line

Authentication required declines are presence problems, not payment problems. The card is often good, the funds are often there, and the customer usually wants the subscription to continue. What is missing is the cardholder, in the moment, confirming the charge. Set subscriptions up with a properly authenticated mandate, route these failures straight to a fast, branded step-up request instead of a retry schedule, and complete the charge promptly once the customer responds. Do that, and a regulatory safeguard stops being a silent churn channel.

Frequently asked questions

Is authentication required a soft or hard decline?

It is generally treated as a soft decline, because the payment can succeed once the cardholder completes authentication. It is not soft in the usual retry sense, though: repeating the same off-session charge without the customer step will typically return the same result, so it needs customer action rather than timing.

Why did a renewal get flagged when the first payment went through fine?

The first payment was attended: the customer was present and could authenticate. Renewals are off-session and merchant-initiated, so they rely on the mandate established at signup. A replaced card, a changed amount, a long gap, or an issuer policy change can all weaken that chain and trigger a step-up later.

What is SCA and does it apply to subscriptions?

Strong Customer Authentication is the authentication framework applied to electronic payments in the European Economic Area and the United Kingdom. Subscriptions are handled through the concept of an authenticated agreement at setup, with subsequent renewals processed as merchant-initiated transactions under that mandate, although issuers can still request authentication on a given renewal.

Should I keep retrying an authentication required decline?

No. The missing ingredient is the cardholder, not time. Pause the automatic retry logic for that failure, send the customer a clear branded request with a secure link to complete authentication, and reattempt the charge promptly once they have done so.

How does Swipe Again handle these failures?

Swipe Again reads each failure by decline code and routes it accordingly. Authentication-style failures go to customer outreach with branded email and SMS and a secure card-update and authentication page, rather than into repeated blind retries. Smart retries, up to 6 attempts over about 16 days, are reserved for declines where timing can help, and hard declines are never retried.