Two renewals can fail for the same $29 on the same morning and need opposite handling. One is a card decline. You know in about two seconds: insufficient funds, do not honor, card expired. The answer is instant, even when it is unhelpful. The other is a bank debit through ACH. You submit it, the billing day passes, and for a while nothing has technically failed at all. The money simply has not arrived, and may still be taken back. Treating those two events with one retry calendar is how careful operators lose subscribers they did not need to lose.
The card timeline, in seconds
A card renewal is a conversation in real time. Your processor asks the issuer, the issuer answers, and the transaction is approved or declined with a code you can act on. A soft decline invites a later retry. A hard decline tells you the credential itself is dead and only a new card will help. Either way, the clock starts immediately. You can retry within hours if the reason is timing, send an update link the same day, and set a grace period that matches how long you are actually willing to wait for an answer you already have.
That speed has a cost. Card retries crowd easily. Fire three attempts in a day and you look desperate to the issuer's risk models, burn goodwill with the customer, and may make a later, better-timed attempt less likely to clear.
The bank debit timeline, in days
An ACH debit is not a conversation. It is a submission into a clearing system that moves in batches, on banking days, through institutions that report problems on their own schedules. A debit can appear settled and then return days later for insufficient funds. It can return because the account was closed, because the customer asked their bank to stop it, or because the account details never quite matched the person you thought you had. Weekends and holidays stretch the silence. A Monday holiday can turn an ordinary delay into nearly a week of believing a renewal succeeded.
That is the practical heart of why bank debit renewals fail differently: the failure often surfaces after the point where a card-based workflow would already have retried twice, emailed twice, and started counting down grace. If your system marks the subscription paid on submission, you may deliver service, close the ticket, and only learn about the return when the customer has mentally moved on.
What the delay changes
Retry timing. Do not schedule the next debit as if the first one answered. Wait until the return window you plan around has passed, or at least until your processor shows the debit as truly settled, before you present it again. Re-debiting into an empty account on day two is not persistence; it is a guess that creates fees.
Notices. A card customer can be told, honestly, 'your payment failed today.' A bank-debit customer in the silent window should hear something different, or nothing yet: 'we are processing your payment.' Send a failure notice too early and you may alarm someone whose debit clears. Send it only when the return arrives and you have compressed the remaining time to act.
Grace. Card grace can be short because the information is fast. Bank-debit grace has to absorb detection time before the customer even gets a fair chance to fix the problem. Measure grace from when you learned of the failure, not from the original billing date, or the customer pays for the banking system's delay with lost access.
The fix you ask for. A card decline usually asks for a new card. A returned debit may ask for corrected account details, a different payment method altogether, or explicit re-authorization after a stop payment. Sending a bank-debit customer a card-update link that assumes a card exists is a small, telling mistake.
A simple split that works
Run two playbooks, not one with exceptions taped to it. Keep a shared goal — a clear notice, a secure way to fix payment details, a defined end — and separate clocks underneath it. Label every failed renewal in your system by rail, return or decline reason, and the date you actually learned about it. That learning date, not the attempt date, should drive the first message, the first retry, and the grace deadline.
Once a week, look only at the slow failures. How many returns arrived more than three days after submission? How many customers had already been told they were paid up? Those two numbers tell you whether your process respects how bank debits really behave. That respect is part of Swipe Again's failed payment recovery work: building recovery around the failure you actually have, not the instant answer you wish every rail gave you.
Top comments (0)