Failed payments are quiet revenue leaks. A card expires, a bank blocks a charge, or a customer hits a spending limit, and a healthy subscription starts to wobble.
When I set up Baremetrics dunning emails, I don’t treat them like debt collection. I treat them like a fast, polite rescue system that gives good customers an easy path back.
That mindset matters, because the setup only works when the message feels human.
Why failed payments need their own recovery system
I don’t lump failed payments in with normal churn. They’re different. A cancellation is a choice. A failed payment is often a billing hiccup wearing a churn mask.
That matters for SaaS teams, because the fix is usually simple. Expired cards, temporary bank declines, and low funds are common. If I respond fast, I can often recover the account before the customer even thinks about leaving.
Baremetrics handles this through Recover, its payment recovery add-on. Based on current public information, it works with Stripe, Braintree, and Recurly, retries charges on a smart schedule, and sends customizable email sequences after a payment fails. Baremetrics also shares its own dunning best practices and a broader dunning management guide, both of which line up with how I approach failed-payment churn.
Most failed payments are not lost customers. They’re customers who need one clear nudge at the right time.
I also like that recovery data sits close to the rest of my subscription metrics. When I compare recovered revenue against broader SaaS churn metrics and Baremetrics dashboard, I get a cleaner picture of what’s truly broken.
One note on cost: in the current public material I checked, Recover pricing wasn’t listed. So if pricing matters for planning, I confirm it in-account or with the Baremetrics team before I roll it out.
How I turn on automated dunning in Baremetrics
I keep the setup simple, because dunning falls apart when the workflow gets messy.
First, I connect the billing system I already use. Baremetrics currently supports Stripe, Braintree, and Recurly for recovery workflows, so the failed-payment data can flow in right away.
Next, I activate Recover and set the retry logic. I don’t make wild guesses here. I match retries to the kind of failures I see most. Temporary bank declines may recover on their own, while expired cards need a customer action.
Then I build the email cadence. Current public sources point to sequences of five to six emails across about 30 days. I like that range because it gives me room to start gently, then raise urgency without sounding harsh.
Finally, I turn on pre-dunning. Baremetrics publicly highlights reminders 30 days and 7 days before card expiry. That’s one of the easiest wins in the whole system, because it stops some failed charges before they happen.
After setup, I test the path like a customer would. If the update-payment flow feels long or confusing, I fix that before I blame the emails.
The dunning email sequence I trust
Good dunning emails feel less like a warning siren and more like a helpful tap on the shoulder. The customer should know what happened, what to do next, and how long they have.
I write short emails with one job per message. Baremetrics has a helpful guide to writing dunning emails, and I sometimes compare my copy against outside examples like these dunning email templates that recover revenue.
The copy I use as a starting point
- Within 24 hours: “Your payment didn’t go through. Please update your card here so your account stays active.”
- A few days later: “We still couldn’t process your payment. This usually takes less than a minute to fix.”
- Final warning before service impact: “Your subscription is about to pause because billing still needs attention. Update payment details now to avoid interruption.”
I tweak the tone based on the failure reason. For an expired card, I keep it practical. For insufficient funds, I avoid blame and remind the customer the system will retry. For a hard decline, I offer support in case the bank needs to clear the charge.
I also keep three rules in mind. First, I put the action link near the top. Second, I never bury the problem in soft language. Third, I don’t over-explain. A dunning email is not a newsletter.
Pre-dunning follows the same logic. A simple note before a card expires can save a string of reminders later. It’s like fixing a loose roof tile before the storm hits.
What I watch after the sequence goes live
Once the emails are running, I stop guessing and watch the numbers. Baremetrics says Recover can recapture 40 to 60 percent of failed payments on average, and that smart retries can recover many charges invisibly. I treat those as useful benchmarks, not promises, because results depend on plan price, customer type, and failure mix.
The first metric I check is recovered MRR. After that, I look at which email drove the update. If lots of customers open but few act, my call to action may be weak. If late emails do all the work, my early messages may be too soft.
I also compare involuntary churn before and after rollout. When that number drops, I know the sequence is doing real work, not just generating clicks.
A failed payment shouldn’t end a good subscription. With Baremetrics, I can set the recovery process once, tune the tone, and let the system do the patient follow-up.
If your failed charges still pile up in a support queue, this is the moment to fix that leak. Start with one clean sequence, then measure what comes back.
