Use this process if your store already sends automated reminders for failed payments. If failures are rare or a person already reviews every exception, a support task queue is enough.
Step 1: Map the flow
List the full path from checkout to billing to CRM:
- the event that marks a payment as failed
- the system that sends the reminder
- the rule that stops the sequence
- the status labels for paid, refunded, canceled, and manual review
Most problems start when one system uses a different status name than the others.
Step 2: Put stop rules in place first
A failed-payment flow should stop when:
- payment succeeds
- the order is refunded
- the order is canceled
- manual review takes over
- a manual payment update is recorded
If queued messages keep going after any of those changes, fix that before changing the copy.
Step 3: Keep the cadence short
A simple schedule works for most stores:
- first retry after 30 to 60 minutes
- second reminder at 24 hours
- final reminder between day 3 and day 7
Three touches is a good baseline. Four should usually be the limit.
Step 4: Route messages by decline type
Not every failure needs the same follow-up.
- Card expired: point the customer toward a payment update.
- Temporary processor decline: allow a later retry.
- Fraud review or verification hold: send the case to a person.
- Manual payment update: stop the reminders right away.
If every decline gets the same message, support ends up cleaning up exceptions.
Step 5: Review logs on a schedule
Use a simple maintenance rhythm:
- first week: confirm the trigger fires and the stop rule works
- first month: review recoveries by decline reason, not only total sends
- weekly at low volume, or daily once failed payments reach about 20 per day: review logs and exceptions
- quarterly: refresh the copy and confirm gateway changes have not altered the event payload
- after any checkout, CRM, or payment gateway update: run the flow from start to stop
Step 6: Keep SMS optional
SMS can help, but it adds consent tracking, quiet hours, and another opt-out list. If those pieces are not already in order, email-only is easier to maintain.
Step 7: Know when a manual process is better
Pause the automation stack when:
- payments go through accounts payable instead of a customer card
- fraud review, address verification, or manual capture decides whether the order continues
- failed payments are rare enough that a weekly review covers them
- no one owns logs, suppression lists, or gateway alerts
In those cases, a manual reminder or support task queue is cleaner than a drip sequence.
Quick maintenance checklist
- One owner is assigned.
- Retry timing is documented.
- The flow stops on successful payment, refund, cancellation, and manual review.
- Decline reason codes are visible.
- Email and SMS opt-outs stay synced.
- Manual payment updates clear queued messages.
- Copy is reviewed after checkout or gateway changes.
- Weekly review is scheduled, or daily log checks are in place at about 20 failed payments per day.
- The sequence stays at three touches, or four at most.
Recommended Dunning Cadence & Recovery Matrix
| Stage | Decision before sending | Stop condition |
|---|---|---|
| Initial notice | Confirm that payment actually failed and the customer has a secure update route | Payment succeeds, the order is canceled, or the failure is resolved |
| Reminder | Check the processor’s retry plan and the customer’s previous messages | Payment succeeds or support takes ownership |
| Final service notice | Use the actual subscription terms, grace period, and cancellation policy | Account is resolved or the policy-defined end state is reached |
Set timings from the business’s terms and processor behavior. The same fixed hour or day sequence does not suit every store, one-time order, or subscription. Do not promise cancellation, suspension, or an automatic retry unless that action is configured and applicable.
FAQ
How often should failed-payment automation be checked?
Weekly is enough when failed payments stay light. Move to daily log checks once the store sees about 20 failed payments a day, or after any gateway, checkout, or CRM change.
How many follow-up messages should the flow send?
Three touches is a clean baseline. More messages usually mean more unsubscribe risk, more support replies, and more chances for a recovered payment to stay in the queue.
Should SMS be part of failed-payment follow-ups?
Only if consent tracking, quiet-hour controls, and opt-out sync are already working cleanly. Email alone keeps the setup simpler.
What usually breaks these automations?
Broken event mapping, stale tags after payment clears, and mismatched status updates between billing and CRM are the usual problems. Checkout redesigns and payment gateway changes can also break the flow quietly.
When should a store stop automating failed-payment follow-ups?
Stop when each failed order needs review, when accounts payable handles the payment, or when fraud and verification rules matter more than speed. A manual reminder or support task queue works better in those cases.