Dunning Optimization for Fintech

The Silent Revenue Leak Most Fintech Teams Underestimate

Failed payments are costing fintech companies between 9% and 12% of annual recurring revenue. Not churned users who made a deliberate choice to leave — users who intended to stay but got dropped because a card expired or a payment processor returned a soft decline at the wrong moment.

That number compounds fast. If you're running a consumer fintech product at $10M ARR, you're potentially leaving $900K to $1.2M on the table every year from involuntary churn alone. Most of your users never even know it happened. They just lose access and don't come back.

This is the dunning problem. And in fintech specifically, it's more complex than it is for a typical SaaS product — because your users are more sensitive to friction around money, your compliance requirements limit certain communication approaches, and your payment failure rates tend to run higher due to prepaid card usage, spending limits, and real-time balance checks.

Solving it requires more than a retry-after-48-hours email. It requires a system.

---

Why Fintech Has a Harder Dunning Problem

In a standard B2B SaaS context, a failed payment usually means a credit card that expired or a billing contact who changed jobs. The stakes are relatively contained.

In consumer fintech — budgeting apps, neobanks, investment platforms, credit monitoring services — you're dealing with a different user base. A significant portion of your customers use debit cards, prepaid accounts, or cards tied to accounts that fluctuate week to week. According to data from Recurly's 2023 State of Subscriptions report, consumer apps see involuntary churn rates nearly 2x higher than B2B software products.

You're also working with tighter communication constraints. Regulatory guidance around financial services communications (UDAAP, TCPA, state-level rules) means you need to be careful about frequency, tone, and channel when contacting users about billing issues. A collections-adjacent message sent at the wrong time, in the wrong format, creates compliance exposure.

And unlike a SaaS tool that a user might miss passively, fintech users often notice the service disruption immediately — they try to check their portfolio, their credit score, or their account balance and find themselves locked out. That friction window is short. If you don't catch them fast, they're gone.

---

The 5-Layer Dunning System for Fintech

Layer 1: Pre-Dunning Alerts (7–14 Days Before Failure)

Most dunning systems are reactive. Yours should start before any payment fails.

Pre-dunning means identifying accounts likely to fail before they do. Flag cards expiring in the next 30 days and trigger an update flow immediately. If you're integrated with a payment processor like Stripe or Braintree, you can also flag accounts that returned soft declines in the past 90 days — these users are statistically more likely to fail again.

Build a short in-app prompt and a single email asking users to verify their payment method is current. Frame it around continuity ("Keep your access uninterrupted") rather than urgency. In testing across fintech apps, this pre-dunning window alone can prevent 20–30% of failures before they occur.

Layer 2: Smart Retry Logic

Not all payment failures are equal. A soft decline (insufficient funds, card velocity limit) is fundamentally different from a hard decline (stolen card, account closed). Your retry logic should reflect this.

For soft declines, use an intelligent retry sequence rather than a fixed interval. Industry benchmarks suggest:

• First retry: 24–48 hours after initial failure
• Second retry: 3–5 days later, at a different time of day
• Third retry: 7 days later, ideally timed to likely payroll cycles (Monday or Friday)

For hard declines, stop retrying immediately and move directly to a payment method update flow. Repeated hard decline attempts increase your chargeback risk and can flag your merchant account.

Stripe's Smart Retries and Chargebee's retry logic use machine learning to optimize timing based on network signals — worth using if you're on those platforms rather than building custom logic.

Layer 3: The Dunning Communication Sequence

Once a payment has failed, your communication sequence needs to be fast, specific, and channel-appropriate.

A well-structured sequence looks like this:

1. Day 0 — In-app banner or push notification immediately after failure. No email yet. Get them while they're in the product.
2. Day 1 — Email with a direct link to update payment method. Subject line should be functional, not alarmist.
3. Day 4 — Second email. Include specifics about what they'll lose access to on day X if the payment isn't resolved. Loss aversion is real — use it.
4. Day 7 — SMS if you have consent and it's compliant for your user segment. This is your highest-urgency touchpoint.
5. Day 10–12 — Final notice before access suspension. Give a clear deadline.

Tools like Braze, Iterable, and Customer.io can orchestrate this sequence across channels with conditional logic — so a user who updates their payment method on day 2 automatically exits the sequence rather than receiving the day 4 message.

Layer 4: Friction-Reduced Recovery Flow

Even when a user responds to your dunning outreach, you can lose them in the recovery flow itself.

The update payment form should be a single-tap or one-screen experience on mobile. No login wall. No navigation to a settings page buried three levels deep. Use a tokenized link in your email that authenticates the user automatically and drops them directly into the payment update screen.

Companies that reduce payment update steps from 4+ to 2 or fewer see recovery rates improve by 15–25%.

Layer 5: Win-Back for Unrecovered Churners

Some users will churn despite everything. That's not the end of the conversation.

Build a win-back segment of involuntary churned users and run a re-engagement campaign 30 and 60 days post-churn. These users had intent to stay — they didn't consciously cancel. Their propensity to resubscribe is meaningfully higher than that of voluntary churners.

Offer a frictionless re-entry path. Highlight what's new or improved. In some cases, a one-month discount or free trial extension meaningfully improves win-back rates for this specific cohort.

---

Benchmarks to Track

• Recovery rate: Industry average for optimized dunning sequences is 40–60% of failed payments recovered
• Pre-dunning prevention rate: 20–30% of potential failures prevented before they occur
• Time-to-recovery: Best-in-class fintech teams recover payments within 5 days on average
• Win-back rate on involuntary churn: 15–25% within 90 days with a structured campaign

---

Where to Start

Audit your current retry logic this week. Map out exactly what happens after a payment fails — how many retries, at what intervals, and what communication goes out. Most teams find they're running a 2–3 step process where a 5-layer system should exist.

From there, implement pre-dunning alerts first. It's the highest-leverage, lowest-effort intervention in this entire framework, and you'll see impact within a single billing cycle.

---

Frequently Asked Questions

How many retry attempts should a fintech app make before suspending access?

Most optimized dunning systems make 3–4 retry attempts over a 10–14 day window for soft declines. Beyond that, the incremental recovery rate drops sharply and you risk degrading user trust. Hard declines should not be retried — move immediately to a payment update flow.

Is it safe to send SMS messages as part of a dunning sequence?

Yes, with proper consent. You must have explicit opt-in for transactional SMS under TCPA, and some states have additional requirements. If you have compliant consent on file, SMS is one of your highest-performing dunning channels — open rates are significantly higher than email for billing-related messages.

What's the difference between dunning and collections?

Dunning refers to the process of recovering payment from customers with failed charges who remain customers in good standing — the assumption is that the failure was unintentional. Collections involves pursuing payment from users who have been terminated for non-payment. Regulatory treatment of these two activities differs materially, and your dunning communications should avoid language or practices that could be interpreted as debt collection.

Can tools like Braze or Customer.io handle dunning sequences automatically?

Yes. Platforms like Braze and Customer.io support triggered behavioral campaigns with exit conditions — meaning you can build a full dunning sequence that automatically pauses when the payment is resolved. You'll still need your billing platform (Stripe, Chargebee, Recurly) to pass the relevant events via API or webhook to trigger and close out the sequence.