Authentication required authentication_required
What this decline means
The bank wants the customer to verify themselves (3-D Secure or similar) before approving — a problem for subscription billing, which by definition runs while the customer is absent.
Why it happens on subscription renewals
- The issuer requires strong customer authentication for this charge — common under European SCA rules and spreading elsewhere.
- A risk threshold was crossed that converts an otherwise silent charge into a verify-first charge.
- Off-session exemptions for recurring charges (which normally bypass authentication) were not granted for this attempt.
The merchant playbook
- Recognize that plain retries mostly won't fix it — the bank isn't asking for another attempt; it's asking for the customer.
- Send the customer a link where they can complete verification or re-save their card (which typically performs authentication in the process). That re-anchored consent usually unlocks future off-session charges.
- Retry after the customer acts — the same charge that failed then clears.
- If many renewals fail with authentication codes at once, review how your billing flags recurring charges — correctly marked subscription charges qualify for off-session exemptions that skip this dance.
Should you retry?
Only after the customer completes verification. Before that, retries bounce off the same authentication wall; the customer-action link is the actual recovery tool.
Common questions
Why does a recurring charge suddenly require authentication?
Recurring charges usually run under off-session exemptions, but the issuer can demand authentication anyway — after risk flags, rule changes, or when the original mandate was never authenticated. The fix is one customer-present verification, which then covers future cycles.
Is this the same as the charge being declined?
Functionally the renewal failed, but nothing is wrong with the card or balance. It's a consent checkpoint — clear it once and billing typically returns to normal.
Related codes: fraud_suspected · do_not_honor · invalid_payment_method · or see the
full decline-code guide.
Where Moorly fits: Moorly reads the decline reason behind every failed renewal in your existing subscription app and applies the playbook above automatically — the right treatment per code, with a dollar figure on what each failure family costs your store. It starts read-only. Join the early-access list →
Moorly is an independent product by Velun Labs and is not affiliated with Shopify, Appstle Inc., or Seal Subscriptions s.r.o. Code names follow Shopify's public API documentation as of August 2026; bank behavior varies by issuer — always confirm against your own admin.