Failed Payment Response Checklist: First 24 Hours

A failed payment discovered a week late is usually a lost subscriber. The same failure caught in the first hour, read correctly, and answered with the right first moves is often a saved account. This checklist is the first 24 hours, hour by hour: what to check, what to send, what to retry, and what to never do — written for operators running dunning by hand and for teams auditing whether their automation actually does these things. Keep the decline code cheat sheet open beside it; the decline code is what routes every step below.

Work the list in order, per failure or per batch. If you are setting up a permanent process rather than fighting today's fires, start from the dunning launch checklist instead, and use this page as the daily runbook it produces. For the wider picture of what happens after a charge fails, see subscription payment failed: what next.

First, sort every failure into its family

One rule decides the whole checklist: treat decline families differently from the first minute. Across 5.4M failed payments, insufficient funds is the largest decline category at 40.6% (Churnkey analysis of Stripe data) — so most of your list will be timing problems, not refusals. Sort each failure before you act:

• Soft declines — insufficient funds, generic issuer declines, temporary holds. The card is probably fine; timing and retries are the fix.
• Card problems — expired, replaced, or reported lost. Retries are pointless until the subscriber updates the card; the update ask is the fix.
• Hard declines — do-not-honor and fraud-related responses where the issuer has closed the door. Never retry these. One clear update request is the whole play.
• Configuration errors — wrong amounts, currency or formatting faults on your side. These are your bug, not the subscriber's; fix the cause before any message goes out.

The first hour

• ☐ Confirm the failures are real. Check your processor status and your own recent changes first. An outage, a key rotation, or a pricing change can manufacture a batch of "failures" that no subscriber caused.
• ☐ Record each failure properly. Subscriber, amount, time, and the exact decline code, in the place your team actually reviews. A failure without a decline code is a guess waiting to happen.
• ☐ Sort the batch into the four families above. Ten minutes of sorting prevents the day's worst errors — most wasted retries come from unsorted lists.
• ☐ Fire the first smart retry for soft declines only. For a generic soft decline, a same-day retry can make sense; for insufficient funds, schedule toward money arriving — paydays and the start of the month — rather than hammering today.
• ☐ Send the first dunning email within the hour. Branded, from a recognisable address, stating the amount, what happened in plain words, and carrying one secure card-update link. Assume an accident; the first message's job is to be noticed, not to warn.
• ☐ Verify access handling matches your policy. Know — do not assume — whether this subscriber keeps access during the grace period, and make sure the email's wording matches the reality.

Hours 2 to 6

• ☐ Check the update link like a subscriber. Open the email on a phone, tap the link, and confirm the update page loads, shows your branding, and works. A broken update page silently converts fixable failures into cancellations.
• ☐ Add the SMS touch if you have consent. One short text, brand identified, same update link. Text carries urgency email cannot; spend it on day one, not five times in week one.
• ☐ Schedule the retry ladder for the soft declines. Space the remaining attempts over days, aligned to decline type, with a hard stop at your sequence limit. Write the dates down — an unplanned ladder becomes either silence or spam.
• ☐ Send the card-problem group their specific ask. Expired and replaced cards get a message that names the problem plainly — "the card we have has expired" — because a generic "payment failed" note does not tell them what to do.
• ☐ Handle hard declines once, correctly. No retries. One clear message that a new payment method is required, with the update link, and a defined date when the subscription will end without one.
• ☐ Fix any configuration errors at the root. Correct the cause, re-run the affected charges once, and send those subscribers an honest note that the fault was yours. Billing people for your error without saying so costs trust you will not get back.
• ☐ Flag high-value accounts for a human. Whatever "high-value" means in your business, a personal email or call from a person — not the automation — is proportionate for the accounts at the top of the list.

End of day: hours 6 to 24

• ☐ Review what recovered and record why. Update link click, retry success, or subscriber reply — the mechanism matters, because tomorrow's decisions about cadence and copy depend on knowing which lever worked.
• ☐ Confirm no subscriber got contradictory messages. Check for overlaps: an email promising a grace period while access was cut, or a "final notice" sent on day one. Fix contradictions before day two's sends.
• ☐ Set the day 3 and day 7 touches now. A mid-sequence reminder and a firmer message, each with the same update link. Writing them at the end of day one means they exist even when day three gets busy.
• ☐ Log the day in your recovery tracking. Failures, families, actions taken, recoveries so far. This log is how you learn whether your process improves — and the habits that keep failure volume falling are covered in how to reduce failed payments.
• ☐ Hand over anything unresolved. If a colleague or tomorrow-you picks this up, leave the state of each family in one sentence each. Checklists fail at handovers more often than at any single step.

The never-do list

• Never retry a hard decline. The issuer has answered definitively. Retrying wastes attempts, can flag your account with the processor, and will not change the answer. The only route is a new payment method from the subscriber.
• Never send a second charge within the same hour "just to check." Rapid repeated attempts look like abuse to issuers, annoy subscribers watching their banking app, and burn the goodwill your messages need.
• Never threaten. No collections language, no legal implications, no invented consequences for a subscriber whose card hiccuped. State only what will actually happen: retries on stated dates, access ending on a stated date.
• Never hide the amount or the reason. "A problem with your payment" without the amount forces the subscriber to investigate before they can fix — and most will not.
• Never keep dunning a recovered account. The moment a payment clears, every pending message and retry stops. Check your automation actually does this; it is the single most common dunning complaint.
• Never ask for card details by email or text. The secure update page is the only collection point, every time, with no exceptions for helpfulness.

If you are auditing automation instead

Run this checklist against your tooling, item by item, with last night's failures as the test data. Pull ten failed payments at random and trace each one: Was it sorted by decline family? Did the first email land within the hour, branded, with a working link? Were retries spaced and capped — and did hard declines receive none? Did everything stop on recovery? Every "no" is a specific configuration fix, not a platform verdict, and most tools fail this audit on message timing and stop-on-recovery rather than on anything exotic. Trace monthly; processors, templates, and staff change, and yesterday's correct setup drifts.

The bottom line

Sort first, act within the hour, retry soft declines on a spaced ladder, ask card problems for an update, leave hard declines alone, and stop everything the moment a payment clears. Do those six things in the first 24 hours and the remaining days of the sequence mostly run themselves. If you would rather the whole sequence ran automatically, that is the work Swipe Again does across Stripe, Recharge, Seal Subscriptions, Skio, Loop Subscriptions, Chargebee, Recurly, Braintree, and Paddle — decline-code-aware retries of up to 6 attempts over about 16 days, hard declines never retried, branded emails and SMS, and a 90-day backfill of your existing failed payments when you connect. The checklist stays useful either way: it is the standard to audit any automation against.

Frequently asked questions

How quickly should I respond to a failed payment?

Within the first hour for the first email and the first correctly chosen action. The decline code should be read and the failure sorted into its family on the same day it happens. Speed matters most at the start, because the subscriber still remembers the subscription, the charge looks familiar on their statement, and a fix takes one click instead of an investigation.

Should I retry a failed payment on the same day?

Sometimes — it depends on the decline. A generic soft decline can justify a same-day retry, but insufficient funds usually calls for waiting until money is likely to have arrived, such as a payday. Hard declines should never be retried on any day. The decline code, not the calendar, makes this decision.

What is the first thing to check before sending any dunning message?

That the failure is real and not your own fault. Check processor status, recent key or pricing changes, and configuration errors first. Messaging subscribers about a failure your side caused — without owning it — damages trust, and retrying a misconfigured charge just repeats the error.

How many messages should go out in the first 24 hours?

One email and, where you have consent, one short SMS carrying the same update link. More than that in a single day reads as panic and trains subscribers to ignore the sequence. Save the remaining touches for the spaced days that follow, when a reminder carries new information instead of repetition.

What should I do differently for high-value accounts?

Add a human. For accounts at the top of your value range, a personal email or call from a named person — alongside, not instead of, the standard sequence — is proportionate and often decisive, because a person can solve the awkward cases automation cannot, like a replaced company card or an accounts-payable contact who needs the request routed differently.