How to Build a Payment Recovery and Dunning System for SaaS

Most SaaS founders obsess over voluntary churn. They run exit surveys, build retention loops, and offer discounts to keep users from canceling. But the bigger, more insidious problem is involuntary churn: customers who want to keep paying you but cannot because their payment method fails. Expired credit cards, insufficient funds, bank fraud filters, network timeouts. These mechanical failures account for 20 to 40% of all SaaS churn, and for many companies, they represent 5 to 10% of monthly recurring revenue walking out the door.

Think about what that means at scale. A SaaS company doing $500K in MRR loses $25K to $50K every single month to failed payments. That is $300K to $600K per year in revenue that customers intended to pay. Unlike voluntary churn, where you need to convince someone to stay, involuntary churn is a pure engineering problem. Build the right system and you recover 50 to 70% of that revenue automatically.

The system you need is called a dunning system, named after the centuries-old practice of "dunning" debtors for payment. In the SaaS context, dunning means the automated process of retrying failed payments, notifying customers, prompting card updates, and gracefully degrading service before eventual cancellation. Every serious SaaS company needs one, and most get it wrong by relying on Stripe's built-in Smart Retries alone. Stripe's defaults are a solid starting point, but they are generic. A custom dunning system tailored to your customer base will consistently outperform off-the-shelf retry logic.

The foundation of any dunning system is the retry scheduler. When a payment fails, you need to retry it at the optimal time to maximize the chance of success. Blindly retrying every 24 hours is lazy engineering and leaves money on the table. The best retry strategies account for failure reason codes, bank processing windows, and customer payment patterns.

Understanding Failure Codes

Stripe returns a decline code on every failed charge, and each code tells you something different about what went wrong and how to respond. Here are the codes that matter most:

• insufficient_funds: The customer's account is temporarily low. Retry in 2 to 3 days, ideally after a typical payday cycle (the 1st, 15th, or the following Monday). This is your highest-recovery failure type.
• card_declined (generic): The issuing bank rejected the charge for unspecified reasons. Retry in 24 hours, then again in 3 days. If it fails three times, pivot to customer notification.
• expired_card: Do not retry at all. The card will never work again. Immediately notify the customer to update their payment method. Every retry here is wasted and can trigger rate limits from Stripe.
• fraudulent: Do not retry. The bank flagged this as potential fraud. Contact the customer directly and ask them to authorize the charge with their bank or provide an alternative payment method.
• processing_error: A temporary glitch on the bank or network side. Retry in 1 to 2 hours. These usually resolve quickly.

Bank Processing Windows

Banks process transactions in batches, and retry timing relative to these batches matters. Charges submitted between 7:00 AM and 10:00 AM in the customer's local time zone have the highest approval rates. Why? The daily batch from the previous night has cleared, balances have settled, and fraud detection systems are freshest. Avoid retrying late at night or on weekends when many banks run with reduced processing capacity.

For US-based customers, the best retry windows align with payroll cycles. The 1st and 15th of each month see the highest account balances. If a payment fails on the 28th due to insufficient funds, scheduling the retry for the 1st or 2nd of the following month yields dramatically better results than retrying on the 29th.

Building the Retry Schedule

Here is the retry schedule we recommend for most SaaS products. This assumes a "soft decline" like insufficient funds or a generic decline:

• Retry 1: 24 hours after initial failure, morning in customer's time zone
• Retry 2: 3 days after initial failure, aligned with the next payday window
• Retry 3: 5 days after initial failure
• Retry 4: 7 days after initial failure (final automatic retry)

After four failed retries, stop charging the card. Continuing to hammer a failing card does not increase your recovery rate, and it can get your Stripe account flagged for excessive declines. At this point, the customer must take action. Your notification sequence (covered in the next section) should have already prompted them to update their payment method.

Retry logic alone recovers about 30 to 40% of failed payments. The rest require the customer to do something: update an expired card, add funds to their account, or contact their bank. Your notification sequence is the mechanism that drives that action. It needs to be clear, non-threatening, and progressively urgent.

Pre-Dunning: The Proactive Phase

The best dunning email is the one you never have to send. Pre-dunning notifications alert customers before their payment fails. If a credit card on file is expiring next month, send an email 30 days before expiration and another 7 days before. Include a direct link to your payment method update page. Stripe's customer.source.expiring webhook fires 30 days before a card expires, giving you the perfect trigger.

Pre-dunning recovers 10 to 15% of cards that would have otherwise failed. That is free revenue for minimal engineering effort. If you build nothing else from this article, build pre-dunning notifications.

Active Dunning: The Recovery Phase

When a payment actually fails, your active dunning sequence begins. Here is the cadence we use:

• Day 0 (immediate): Send a friendly, low-pressure email. Subject line: "Your payment did not go through." Tone: helpful, not alarming. Include a one-click link to update payment. Do not mention cancellation.
• Day 3: Second email, slightly more direct. Mention that their subscription is at risk if payment is not resolved. Include the same update link. Optionally, add an in-app banner that persists until payment is resolved.
• Day 5: Send an SMS if you have the customer's phone number. SMS open rates are 95%+ compared to 20% for email. Keep the message short: "Your [Product] subscription payment failed. Update your card here: [link]."
• Day 7: Third email. This is the "we do not want to lose you" message. Be direct about the consequences. "Your subscription will be paused in 3 days unless you update your payment method." Include a personal touch if possible.

Grace Period and Cancellation

After 7 days of active dunning, enter a grace period. The customer keeps limited access to your product (read-only mode, data export, but no new features) for 3 to 7 additional days. This creates urgency without punishing customers who are dealing with a legitimate banking issue.

On day 10 to 14, send the final notice: "Your subscription has been canceled due to non-payment. Your data will be preserved for 30 days. Click here to reactivate." Then actually cancel the Stripe subscription. The 30-day data preservation window is important because many customers will come back once they sort out their banking situation. Making reactivation painless converts a significant portion of these "lost" customers.

One more tip on messaging: never use the word "dunning" in customer-facing communications. It sounds like a collections agency. Use phrases like "payment update needed" or "billing issue." Your customers should feel like you are helping them, not chasing them for money.

The single most important element of your dunning system is making it absurdly easy for customers to update their payment method. Every extra click between your dunning email and a successful card update costs you recovered revenue. We have seen teams triple their recovery rate just by fixing their update flow.

Hosted Payment Update Pages

Stripe's Customer Portal provides a ready-made payment update experience. You generate a portal session with a single API call, and Stripe handles the card input form, validation, 3D Secure authentication, and PCI compliance. The URL is one-time-use and expires after a set duration, which is perfect for embedding in dunning emails.

For a faster experience, use Stripe Checkout in "setup" mode. Create a Checkout Session with mode: 'setup' and redirect the customer there. Once they enter a new card, Stripe automatically attaches it to the customer and sets it as the default payment method. You can then immediately retry the failed invoice programmatically.

In-App Prompts

Email is great, but customers who are actively using your product are the easiest to convert. Display a persistent, non-dismissible banner at the top of your app when a payment has failed. Something like: "Your payment failed on [date]. Please update your payment method to continue using [Product]." Include an inline button that opens a modal with Stripe Elements embedded for card input.

For mobile apps, use a full-screen interstitial that appears on launch when payment is past due. Do not let the user dismiss it without updating their card or explicitly choosing to cancel. This is aggressive, but it works. Mobile interstitials recover 20 to 30% of failed payments on their own because the user is already engaged and the friction to update is minimal.

Magic Links for Frictionless Updates

Generate a unique, time-limited token for each dunning notification. When the customer clicks the link in your email or SMS, they land on a pre-authenticated payment update page without needing to log in. Requiring a login to update a payment method is one of the biggest conversion killers in dunning. The customer might not remember their password, they might be on their phone, and every obstacle reduces the chance they complete the update. Magic links eliminate all of that friction.

Store the token in your database with the customer ID, invoice ID, and expiration timestamp. When the link is clicked, validate the token, load the customer's context, and present the payment form. After a successful update, automatically retry the outstanding invoice and redirect to a confirmation page.

Your dunning system is event-driven. Stripe tells you when something happens, and you react. Getting your webhook integration right is non-negotiable. A missed or mishandled webhook means a failed payment slips through the cracks and you lose a customer silently. If you are new to Stripe webhooks, our subscription billing guide covers the fundamentals.

Critical Webhook Events

These are the Stripe events your dunning system must handle:

• invoice.payment_failed: The primary trigger. Fires when an automatic subscription payment fails. Extract the failure code, customer ID, invoice ID, and attempt count from the payload. This event kicks off your entire dunning workflow.
• charge.failed: Fires for any failed charge, including one-off charges. Useful if your billing model includes metered or usage-based pricing components that bill outside the normal subscription cycle.
• invoice.payment_succeeded: Fires when a retry or manual payment succeeds. Use this to immediately cancel all pending dunning notifications, remove in-app banners, and reset the customer's subscription status to active.
• customer.subscription.updated: Watch for status changes to "past_due" or "unpaid." These status transitions should sync to your local database so your application can enforce access restrictions during the grace period.
• payment_method.attached: Fires when a customer adds a new payment method. If the customer has an outstanding failed invoice, automatically retry it.

Building the Retry Scheduler with BullMQ

You need a job queue to schedule retries and notifications at precise times. BullMQ (built on Redis) is the best option for Node.js applications. It supports delayed jobs, cron-like repeat schedules, and has excellent retry semantics built in.

When invoice.payment_failed fires, your webhook handler creates a series of delayed jobs in BullMQ: one for each retry attempt and one for each notification in your dunning sequence. Each job includes the customer ID, invoice ID, retry number, and failure code. The job processor fetches the latest invoice status from Stripe before executing (in case the customer already paid) and then either retries the charge or sends the notification.

If you prefer a serverless approach, Inngest is an excellent alternative. Inngest lets you define multi-step workflows as code, with built-in scheduling, retries, and observability. You define a function that triggers on your invoice.payment_failed event, and Inngest handles the timing and execution. The advantage over BullMQ is that you do not need to manage Redis infrastructure. The disadvantage is vendor lock-in and less control over execution timing.

Idempotency and Race Conditions

Stripe can send duplicate webhook events, and your retry jobs can overlap with Stripe's own Smart Retries. Every operation in your dunning system must be idempotent. Before retrying a payment, always fetch the invoice from Stripe and check its status. If it is already "paid," skip the retry and cancel remaining dunning jobs for that invoice. Use database-level locks or Redis distributed locks when updating dunning state to prevent race conditions between concurrent webhook handlers.

A dunning system without analytics is just a cron job with email templates. You need to measure everything so you can optimize over time. The difference between a mediocre dunning system and a great one is often 20 to 30 percentage points of recovery rate, and that gap is closed through data-driven iteration.

Key Metrics to Track

• Recovery rate: The percentage of failed payments that are eventually recovered, either through automatic retries or customer-initiated updates. Track this overall and broken down by failure code. Aim for 50 to 70% overall recovery.
• Time to recovery: How many days between the initial failure and successful payment. Shorter is better. If your average time to recovery is over 5 days, your retry timing or notification cadence needs work.
• Revenue saved: The total dollar amount recovered through your dunning system. This is the number your CEO cares about. Calculate it monthly and compare it against what you would have lost without dunning.
• Notification conversion rate: For each email, SMS, and in-app prompt, track how many resulted in a payment method update or successful payment. This tells you which channels and messages are working.
• Ultimate churn rate: The percentage of customers who enter dunning and ultimately cancel. This is the inverse of your recovery rate, and it shows the ceiling you are working against.

A/B Testing Dunning Messages

Your dunning emails are marketing, whether you think of them that way or not. Test everything: subject lines, body copy, CTA button text, sender name, and send time. We have seen subject line changes alone improve open rates by 40%.

Start with these high-impact tests:

• Urgency vs. empathy: Test "Action required: payment failed" against "We are here to help with your billing." Urgency drives more immediate action, but empathy builds more trust. The winner varies by audience.
• Personal sender vs. brand sender: Emails from "Nate at [Product]" consistently outperform emails from "[Product] Billing." People respond to people.
• Plain text vs. branded HTML: Plain text emails feel personal and often outperform polished marketing templates in dunning contexts. The customer should feel like a real person noticed the problem.
• CTA wording: "Update payment method" vs. "Keep your account active" vs. "Fix in 30 seconds." Specificity and low perceived effort usually win.

Run each test for at least 200 failed payments per variant before drawing conclusions. Dunning volumes are typically low compared to marketing campaigns, so tests take longer to reach statistical significance. Use a simple chi-squared test or a Bayesian approach to evaluate results.

Building the Analytics Dashboard

Store every dunning event (failure, retry attempt, notification sent, notification opened, payment method updated, recovered, canceled) with timestamps in a dedicated analytics table. Build a dashboard that shows daily recovery rate trends, revenue saved this month versus last month, and a breakdown of where in the funnel customers are dropping off. If most recoveries happen on retry 1, your retry timing is solid. If most recoveries happen after email 3, your early notifications need work. The data tells the story.

The basics of dunning are straightforward: retry, notify, update, recover. But production dunning systems encounter edge cases that can break your workflow or, worse, create legal and compliance issues. Here is what you need to handle before going live.

Disputed Charges and Chargebacks

If a customer disputes a charge during the dunning period, stop all retries and notifications immediately. Retrying a disputed charge can escalate the dispute and result in additional chargeback fees. Listen for the charge.dispute.created webhook event and add the customer to a "do not retry" list. Your dunning system should check this list before every retry attempt. Resolve the dispute through Stripe's dispute management flow before resuming any billing activity.

Expired Cards vs. Lost or Stolen Cards

Stripe's Account Updater service automatically updates card numbers and expiration dates when a bank issues a replacement card. This works for about 60% of expired cards in the US. For the remaining 40% (and for lost or stolen cards, which are not eligible for Account Updater), you must rely on customer notification. Segment your dunning notifications based on whether Account Updater has a chance of resolving the issue. If the decline code is expired_card and Account Updater has not kicked in within 48 hours, escalate the notification urgency.

Insufficient Funds with Debit Cards

Debit card declines for insufficient funds behave differently than credit card declines. Credit cards have a credit limit that can fluctuate, but debit cards are tied directly to a bank balance. If a debit card fails for insufficient funds, retry timing aligned with payroll cycles is even more critical. Track whether the stored payment method is a debit card (Stripe provides this in the payment method metadata) and adjust your retry schedule accordingly. Retry debit cards on the 1st, 15th, or the Monday after the failure for the best results.

PCI Compliance

If you are using Stripe Elements or Stripe Checkout for your payment update flows (and you should be), your PCI compliance burden is minimal. You qualify for SAQ A, the simplest self-assessment questionnaire. Never store raw card numbers, CVVs, or full card details anywhere in your system. Your dunning database should only store Stripe payment method IDs, last four digits (for display purposes), and expiration dates. If you are building custom payment forms that touch raw card data, you need SAQ D compliance, which involves a full security audit. Avoid this unless you have a very specific reason.

Rate Limits and Stripe Account Health

Stripe monitors your account's decline rate. If too many of your charges are declined, Stripe may flag your account for review. This is especially relevant for dunning systems that aggressively retry failed payments. Keep your overall decline rate below 1% of total charges by being smart about which failures you retry. Never retry expired_card, fraudulent, or do_not_honor declines. Focus retries on insufficient_funds and processing_error codes where success is likely.

Multi-Currency and International Considerations

If your SaaS platform development serves international customers, your dunning system needs to account for time zones (retry during business hours in the customer's locale), currency-specific processing windows, and localized notification templates. A dunning email in English is not helpful for a customer in Japan. At minimum, support localized subject lines and CTAs. Services like Resend or Postmark support template localization that makes this manageable without building a full i18n pipeline for your transactional emails.

Putting It All Together

A production-grade dunning system is not a weekend project, but it does not need to take months either. Start with the highest-impact components: pre-dunning notifications for expiring cards, a four-step retry schedule based on failure codes, a three-email notification sequence with magic links to a Stripe-hosted update page, and basic recovery analytics. This foundation will recover 40 to 50% of failed payments. Then iterate: add SMS notifications, build the in-app prompt, implement A/B testing on your email templates, and refine your retry timing based on your actual recovery data. Each improvement compounds. Teams that invest in dunning consistently find it to be the highest-ROI retention feature they build.

If you are building a SaaS product and losing revenue to failed payments, we can help you design and implement a dunning system that fits your stack and customer base. Book a free strategy call and we will walk through your current billing setup, identify the quick wins, and map out a recovery system that pays for itself in the first month.