A subscriber has been paying without incident for eight months. The card on file expires, or the issuing bank’s fraud model soft-declines an unremarkable renewal for no reason anyone can see from the outside. The billing system marks the invoice unpaid, and that’s normally where the chain of good intentions stops: a reminder email goes out on a fixed schedule, the customer doesn’t notice it because it reads like every other automated billing notice they’ve learned to ignore, and a few overdue reminders later the account is suspended.
The customer did not decide to cancel. They just didn’t notice the card had failed, and now they’re locked out and annoyed, and the business has lost revenue it was never trying to lose. This is involuntary churn, and dunning — the process of chasing a failed renewal back to a successful one — is the machinery meant to stop it. Most of the time that machinery runs, produces a recovery rate somewhere under half, and nobody looks closer because it appears to be working.
Why it happens
Three separate failures usually combine to produce that mediocre recovery rate.
- Soft declines get treated like hard declines. A soft decline — insufficient funds today, a temporary risk flag — is retryable and often succeeds a few days later. A hard decline — card reported lost, account closed — never will. A dunning schedule that retries both the same way wastes attempts on dead cards and gives up too early on the ones that would have recovered.
- Retry timing ignores how issuers actually behave. Retrying immediately after a decline usually fails again, because whatever caused it hasn’t changed in ten minutes. Retrying weeks later misses the window when a low balance recovers. Generic, evenly-spaced retry logic hits neither case well.
- The customer never sees the actual signal. An email titled “payment failed, please update your card” sent from a no-reply billing address looks identical to every other automated notice. The specific, urgent version — “your subscription ends in three days” — is often missing entirely or buried below the fold.
How to diagnose it
- Split recovered renewals from lost ones in your reporting. Most billing systems report total involuntary churn as one number. Few separate “recovered after a retry” from “never recovered,” and without that split you can’t tell whether the fault is the retry logic or the customer communication.
- Pull decline reason codes, not just pass or fail. If your integration doesn’t surface why a renewal failed, you can’t tell a soft decline from a hard one, and every fix downstream of that distinction is a guess.
- Check whether a retry is actually being attempted at all. Some gateway setups only ever support a customer-present first payment and silently never attempt the automatic renewal, which looks identical to “dunning isn’t working” from the outside — see why WHMCS recurring payments fail for the underlying mechanics.
- Time the first dunning email against the decline itself, not against a nightly batch job’s schedule. A day’s delay before anyone is told is a day the card could have been fixed.
How to fix it
- Branch the retry schedule on the decline reason. Retry soft declines on a schedule tuned to issuer behaviour, commonly a handful of attempts spread over one to two weeks. Treat hard declines as “needs a new card” immediately, skip the wasted retries, and go straight to asking for one.
- Give the customer an update path that doesn’t start from zero. A one-click “update your card” link that returns straight to a resumed subscription converts far better than “log in and find billing settings.”
- Escalate the message, not just the frequency. The first notice can be gentle. The one sent two days before suspension should say exactly that, in the subject line, not in paragraph three.
- Use account updater services where your processor offers them. Card networks push through updated expiry dates and reissued numbers for cards that were simply renewed, which recovers a meaningful share of “failures” that were never really declines — they were stale card data.
- Add a grace period before suspension, separate from the retry schedule. Cutting off access the moment the retries exhaust converts a recoverable late payment into a support ticket and, often, a chargeback.
Where PaymentHood fits
The dunning logic itself lives in your billing system — WHMCS, WooCommerce Subscriptions, or whatever runs your renewals. What PaymentHood is responsible for is making sure that system has something accurate to act on.
When a customer pays with a method that supports stored agreements, PaymentHood creates that agreement at the provider, so your billing system’s cron can actually attempt the merchant-initiated charge on the due date — rather than discovering too late that the original gateway only ever took a customer-present payment and could never retry at all. When a retry does fail, the decline reason is reported back through the standard callback your billing system already understands, so its own dunning rules can branch on a real soft-or-hard distinction instead of a blank “declined.”
Because PaymentHood is a payment orchestration platform connected to 30+ providers, a renewal that keeps failing at one provider isn’t automatically a dead card — it can be retried through a different provider without the customer re-entering anything, which separates “this card doesn’t work” from “this gateway doesn’t work” far earlier than most dunning schedules ever get to.
There’s no per-transaction fee from PaymentHood, so recovering a renewal through a retry or a provider switch doesn’t cost a platform cut on top of whatever your provider already charges. Free plugins connect this to WooCommerce and WHMCS alongside the other major carts and billing systems.
Create a free PaymentHood account, or browse the provider directory to see which providers support the stored agreements that recurring billing actually needs.