CASE STUDY · SUBSCRIPTION & BILLING MANAGEMENT TECH
Automating dunning and recovery for a SaaS client's failed payments.
- 25%Unrecovered failed payments down from 25% to 12%
- 5 monthsRecovered revenue covered the project cost within 5 months
01 · PROJECT OVERVIEW
The client and the brief.
An anonymised SaaS company. Name withheld under confidentiality.
Retry logic, reminders and in-app prompts, wired into the billing system and the product.
- 1A quarter of failed payments were never recovered.
- 2The company had a single retry a few days after the failure, then a generic email.
- 3Customers with expired cards, bank declines and temporary limits all got the same treatment.
- 4Most of the lost accounts had not chosen to leave.
- 5Their payments had simply failed and nobody followed up properly.
02 · WHAT WENT WRONG
What went wrong, and how we fixed it.
Every engagement hits problems. These were the ones that mattered here, and what we changed so they did not come back.
- PROBLEM 01Early on, some customers received a reminder after they had already paid
A webhook arrived late and the reminder job read stale state. This was embarrassing and it generated support tickets. We made the send step check the live invoice status immediately before sending, added an idempotency key to each message, and put a short delay between the failure event and the first reminder.
- PROBLEM 02We also added a suppression list for accounts already in contact with support
- PROBLEM 03A second issue appeared with customers who paid by bank debit
Their failures took days to confirm, so the card schedule retried too early and sent reminders for payments that were still pending. We gave that method its own states and timing, and waited for the final status before any message. Recovery for that group improved and the complaints stopped.
- PROBLEM 04Recovery for that group improved and the complaints stopped
03 · THE PROCESS
How we ran it.
We ran this as a short, measured project.
- 01Step 1
Analysis: we grouped past failures by decline reason and looked at which ones had ever recovered.
- 02Step 2
Design: we agreed a retry schedule per reason, a message sequence and the rules for pausing access.
- 03Step 3
Build and test: we built the flows and tested them against recorded failure cases and the gateway's test cards.
- 04Step 4
Staged release: we rolled out to a slice of customers, compared it with a holdout group, then widened.
We met weekly to look at recovery by reason and by message. Marketing and support reviewed all copy.
04 · RESULTS
What changed.
Measured against the way the work ran before the engagement began.
- NOW 01
Failed payments are tracked as a metric alongside churn and reviewed monthly.
- NOW 02
Support sees the dunning state of an account on one screen.
- NOW 03
Message copy is tested the way product copy is tested.
- NOW 04
Expiring cards trigger a prompt before the next renewal, not after it fails.
- 25%
Unrecovered failed payments down from 25% to 12%
- 5 months
Recovered revenue covered the project cost within 5 months
05 · WHAT WE BUILT
How it works.
- Payment gateway webhooks fed an event queue.Each failure was classified as soft (try again later) or hard (needs a new card).
- Soft failures followed a retry schedule with spacing that avoided pay-day clusters and weekends where the data supported it.
- Hard failures skipped retries and went straight to a card update prompt.
- An in-app banner and a secure update link replaced the plain email.Customers could fix the card without logging in to a support ticket.
- A state machine tracked each invoice: failed, retrying, reminded, grace period, recovered or cancelled.
- Every send and retry was logged, so we could measure what actually recovered revenue.
- Controls
- Customers never lost access on the first failure. A grace period applied, and its length depended on plan size and payment history. Large accounts were routed to an account manager after the second failed attempt instead of receiving more automated emails. Each retry respected the gateway's rules on attempt counts, and a full log meant any customer complaint could be traced step by step.
06 · QUICK ANSWERS
The short version.
- What problem did the client have?
- A quarter of failed payments were never recovered. The company had a single retry a few days after the failure, then a generic email. Customers with expired cards, bank declines and temporary limits all got the same treatment. Most of the lost accounts had not chosen to leave. Their payments had simply failed and nobody followed up properly.
- What did Brandsmashers build?
- Retry logic, reminders and in-app prompts, wired into the billing system and the product.
- How was the work run?
- We ran this as a short, measured project.
- What were the results?
- Unrecovered failed payments down from 25% to 12%; recovered revenue covered the project cost within 5 months.
YOUR TURN
Have a similar requirement?
Tell us what is stuck. We will come back with a plan and matched, pre-vetted engineers.
