5-Step Failed Payment Dunning by Plan Tier in 2026

Involuntary churn — accounts that lapse because of a failed payment rather than a cancellation decision — is the most recoverable form of revenue loss in SaaS. Unlike intentional cancellations, where the customer has made a decision, failed-payment churn is typically caused by an expired card, a bank fraud flag, or a temporarily exceeded credit limit. The customer still wants the product.

The failure is in the dunning sequence. Most SaaS products run a single dunning flow: Stripe retries the charge on day 3, 5, and 7, sends a generic "update your payment method" email to everyone, and cancels the account on day 10. A startup customer on the $49/month plan and an enterprise account on the $3,600/month plan receive the same email and the same retry schedule.

Median SaaS net revenue retention ($10-50M ARR): 110% according to Bessemer 2024 State of the Cloud (2024). That figure — teams retaining more revenue from existing customers than they add from new ones — is only achievable if involuntary churn is actively managed. A flat dunning flow that treats all plan tiers identically is a structural leak in your retention architecture.

This recipe walks the 5 steps to build a tier-differentiated dunning system that matches escalation intensity to plan economics.

Key Takeaways

• Plan-tiered dunning matches retry cadence, outreach channel, and escalation path to the revenue at stake per account.

• Enterprise and mid-market tiers warrant a human outreach step that starter tiers do not justify operationally.

• The Stripe invoice.payment_failed event is the correct trigger — not customer.subscription.deleted (which fires too late).

• A tier-based dunning system recovers 55–65% of failed-payment accounts versus 30–35% for a single generic flow.

• The five steps are: classify the account, configure tier-appropriate retry timing, send tiered email sequences, escalate to CSM or phone for high-value tiers, and log recovery outcomes for continuous tuning.

Who This Recipe Is For

This recipe is built for SaaS billing operators, RevOps leads, and CS/Ops managers at companies running $1M–$30M ARR on Stripe (or equivalent) billing infrastructure. Applicable if you have at least two distinct plan tiers with meaningfully different monthly contract values.

Red flags: Skip if all plans are priced within a $30/month range of each other (tier differentiation adds complexity without payoff), if you process fewer than 25 failed payments per month (the volume does not justify the routing overhead), or if your billing system does not expose plan metadata on the payment failed event.

TL;DR: Build three dunning tracks — Starter, Growth, Enterprise — triggered at invoice.payment_failed, differentiated by retry cadence, email sequence intensity, and human escalation threshold. Wire them in 5 steps. Tune quarterly using recovery rate by tier.

Glossary

Dunning: The process of communicating with customers to collect a payment that has failed. In SaaS, typically automated via email and retry sequences.

Involuntary churn: Account cancellation caused by payment failure rather than customer intent. Recoverable with a well-designed dunning sequence.

invoice.payment_failed: The Stripe webhook event that fires when a subscription invoice charge attempt fails. Contains plan ID, amount, failure reason, and customer metadata.

Smart retry: Stripe's machine-learning-based charge retry schedule that selects retry times based on historical payment patterns. Available on Stripe Billing.

Hard decline: A permanent payment failure where the bank has blocked the transaction (e.g., card number invalid, account closed). Cannot be recovered by retrying — requires the customer to provide a new payment method.

Soft decline: A temporary payment failure (e.g., insufficient funds, fraud flag) that may succeed on a later retry. The majority of failed payments are soft declines.

Grace period: The number of days after a payment failure during which the customer retains access to the product while the dunning sequence runs.

Step 1: Classify the Account by Plan Tier at the Moment of Failure

When invoice.payment_failed fires, your orchestration layer needs to determine which dunning track to activate. The classification should read the plan metadata directly from the Stripe event rather than from a separate CRM lookup — latency in the CRM can mean the account is already in a degraded state before the classification completes.

Define three dunning tracks based on MRR at risk:

The MRR thresholds are configurable and should reflect your plan pricing. A company with $49, $199, and $999 tier pricing would align Starter to the $49 plan, Growth to the $199 plan, and Enterprise to the $999 plan.

According to ChurnBuster's 2024 Dunning Benchmarks Report, grace periods shorter than 7 days for starter accounts produce only marginal additional recovery (2–3%) while generating significantly higher support ticket volume from customers confused about their access status. Longer grace periods on starter accounts are not operationally worth the complexity.

Step 2: Configure Tier-Appropriate Retry Timing

Stripe Smart Retry handles the charge scheduling, but you need to configure the retry window per tier in your Stripe Billing settings. Default Stripe Smart Retry runs 4 retries over 7 days. For Enterprise accounts, you want to extend this window and align retries with your CSM outreach schedule.

Starter: Default Stripe Smart Retry (4 attempts over 7 days). No manual overrides.

Growth: 5 retries over 12 days, with the second retry delayed to day 5 to align with the CSM email. A card that fails on day 1 may be approved after the customer speaks with your CSM on day 5.

Enterprise: 6 retries over 21 days, with retry windows aligned to the CSM's call schedule. Avoid retrying on weekends for enterprise accounts where the AP team processes card updates on business days.

Benchmark: Enterprise dunning recovery at 65% according to ProfitWell 2024 Payment Recovery Report (2024) when retries are aligned with human outreach, versus 41% with automated-only retry.

Step 3: Send Tiered Email Sequences

The email sequence structure differs materially by tier because the language, urgency framing, and call-to-action differ based on who is reading the email at each company type.

For Starter accounts, the email recipient is typically the subscriber themselves — a founder or individual operator. Short, direct, and low-friction.

For Growth and Enterprise accounts, the email may go to a finance manager, an IT administrator, or an AP contact. These recipients need the invoice reference number, the specific card on file (last 4 digits), and a direct link to the billing portal — they cannot look these up easily.

The Enterprise sequence deliberately avoids the phrase "your account will be cancelled" in early emails — this language triggers escalations from procurement and legal teams that slow down the card update rather than accelerating it. Use "your billing requires attention" and "your invoice is outstanding."

US Tech Automations manages the tiered email queue by listening to invoice.payment_failed, routing the account to the correct tier track, and scheduling each email in the sequence without requiring a Zapier step for each individual touch. The orchestration layer also handles suppression — if the customer updates their card and invoice.payment_succeeded fires, all pending dunning emails are cancelled automatically.

Step 4: Escalate to CSM or Human Outreach for High-Value Tiers

Growth and Enterprise tiers require a human escalation step that Starter accounts do not. The economics justify it: an Enterprise account at $2,400/month represents $28,800 of annual contract value. A 30-minute CSM call that recovers one account per month returns $28,800 in ACV for roughly 6 hours of CS time per month — an ROI calculation that is easy to defend.

Worked example: A B2B SaaS company processes 48 failed payments per month, of which 11 are Growth tier ($350–$750 MRR) and 4 are Enterprise tier ($1,200–$3,600 MRR). When invoice.payment_failed fires for any Growth or Enterprise account, the orchestration layer creates a task in the CSM's queue within 4 hours. The CSM has a 48-hour SLA to make first contact. On average, 7 of the 11 Growth accounts update their card within the grace period (64% recovery), and 3 of the 4 Enterprise accounts recover (75% recovery). The combined MRR saved per month across both tiers is approximately $10,400 — against a CSM time investment of about 8 hours.

For the Starter tier, the math inverts: 33 failed payments averaging $87 MRR each means even a 100% CSM recovery rate on those accounts would generate $2,900 of MRR saved against 33 individual touchpoints. The automation-only approach is the right call.

Step 5: Log Recovery Outcomes and Tune Quarterly

A dunning system that does not measure its own performance will drift. The metrics that matter are recovery rate by tier, average days to recovery, and recovery method (automatic retry vs. card update vs. CSM-assisted). Log these per invoice.payment_failed event to a data warehouse or your CRM.

Tune quarterly by reviewing:

1. Retry timing alignment: Are the retry windows for Growth and Enterprise aligned with when customers are actually updating cards? If card updates cluster on Mondays, shift retry 2 to Tuesday.

2. Email open rates by step: Low open rate on day 1 emails suggests deliverability issues or subject line problems. High open rate with low click-through suggests the card update link or billing portal UX is the friction point.

3. CSM conversion rate: If the CSM is reaching customers but recovery is below 60% for Enterprise, the issue may be the outreach script or the billing portal experience — not the dunning schedule.

4. Hard vs. soft decline ratios: If more than 30% of your failed payments are hard declines, the dunning sequence has a ceiling. Hard declines require proactive card hygiene (card expiry reminders 30 and 7 days before expiry) rather than reactive dunning.

According to Recurly's 2024 Subscription Finance Report, SaaS teams that review and tune their dunning sequences quarterly recover 18% more revenue annually than teams that configure and forget.

The agentic workflow automation platform handles the logging step by writing recovery events to a connected data store, making the quarterly review a pull from a structured table rather than a manual reconstruction from email logs.

Benchmarks: Tiered vs. Single-Flow Dunning

The CS hours investment for Growth and Enterprise escalation is the only cost increase — and it is paid back at a minimum 10:1 ratio at average enterprise MRR.

Email Sequence Performance Benchmarks by Tier

Understanding how each tier's email sequence performs is critical for quarterly tuning. The table below summarizes typical open rates, click-through rates, and card update rates observed across tiered dunning implementations.

According to Churnbuster's 2024 Dunning Benchmarks Report, day-5 emails with a CSM sender name achieve a 31% higher card update rate than the same message sent from a support alias — the sender identity is the primary driver of enterprise-tier recovery performance.

US Tech Automations manages the sender-identity routing automatically: Starter tier emails send from the support alias, Growth tier day-5 escalation switches to the assigned CSM's address, and Enterprise tier sends from the CSM's personal address from day 1. The orchestration layer handles the sender swap without requiring a manual handoff from the billing team to CS.

For SaaS teams using Stripe as their billing backbone, the US Tech Automations platform also handles suppression automatically — when invoice.payment_succeeded fires after the dunning sequence starts, all pending emails and retry escalations are cancelled within 60 seconds, preventing the customer from receiving a "your account is at risk" email after they've already resolved the payment. You can explore the full billing recovery workflow at ustechautomations.com/ai-agents/finance-accounting.

Common Mistakes in Dunning Systems

Using customer.subscription.deleted as the trigger. This event fires after the grace period has elapsed and the account is cancelled. You want invoice.payment_failed, which fires at the moment of failure — giving you the full grace period to recover.

Treating all declines as soft declines. Hard declines (stolen card, account closed) cannot recover through retries. Your orchestration layer should check the Stripe decline code and route hard declines directly to a "new card required" email rather than through the retry sequence.

Not suppressing dunning emails after recovery. A customer who updates their card on day 2 should not receive the day 5 escalation email. This is a basic suppression requirement that many first-generation dunning setups miss.

Escalating Enterprise accounts to the CSM too late. By day 7, an Enterprise customer who has been getting automated emails may already be frustrated. The first CSM touch should be within 48–72 hours of the failed payment — early enough to feel proactive rather than punitive.

When NOT to Use US Tech Automations

The tiered orchestration approach described in this recipe assumes meaningful plan price differentiation and a CS team structure that can handle Growth and Enterprise escalations. There are contexts where it is not the right fit.

If your product is entirely self-serve with no CS team and your highest plan is under $99/month, the tier differentiation adds operational complexity that Stripe's built-in Smart Retry handles more cost-effectively. Pair Smart Retry with a well-timed 3-email sequence and you will capture most recoverable accounts.

If you are on a billing platform other than Stripe with limited API access (some legacy billing systems), the orchestration layer's ability to read plan metadata in real time may be constrained. In that case, Churnbuster or Chargebee's native dunning tools may integrate more cleanly with your billing stack.

Frequently Asked Questions

What is the correct Stripe event to trigger dunning?

Use invoice.payment_failed. This event fires immediately when a charge attempt fails and includes the invoice ID, plan metadata, failure reason (decline code), and customer email. Do not use customer.subscription.past_due — this fires after the first retry cycle and is too late to start a proactive dunning sequence.

How many retry attempts should I configure per tier?

Starter: 4 retries over 7 days (Stripe Smart Retry default). Growth: 5 retries over 12 days. Enterprise: 6 retries over 21 days. More retries beyond 6 rarely improve recovery rates and can generate additional bank fees on some card networks.

Should dunning emails come from a support address or the CSM's personal email?

Starter tier: Support address. Growth tier: Support address on days 1–3, CSM's address on the day-5 escalation. Enterprise tier: CSM's personal email from day 1 — enterprise customers are more likely to respond to a named person than a support alias. The CSM's email also signals that their account is being personally managed.

What decline codes indicate a hard decline vs. a soft decline?

Hard declines (do not retry): do_not_honor, stolen_card, lost_card, card_not_supported, invalid_account. Soft declines (safe to retry): insufficient_funds, do_not_honor when sent from certain card networks on first attempt, processing_error. Stripe's documentation provides the full decline code taxonomy and recommended handling.

How do I prevent dunning emails from going to a cancelled account?

Check the subscription status before sending each email in the sequence. If invoice.payment_succeeded or customer.subscription.deleted has fired since the dunning sequence started, cancel all pending sends. This check should be in the orchestration logic, not the ESP — ESPs do not have real-time access to subscription status.

What is a good benchmark for overall dunning recovery rate?

According to ProfitWell 2024 Payment Recovery Report, the median overall recovery rate for SaaS companies is 38–42%. Companies with tiered dunning and CSM escalation achieve 55–65%. Top performers (tiered + proactive card expiry reminders) reach 70–75%.

Can I run dunning for annual contracts differently than monthly subscriptions?

Yes — and you should. Annual contracts represent 12x the MRR at risk and warrant immediate human escalation (within 24 hours) rather than following the 48–72 hour grace period standard for monthly accounts. Add an annual contract flag to your dunning classifier and route those accounts directly to the Enterprise escalation track regardless of plan tier.

Conclusion

Failed-payment accounts recover 2x more revenue according to Recurly 2024 Subscription Finance Report (2024) when the dunning sequence is matched to plan tier versus a single undifferentiated flow — the benchmark difference between 31% and 59% overall recovery rates.

The five-step recipe — classify at failure, configure tier-appropriate retries, send tiered email sequences, escalate Growth and Enterprise accounts to human outreach, and tune quarterly on recovery data — is not architecturally complex. It is operationally disciplined. The discipline is in building three tracks instead of one and measuring each independently.

For SaaS teams ready to implement tiered dunning without rebuilding their billing infrastructure, explore the workflow architecture and pricing at ustechautomations.com/pricing.

For adjacent billing recovery workflows, see the guide on SaaS billing failure recovery, the Mixpanel-to-CustomerIO event trigger pattern for product-led escalation sequences, and involuntary churn reduction playbooks for SaaS.