How Much Does It Cost to Build a Dunning Payment Recovery SaaS?

Dunning is the process of automatically recovering failed payments from subscribers. When a customer's credit card expires, hits its limit, or gets flagged by a fraud filter, the charge fails. Without dunning, that subscriber quietly disappears from your revenue. No cancellation request, no angry email, just a silent churn event that most SaaS companies do not even notice until they audit their MRR three months later.

The numbers are brutal. Failed payments cause 20 to 40 percent of all SaaS churn, a category known as involuntary churn. Across the industry, this translates to roughly 5 to 10 percent of total revenue lost annually. For a SaaS company doing $2 million in ARR, that is $100K to $200K walking out the door every year without anyone asking it to leave.

Dunning recovery platforms solve this with a combination of smart payment retry logic, multi-channel communication sequences (email, SMS, in-app banners), and self-service flows that let customers update their payment method without contacting support. The best systems recover 50 to 70 percent of failed payments automatically. That recovery rate is why dunning has become its own product category, with startups and agencies investing serious capital to build dedicated solutions.

If you are considering building a dunning SaaS, either as a standalone product or as a feature within a larger billing platform, you need to understand the true cost. This guide breaks down every component, from MVP to full product, with real numbers based on what we have seen building billing infrastructure at Kanopy.

Before you can estimate cost, you need to map the feature set. Dunning platforms share a common core regardless of market positioning.

Smart Retry Logic

This is the engine. When a payment fails, the system needs to decide when and how to retry the charge. Naive retry (just try again in 3 days) recovers maybe 20 percent. Smart retry analyzes the failure reason code from the payment processor, the customer's historical payment patterns, and the time of day to optimize retry timing. Stripe returns over 50 distinct decline codes, and each one calls for a different retry strategy. A card marked "insufficient funds" should be retried on payday. A card marked "card expired" should not be retried at all, because the customer needs to update their payment method first.

Building smart retry logic requires a scheduling system (BullMQ with Redis or a managed service like Inngest), a rules engine that maps decline codes to retry strategies, and enough data infrastructure to track retry outcomes and improve the model over time.

Multi-Channel Communication Sequences

When a payment fails, the customer needs to know about it and take action. A dunning platform sends a coordinated sequence of messages across email, SMS, and in-app notifications. The sequence typically runs 7 to 21 days and escalates in urgency. Day 1 might be a friendly email. Day 5, a follow-up with a direct link to update payment info. Day 10, an SMS. Day 14, a final warning before the account is paused or downgraded.

Each channel requires its own integration. Email needs a transactional provider like Resend, SendGrid, or Postmark. SMS needs Twilio or a similar service. In-app notifications need a real-time delivery mechanism (websockets or polling). The communication engine also needs template management, personalization (customer name, amount owed, plan details), and A/B testing so you can optimize subject lines, send times, and message copy.

Payment Method Update Flows

The customer needs a frictionless way to swap in a new card. This means a hosted or embedded payment update page that works on mobile, pre-fills existing info, and confirms the update with a real-time authorization check. Stripe makes this easier with the Customer Portal and the Setup Intents API, but you still need to build the surrounding UX: the landing page, the confirmation screen, the webhook handler that marks the account as recovered, and the logic that triggers an immediate retry after the payment method is updated.

Analytics and Reporting

Operators need to see what is working. A dunning dashboard should display recovery rate (payments recovered divided by payments failed), revenue recovered, average time to recovery, channel performance (which emails or SMS messages drive the most updates), and cohort analysis showing whether recovery rates are improving over time. This is also where you surface the data that justifies the platform's existence to customers: "We recovered $47,000 for you this month."

Billing Provider Integrations

A dunning SaaS is only useful if it connects to the customer's billing stack. At minimum, you need Stripe and Braintree integrations. Broader market coverage requires Paddle, Recurly, Chargebee, and potentially Adyen for enterprise customers. Each integration means mapping that provider's webhook events, subscription data model, and payment retry APIs to your internal system. This is one of the most time-consuming parts of the build.

An MVP dunning platform proves the concept and gets your first customers recovering revenue. Here is what it includes and what each component costs to build.

Single Billing Provider Integration (Stripe): $8,000 to $15,000

Start with Stripe because it dominates the SaaS billing market. You need webhook listeners for invoice.payment_failed, invoice.payment_succeeded, customer.subscription.updated, and related events. You need to map Stripe's decline codes to retry strategies and build the OAuth flow that lets customers connect their Stripe account to your platform. This is not trivial. Stripe's webhook delivery has edge cases around event ordering, idempotency, and retries that require careful handling. If you have built subscription billing implementation before, you know how many hidden complexities live in this layer.

Basic Retry Engine: $10,000 to $20,000

A job scheduler (BullMQ on Redis is the standard choice) that processes retry attempts based on configurable rules. For the MVP, you can start with a rule-based system: if the decline code is "insufficient_funds," retry on days 3, 7, and 14. If the decline code is "card_expired," skip retries and trigger the payment update flow immediately. You do not need ML-powered retry optimization at this stage. Simple rules based on Stripe's decline code documentation will recover the majority of recoverable payments.

Email Notification Sequence: $5,000 to $10,000

Three to five templated emails triggered at intervals after a failed payment. Integration with Resend or SendGrid for delivery. Basic personalization (customer name, company name, amount, plan). A hosted payment update link in every email. Skip SMS and in-app notifications for the MVP. Email alone drives 60 to 70 percent of payment method updates.

Payment Update Page: $5,000 to $12,000

A clean, mobile-responsive page where customers enter a new card. Built on Stripe Elements or the Stripe Customer Portal with custom branding. The page needs to handle the full flow: load customer context from a secure token in the URL, display what is owed, collect the new payment method, run a Setup Intent to validate the card, and trigger an immediate retry of the failed invoice.

Basic Dashboard: $8,000 to $15,000

A web dashboard where your customers (the SaaS operators using your dunning platform) can see failed payments, recovery status, and basic metrics. Recovery rate, revenue recovered, active dunning sequences. Built with Next.js and a charting library like Recharts or Tremor. Authentication with Clerk or Auth0. This does not need to be fancy at launch, but it needs to clearly show value.

Infrastructure and DevOps: $5,000 to $8,000

CI/CD pipeline, staging environment, basic monitoring (Sentry for errors, Axiom or Datadog for logs), and deployment configuration. For a dunning platform, reliability is non-negotiable. If your retry scheduler goes down for 6 hours, that is real money your customers are not recovering. Budget for redundancy and alerting from day one.

Timeline and Team

A focused team of two senior full-stack engineers and a designer can ship this MVP in 10 to 16 weeks. At agency rates of $150 to $200 per hour, that puts you in the $50,000 to $100,000 range. Freelancers might come in lower, but billing infrastructure demands precision, so do not optimize for the cheapest option here. Bugs in a dunning platform directly cost your customers money.

After validating your MVP with paying customers, the full product build adds the features that differentiate you from competitors and unlock enterprise deals.

Multiple Billing Provider Integrations: $30,000 to $60,000

Each new billing provider (Braintree, Paddle, Recurly, Chargebee, Adyen) costs $8,000 to $15,000 to integrate properly. The work is not just connecting to their API. You need to normalize their event models into your internal schema, handle provider-specific quirks (Paddle's subscription model is fundamentally different from Stripe's), and build the onboarding flow that walks customers through connecting their account. Supporting four to five providers is table stakes for a serious dunning product.

Machine Learning Retry Optimization: $20,000 to $45,000

This is where the magic happens. Instead of static retry rules, you train a model on historical payment outcomes to predict the optimal retry time for each failed payment. Features include: decline code, day of week, time of day, customer's payment history, card type (debit vs. credit), and the customer's billing country. Even a relatively simple gradient-boosted model can improve recovery rates by 10 to 20 percent over rule-based logic. You need a data pipeline to collect and process outcomes, a training workflow, and an inference service that the retry scheduler queries before each attempt.

SMS and In-App Channels: $15,000 to $25,000

Adding Twilio for SMS delivery, plus in-app notification banners or modals in your customers' products. The in-app channel requires either a JavaScript SDK that your customers embed or an API they call from their frontend. SMS adds a compliance layer: you need opt-in tracking, TCPA compliance, and unsubscribe handling. But SMS recovery rates are strong. A well-timed text message recovers payments that email alone misses.

Advanced Analytics and Reporting: $15,000 to $30,000

Cohort analysis, channel attribution, revenue impact forecasting, exportable reports, and a metrics API. Enterprise customers will want to pull dunning data into their BI tools. Build a clean REST or GraphQL API that exposes recovery metrics, and consider a webhook system that pushes events (payment recovered, account paused, payment method updated) to the customer's own systems.

A/B Testing Engine: $10,000 to $20,000

Let customers test different email subject lines, send times, message copy, and retry schedules against each other. This requires a randomization layer, statistical significance calculations, and a clear UI for creating and evaluating experiments. A/B testing is one of the features that separates a serious dunning product from a basic retry script.

Multi-Tenant Architecture and Scalability: $15,000 to $30,000

As you onboard more customers, you need proper data isolation, rate limiting per tenant, and a job scheduling system that handles thousands of concurrent retry sequences without degrading performance. For a deep dive on general platform costs, see our guide on SaaS development costs. The scheduling layer in particular needs careful engineering. BullMQ can handle significant throughput, but you need to shard queues, implement priority ordering (high-value invoices first), and build dead-letter handling for jobs that fail repeatedly.

Team and Timeline

The full build typically requires three to four engineers (two full-stack, one backend/data specialist, one frontend), a product designer, and a part-time product manager. Timeline: 5 to 9 months depending on the number of billing integrations and whether you are building the ML retry engine in-house or starting with a rule-based system and adding ML later. Most teams go the phased route, shipping rules first and layering in ML once they have enough payment outcome data to train on.

The right technology choices for a dunning platform prioritize reliability, real-time event processing, and integration flexibility. Here is the stack we would recommend for a new build in 2032.

Backend: Node.js with TypeScript

TypeScript gives you type safety across your webhook handlers, retry logic, and API layer. This matters more in billing infrastructure than in most other domains because a type error in a payment amount or currency code is a financial bug, not just a UI glitch. Use Fastify or Express for the API server. Build the webhook processing layer as a separate service so a spike in webhook traffic does not affect the customer-facing dashboard.

Job Scheduling: BullMQ with Redis

BullMQ is the industry standard for job scheduling in the Node.js ecosystem. It handles delayed jobs (schedule a retry for Tuesday at 9am EST), repeatable jobs (check for new failed payments every 5 minutes), and job prioritization. Redis serves as both the job store and the caching layer for frequently accessed data like customer subscription status and retry configuration. For managed alternatives, Inngest and Trigger.dev offer similar functionality with less operational overhead, but they add a per-execution cost that scales with volume.

Database: PostgreSQL

PostgreSQL stores customer data, integration credentials (encrypted), retry history, communication logs, and analytics aggregations. Use row-level security for multi-tenant data isolation. For the analytics layer, consider materialized views or a separate read replica to keep reporting queries from impacting the transactional database.

Email: Resend or SendGrid

Resend is the modern choice with excellent developer experience and React Email for template rendering. SendGrid has broader enterprise adoption and more robust deliverability tools. Both handle the transactional email volume a dunning platform generates without issue. Budget $50 to $500/month depending on volume.

Frontend: Next.js with React

The operator dashboard, payment update pages, and marketing site all live in a Next.js application. Server components reduce client-side JavaScript. API routes handle simple backend operations. Vercel deployment gives you global edge delivery for the payment update pages, which matters because a slow-loading payment page means lost recoveries.

Webhook Processing Architecture

This deserves its own callout because it is the heart of the system. Every billing provider sends webhooks when payments fail, succeed, or change status. Your webhook processing layer needs to: verify webhook signatures, parse and normalize events across providers, deduplicate events (providers sometimes send the same event multiple times), enqueue the appropriate action (start dunning sequence, update recovery status, trigger retry), and log everything for debugging and audit purposes. Use a message queue (SQS, Redis Streams, or BullMQ itself) between the webhook receiver and the processing logic. This decouples ingestion from processing and prevents webhook timeouts during traffic spikes. Your payment processor comparison will inform which webhooks you need to handle first.

Before you commit $50K or more to building a dunning platform, understand what already exists. The competitive landscape is crowded and growing.

Churnkey

Churnkey focuses on both voluntary and involuntary churn. Their payment recovery product includes smart retries, customizable email sequences, and a payment update modal you embed in your app. Pricing starts around $300/month and scales with recovered revenue (typically 3 to 5 percent of recovered MRR). They integrate primarily with Stripe and have been expanding to other providers.

Gravy

Gravy takes a hybrid approach, combining software automation with a human outreach team that contacts customers directly. They position themselves as a premium option for companies that want white-glove recovery. Their pricing is performance-based, typically 10 to 20 percent of recovered revenue. The human touch can recover payments that pure automation misses, but the higher take rate eats into your margins.

Butter Payments

Butter focuses entirely on the smart retry layer. They sit between your application and Stripe, optimizing retry timing using machine learning. No email sequences or communication features. Pricing is performance-based. Butter is a good option if you want to handle communication yourself and just need better retry logic.

Recurly

Recurly is a full subscription management platform with built-in dunning capabilities. Their revenue recovery tools include smart retries, email sequences, and account updater integration. If you are already using Recurly for billing, their dunning features are included in your subscription. The downside is vendor lock-in. Moving off Recurly is a major migration project.

When Building Makes Sense

Building your own dunning platform makes sense in a few specific scenarios. First, if you are building a dunning product to sell to other companies, you obviously need to build it yourself. Second, if you have unique requirements that existing tools do not support, like custom retry logic based on proprietary data signals or deep integration with a vertical-specific billing system. Third, if the take rate from existing providers is too expensive at your scale. A company doing $50 million in ARR that loses 7 percent to failed payments stands to recover $1.75 million. Paying 5 percent of that to a dunning provider costs $87,500/year, which might justify the investment in a custom solution.

When Buying Makes Sense

For most SaaS companies under $10 million ARR, buying a dunning solution is the smarter play. You get immediate recovery improvement without months of engineering investment. Churnkey or Butter can be integrated in a day or two. The ROI is measurable within the first billing cycle. Save your engineering resources for your core product and buy the dunning layer until the economics justify building it.

Building the software is only part of the total investment. Here is what it costs to run a dunning platform after launch.

Infrastructure: $300 to $2,000/month

Vercel or AWS for hosting, managed PostgreSQL ($50 to $200/month on Neon or Supabase, $200 to $800 on RDS), Redis ($30 to $150/month on Upstash or Redis Cloud), and monitoring tools (Sentry at $26/month, Datadog or Axiom at $50 to $300/month). The cost scales with the number of customers and retry volume, but stays manageable for the first 100 to 200 customers.

Communication Services: $200 to $1,500/month

Resend or SendGrid for email ($20 to $200/month at moderate volume), Twilio for SMS ($0.0079 per message, adds up with scale), and optionally a dedicated IP for email deliverability ($20 to $50/month). Email deliverability is critical for a dunning platform. If your recovery emails land in spam, you are recovering nothing. Invest in proper SPF, DKIM, and DMARC configuration, warm up your sending domain gradually, and monitor bounce and complaint rates.

Maintenance and Feature Development: $5,000 to $15,000/month

At minimum, you need one senior engineer maintaining the platform, responding to billing provider API changes, updating integrations when providers release new features, and fixing bugs. Budget for at least half-time dedicated engineering capacity. Billing providers update their APIs frequently, and a breaking change in a webhook format can halt recoveries for all your customers if you do not catch it quickly.

Timeline Summary

• MVP (Stripe-only, email, basic retries): 10 to 16 weeks, $50,000 to $100,000
• Full product (multi-provider, SMS, ML retries, A/B testing): 5 to 9 months, $150,000 to $350,000
• Ongoing monthly costs: $5,500 to $18,500 including infrastructure, services, and engineering

What To Do Next

If you are building a dunning SaaS product, start with Stripe integration and email recovery sequences. That combination covers the largest market segment and lets you validate demand before investing in multi-provider support or ML-powered retries. Prove that customers will pay for recovered revenue, then expand.

If you are a SaaS operator trying to reduce involuntary churn, evaluate Churnkey or Butter first. If their pricing works for your scale and their features cover your needs, buy rather than build. Redirect that $50K to $100K toward your core product.

At Kanopy, we have built payment infrastructure, billing integrations, and recovery systems for SaaS companies ranging from early-stage startups to platforms processing millions in monthly revenue. If you want a realistic estimate for your specific dunning product, including architecture guidance, timeline, and a detailed cost breakdown, book a free strategy call and we will walk through it together.