Dunning for a Small Subscription Business: What Stripe Retries on Its Own, Which Failed Payments a Person Should Chase, and a Slack Alert per Failure
Dunning is the work of collecting a recurring payment that failed: retrying the card, emailing the customer, and, when that does not work, a person getting in touch. At a small subscription business billing through Stripe, most of that runs on its own. The retries and emails happen quietly, nobody on the team sees them, and the first sign of trouble is a customer whose subscription has already been cancelled. This guide splits dunning into the part Stripe handles without you and the short list of failures a named person should own, and shows how to get each of those in front of that person in Slack the moment it happens.
The short version
- Turn on Stripe's automatic retries and its customer emails. They recover the failures that only need another attempt.
- Decide what happens when retries run out: cancel, mark unpaid, leave past due or pause.
- Name one person who owns three kinds of failure: hard declines, the final retry, and your largest accounts.
- Send every failed payment to a Slack channel that person reads, with the customer, the amount and a link.
- Check once a month how many failures recovered by themselves and how many needed the owner.
Why failed payments slip past a small team
A card payment can fail for many reasons: the card expired, the bank declined a charge it judged unusual, the account was short that day, or the card was reported lost. Stripe's resource on what subscription businesses need to know about dunning puts failed payments at 20 to 40 percent of total churn for subscription businesses. Those are customers who never decided to leave; their card stopped working.
Stripe's billing tools deal with much of this by themselves. According to Stripe's documentation on automatic payment retries, Smart Retries uses signals such as how many devices have used a card in recent hours and the best time of day to pay to pick when to try again, and the recommended default is 8 tries within 2 weeks. You can stretch the window to as long as 2 months, or switch to a custom schedule of up to three retries.
A small team still loses customers because Stripe works in the background, and its dashboard is somewhere a founder visits when they remember to. Two founders who sell dunning tools described the same gap on Hacker News: one built a tool after manually chasing customers whose payments failed on a gym software product, and another wrote that many founders rely on Stripe's default retry logic with little visibility into how many payments fail. Both are sellers describing their own experience, not measured studies, but they match what a team without a billing person looks like: the system retries, the emails go out, and nobody knows which customers are on their last attempt.
What Stripe retries, and what it cannot
Some failures recover with another attempt, and some never will.
Stripe's retry documentation lists the cases where it does not retry at all: no payment method on file, and a set of hard decline codes from the card issuer, including lost_card, stolen_card, incorrect_number, pickup_card and authentication_required. For those, the scheduled retries still tick over on the invoice, but a charge only goes through once the customer adds a new payment method.
Stripe cannot retry a hard decline such as a lost or stolen card, so those failures need a person to ask for a new card the same day instead of waiting out the retry schedule. A customer whose card was reported stolen will not be rescued by eight more attempts over two weeks. Each day of waiting brings the end of the window closer, and the automated emails read like every other billing notice. A short, personal message from someone at the company asking for an updated card is the step that recovers these.
The second decision is what happens after the last attempt. Stripe gives four options:
| Setting after the final retry | What happens to the subscription | When it suits a small team |
|---|---|---|
| Cancel the subscription | It becomes canceled | Low-priced plans where you would rather the customer sign up again |
| Mark the subscription as unpaid | It becomes unpaid; new invoices stay as drafts | You want to keep the record and stop charging while someone follows up |
| Leave the subscription past due | It stays past due and keeps generating invoices | Customers you expect to pay late, such as larger accounts on a relationship |
| Pause the subscription | It is paused; no new invoices until it resumes | Eligible subscriptions where you want a clean restart once a card is added |
Pick one on purpose. Otherwise the default you never looked at decides whether a larger customer silently drops off at the end of week two.
Which failed payments a person should chase
Most guides on dunning management are written for companies with a billing team or a customer success group. Baremetrics, which sells a dunning tool, recommends in its dunning management guide that an account manager reach out directly between days 5 and 7 of a failed payment for accounts of about $50,000 a year or more. It also estimates, from its own customers, that businesses lose about 9 percent of monthly recurring revenue to failed payments. Treat that figure as a vendor's number. A firm of twelve people does not have account managers, and few of its customers pay $50,000 a year.
On a small team the job is not to watch every failed payment but to own the few that automation cannot fix: hard declines, the final retry, and any account large enough that losing it would change your month. This is a recommendation, built from what Stripe can and cannot retry plus the Baremetrics idea of a size threshold scaled down to your own numbers.
Here is a decision table you can copy. The dollar threshold is an example; set your own.
| The failure | Who handles it | What they do |
|---|---|---|
| Ordinary decline, early in the retry schedule | Stripe | Retries and sends its emails. Nobody needs to act. |
| Hard decline (lost, stolen, wrong number, needs authentication) | The owner, same day | Writes to the customer personally and asks for a new card |
| Final retry reached, no new card | The owner, before the end of the window | Writes or calls; decides whether to extend, pause or let it lapse |
| Any failure on an account above your threshold (for example, your top 10 customers, or anything over $500 a month) | The owner, day one | A short personal note, whatever the decline type |
| Repeat failures from the same customer, month after month | The owner, once | Asks about a different payment method or annual billing |
Name one owner. In a team of eight that is usually the founder or whoever runs operations. When the job is shared, each person can assume another one wrote, and the hard declines wait.
What to write
Stripe's resource suggests giving every dunning message a human touch, even the automated ones, and offering more generous terms to high-value customers. For the personal note, three sentences are enough: the payment for the plan did not go through, here is a link to update the card, and reply if anything has changed on their side. Keep it friendly and leave out anything that reads like a collections letter.
Getting each failure in front of the owner in Slack
The decision table only works if the owner sees the failure when it happens. You can do this with webhooks and some code: Stripe sends an invoice.payment_failed event with an attempt_count showing how many tries have been made. A team without a developer has nobody to build and maintain that.
If your team works in Slack, the Kipwise agent can do it with your own Stripe connection. You connect Stripe once and mention the agent in your finance or ops channel:
> @Kipwise whenever a payment fails, tell me here.
From then on, each time a payment fails, the agent reads the record in Stripe first and posts it in that channel. You reply in the same thread to carry on. A made-up example of how that looks:
> Failed payment: Northwind Studio, $480, Growth plan, card ending 4242. [Open in Stripe] > > You: Is this a hard decline? Show their last three invoices. > > Agent: Lists the invoices with their status and a dashboard link for each. > > You: Draft a short note to their billing contact asking for an updated card.
With Stripe connected to the agent, it looks up customers, payments, invoices and subscriptions in the account you connected and links the dashboard page next to each figure. Refunds, invoices, coupons and subscription changes happen only when you explicitly ask for them. Cancelling, voiding or deleting is never done in Slack; it gives you the dashboard link instead. If the agent drafts an email in your Gmail, sending it waits for you to approve it on a card that shows the recipient, subject and preview.
The agent posts every failure, and the owner acts on the rows that need a person and lets Stripe handle the rest. You can add a second, scheduled check as well: a recurring job every Monday that lists subscriptions still past due, so nothing that failed late on a Friday goes unseen.
If the money you are chasing is invoices sent from Xero or QuickBooks rather than card payments in Stripe, that is a different job with its own steps; see how to chase overdue invoices in Slack.
When things go wrong
The alert fires, nobody acts. A channel full of alerts trains people to ignore it. Put failures in a channel the owner actually reads, and keep it to payment events only.
The customer updates the card, and retries do not pick it up. Stripe's retry documentation notes that retries use the payment method on the subscription first. If a customer adds a new card only to their customer record while the subscription has its own default, Stripe keeps retrying the old one. When a recovered customer still shows as failing, check which card the subscription uses.
Two people write to the same customer. This happens when ownership is shared. One owner, named in the channel description, avoids it.
A large customer hits the final retry over a holiday. If the setting after the final retry is "cancel", the subscription ends without anyone deciding. For accounts above your threshold, "leave past due" or "mark unpaid" gives you time to reach them.
The note goes to the wrong person. The billing contact in Stripe may be a finance inbox, not the person who chose your product. For a large account, copy the person you usually talk to.
How to tell it is working
Run this for a month, then check five things:
- How many payments failed, and how many recovered without anyone acting. That is Stripe's share.
- How many were hard declines, and how many of those got a new card after the owner wrote.
- Whether any subscription reached the end of the retry window without the owner seeing it first. The target is none.
- How long the owner took to act on a failure from an account above the threshold.
- Which customers failed more than once. They are candidates for a different payment method.
If the first number is high and the rest are small, your retry settings are doing their job and the owner's list stays short. If hard declines keep lapsing, the alert is reaching the wrong person or the wrong channel.
What to do next
Open your Stripe dashboard today and look at two settings: the retry schedule and what happens after the final retry. Then write down your threshold for a personal follow-up and the name of the person who owns it. If your team works in Slack and you want every failed payment posted where that person will see it, install the Kipwise agent, connect your Stripe account and ask it to tell you whenever a payment fails. It costs $10 per user per month with a minimum of three users; see Kipwise pricing for the trial.
