Most retry debugging starts in the wrong place. A renewal fails, the team inspects the retry schedule, the email cadence, the decline code — and never asks the prior question: was this charge permitted to exist at all?
Every recurring charge rides on a mandate: the customer's standing authorization for you to bill them again without their presence. That authorization has a scope, a reference, and in many payment methods a set of rules about amount, frequency, and how the charge must be flagged when it is submitted. When a retry fails with a code that reads like a bank's refusal to cooperate — authentication required, mandate-related, do-not-honor families — the problem is often not the card. It is the paperwork underneath the charge.
What a mandate actually specifies
For card payments, the mandate is largely implicit: the cardholder agreement plus the way the original transaction was flagged. That flagging matters more than most developers expect. A renewal submitted as a merchant-initiated transaction, correctly referencing the initial customer-initiated setup, sails through checks that will stop the identical charge submitted without that reference chain. When a platform migration, a processor change, or a vault import breaks the chain — the stored credential arrives without its original transaction reference — issuers increasingly treat the renewal as an out-of-scope charge and decline it, sometimes with codes that look deceptively like ordinary soft declines.
For direct-debit schemes, the mandate is explicit and literal: a signed authorization with a reference number, rules about advance notice before amounts change, and in schemes like SEPA a defined window and format for representing a failed debit. Present a debit outside the mandate's terms and the bank does not decline it the way a card network declines — it rejects or reverses it under the scheme rules, and repeated out-of-scope presentations can put the mandate itself, and your credibility with the scheme, at risk.
Three mandate failures that masquerade as dunning problems
The migrated vault. Cards imported from a previous processor without network transaction identifiers. First renewals fail at elevated rates; the fix is not more retries — retrying an out-of-scope charge just repeats the refusal — but re-establishing the reference chain or stepping the affected customers through a fresh, customer-initiated update that creates one.
The changed amount. A price increase billed under a mandate whose notice rules were never honored. Several schemes require advance notice of amount changes; skipping it converts loyal customers' renewals into disputes and reversals wearing decline-code clothing.
The lapsed authorization. Trials that converted under one authorization context and bill months later under another, or subscriptions paused so long that the original setup reference is stale in the issuer's eyes. The charge is legitimate; its provenance no longer proves it.
The operational rule
Segment your failure file by provenance before you segment it by decline code. Failures on charges with intact mandate chains belong to the retry system: timing, cadence, messaging. Failures where the chain is broken belong to a much shorter playbook — fix the reference, or ask the customer to re-authorize with a fresh checkout — and no amount of retry sophistication substitutes. For the fuller mechanics, how recurring payment mandates decide whether a retry is even allowed traces the card and direct-debit cases separately, with the failure signatures of each.
Dunning systems are built to answer "when should we try again, and what should we say?" The mandate layer asks the ruder question first: "were we allowed to try at all?" — and what Swipe Again does when a mandate blocks a retry starts exactly there, because a recovery program that cannot tell those two failure classes apart will spend its effort retrying charges that were never permitted to land.
Top comments (0)