Failed Payments and Dunning for SaaS: Retries, Emails and Billing Edge Cases

How should I handle failed payments, payment retries, dunning and billing edge cases?

Let the billing provider retry automatically, tell the customer quickly and plainly, give them a hosted page to fix the card, and keep access for a grace period that matches the retry window. Make your application react to billing webhooks rather than polling, and write down what happens at the end of the window before the first customer ever fails a payment.

Why failed payments matter more than they look

A customer whose card fails did not decide to leave. Expired cards, a bank's fraud filter, insufficient funds on the renewal date or a card that now needs extra authentication all look the same in your revenue chart as a cancellation if nothing recovers them. This is usually called involuntary churn, and unlike voluntary churn it is mostly an engineering and operations problem, so it is one of the cheaper retention problems to fix. For the wider picture of retention, see our guide to SaaS metrics and churn.

Step 1: Configure automatic retries

Every mainstream subscription billing system can retry a failed renewal on a schedule. Using Stripe Billing as the example, Stripe recommends its Smart Retries feature, which chooses retry times using signals such as when a payment method is most likely to succeed; its documentation gives a recommended default of 8 tries within 2 weeks, with retry windows of 1 week, 2 weeks, 3 weeks, 1 month or 2 months. You can instead define a custom schedule of up to three retries at set day intervals.

Step 2: Write a dunning sequence people actually act on

Dunning is the sequence of messages that asks the customer to fix the payment. In our experience the wording matters less than three practical details: the email arrives from a recognisable sender, it says exactly what failed and what happens next, and it has one button to a hosted page where the card can be updated without logging in to anything else. A sequence we would start from:

For B2B accounts, send the messages to the billing contact and, where you have one, the account owner: the person who uses the product is often not the person whose card is on file. An in-app banner for admins is worth adding once you have more than a handful of customers.

Step 3: Decide what happens to access

Decide this before you launch, because it is a product decision as much as a technical one. Stripe, for example, lets you choose what a subscription does once retries are exhausted: cancel it, mark it unpaid, leave it past_due, or pause it where eligible. Whichever you pick, map each billing state to a clear level of access in your application:

• Active: full access.
• Past due (inside the retry window): full access plus a banner. Cutting access on day one punishes customers for their bank's mistake.
• Unpaid or paused (after the window): read-only access or a locked workspace, with data kept. Deleting data because a card expired is rarely what anyone wants, and may conflict with what your terms promise.
• Cancelled: follow your published data-retention policy, with an export option. See our guide to GDPR and SaaS legal basics for retention and deletion.

Step 4: Handle the webhooks properly

This is where most custom billing integrations go wrong. Your app should learn about payment state from the billing provider's webhooks and store it, rather than assuming a payment succeeded because the checkout page redirected. Stripe's webhook documentation sets out the rules that matter:

• Verify the signature on every event using the endpoint's signing secret and the raw request body; otherwise anyone can post a fake "paid" event to your endpoint.
• Expect duplicates. Stripe says an endpoint may receive the same event more than once; log processed event IDs and skip repeats.
• Do not rely on order. Stripe does not guarantee events arrive in the order they were created, so fetch the current subscription state from the API when an event arrives rather than applying events as a sequence of changes.
• Return a 2xx quickly and do the work in a background job. Stripe retries undelivered live-mode events for up to three days with exponential back-off, so a slow or failing endpoint causes repeated deliveries.
• Listen to the events you need, typically invoice.payment_failed, invoice.paid and customer.subscription.updated / deleted, rather than every event type.

Billing edge cases to test before launch

Measure it

Track three numbers each month: the share of renewal invoices that fail on the first attempt, the share of those recovered by retries and emails, and the revenue lost after the window closes. If recovery is low, look first at the emails (are they reaching the billing contact?) and the hosted update page (does it work on mobile?) before tuning retry timing.

When to build more than this

For an early SaaS, the billing provider's built-in retries, emails and hosted pages are usually enough, and building your own dunning engine is a distraction; see what not to build in a SaaS. Custom work starts to pay off when you invoice large B2B accounts by bank transfer, sell through resellers, need usage-based billing reconciled against your own metering, or run several billing providers in different regions.