Stripe requires_action on Shopify Subscriptions: 3DS Fix for Merchants
When Stripe returns requires_action on a Shopify subscription renewal, the charge cannot complete without customer action. This happens when the card issuer demands 3D Secure authentication for an off-session payment. The root cause is usually that the initial subscription setup did not claim the MIT (Merchant-Initiated Transaction) exemption by setting setup_future_usage: off_session during the customer's first payment. Without this exemption, every renewal risks triggering a 3DS challenge the customer must complete. The Shopify errorCode is AUTHENTICATION_REQUIRED. Here is how to identify affected subscriptions and fix both old and new ones.
What does requires_action mean when a Shopify subscription charge fails?
requires_action is a PaymentIntent status returned by Stripe when the card issuer mandates 3D Secure authentication before completing the charge. For subscription renewals — which are off-session, meaning the customer is not present — this is a problem. The customer cannot complete 3DS without being redirected to an authentication page, which does not happen automatically during a background renewal.
In Shopify's subscription billing layer, requires_action surfaces as the errorCode AUTHENTICATION_REQUIRED on the SubscriptionBillingAttempt. The charge is blocked. Stripe fires the invoice.payment_action_required webhook event, which contains the PaymentIntent and a next_action.redirect_to_url that the customer must visit to complete authentication. Without merchant intervention, the subscription stays in a blocked state indefinitely.
What is the MIT exemption and how does it prevent 3DS failures on renewals?
The MIT (Merchant-Initiated Transaction) exemption allows subscription renewals to bypass 3DS challenges. To claim it, the merchant must set setup_future_usage: off_session on the PaymentIntent during the customer's initial checkout. This signals to Stripe and the card network that the customer consents to future off-session charges, and the issuer pre-authorizes the exemption.
Without setup_future_usage: off_session, each renewal is treated as a new, unvetted off-session charge. Issuers — especially European banks under SCA regulations — may require 3DS for any charge that was not explicitly pre-authorized. The MIT exemption is the correct technical fix for new subscriptions. For existing subscriptions that were set up without it, you must handle the AUTHENTICATION_REQUIRED errors individually until customers re-authenticate.
How does Recharge handle authentication_required errors on subscription charges?
Recharge does not automatically send the 3DS confirmation URL to the customer when PAYMENT_METHOD_REVOKED or AUTHENTICATION_REQUIRED errors occur. When Recharge receives the charge failure, it fires charge/failed webhook with the error detail. The merchant or subscription app is responsible for generating the 3DS confirmation URL and sending it to the customer.
This is a common gap for Recharge merchants. A subscription fails with AUTHENTICATION_REQUIRED, Recharge retries it on its dunning schedule, and each retry fails again because the underlying 3DS requirement has not been fulfilled. The dunning retries are wasted. The correct action is to detect AUTHENTICATION_REQUIRED errors immediately, skip retries, and send the customer the authentication URL.
How do you recover subscriptions stuck in requires_action state?
For each subscription with AUTHENTICATION_REQUIRED errorCode, retrieve the associated PaymentIntent from Stripe. The PaymentIntent contains next_action.redirect_to_url — send this URL to the customer via email with a clear subject line like 'Action required: complete your subscription payment.' Give the customer 48–72 hours to complete the 3DS challenge.
After the customer completes authentication, Stripe fires invoice.payment_succeeded (or payment_intent.succeeded for non-invoice flows). At this point, update the Recharge subscription state if it drifted, and create a new Shopify billing attempt if needed. Use AltorLab's scanner to identify all subscriptions currently stuck in AUTHENTICATION_REQUIRED state across your store — these are often invisible in standard Shopify reports.
Frequently asked questions
Why do Shopify subscription renewals suddenly require 3D Secure authentication?
Usually because the initial subscription setup did not use setup_future_usage: off_session, so no MIT exemption was claimed. European card issuers under SCA also increase 3DS requirements periodically. Renewals that previously worked without 3DS can start failing if the issuer tightens their authentication policy.
What is the difference between requires_action and card_declined in Stripe?
requires_action means the charge can complete once the customer authenticates — it is recoverable with customer action. card_declined means the issuer refused the charge outright — it is not recoverable without a new payment method or, for soft declines, a retry after a delay.
Can I avoid 3DS entirely for subscription renewals?
Not entirely, but you can minimize it by using setup_future_usage: off_session during initial checkout to claim the MIT exemption. This pre-authorizes future off-session charges. Some issuers will still require 3DS regardless, particularly for high-value transactions or newly issued cards.
Why doesn't Recharge automatically send the 3DS link to the customer?
Recharge's dunning system is designed for standard payment retries, not authentication challenges. AUTHENTICATION_REQUIRED requires a customer-present action, not a retry. Recharge does not parse the PaymentIntent next_action to extract the 3DS URL — merchants must build this notification flow themselves or use a monitoring tool.
How do I know which of my subscriptions are stuck waiting for authentication?
Query the Shopify Admin GraphQL API for subscriptionBillingAttempts with errorCode AUTHENTICATION_REQUIRED. Cross-reference with Stripe to find the corresponding PaymentIntent and extract the authentication URL for each affected customer. AltorLab automates this cross-stack lookup.