Dunning Optimization with Klaviyo

What Dunning Optimization Actually Requires

Failed payments are a silent revenue leak. A card declines, a subscription lapses, and a customer you worked hard to acquire disappears — not because they wanted to leave, but because of a billing failure. This is involuntary churn, and it's recoverable.

Dunning optimization has two components: pre-dunning (alerting customers before a payment fails) and retry logic (the sequenced follow-up after failure). Most brands handle neither well. They send one generic "your payment failed" email and call it done.

Klaviyo gives you enough infrastructure to build a serious dunning program — with some important constraints you need to understand before you build.

---

How Klaviyo Fits Into the Dunning Stack

Klaviyo is not a payment retry engine. It does not control when your payment processor attempts to charge a card. That logic lives in your subscription platform — Recharge, Skio, Stay AI, Bold Subscriptions, or wherever you manage recurring billing.

What Klaviyo controls is the communication layer: the timing, content, and channel of every message sent to customers with failed or at-risk payments.

This distinction matters for your architecture. Your subscription platform fires the events. Klaviyo listens for them and acts.

---

Setting Up the Event Infrastructure

Connect Your Subscription Platform

Before building a single flow, you need clean event data flowing into Klaviyo. Most major subscription platforms have native Klaviyo integrations.

If you're using Recharge, enable the Klaviyo integration inside Recharge's settings. This pushes events like `Payment Failed`, `Upcoming Charge`, and `Subscription Cancelled` directly to Klaviyo as custom events.

If you're on a platform without a native integration, use a tool like Segment or build a direct API connection to push custom events to Klaviyo's [Track API](https://developers.klaviyo.com/).

The four events your dunning program depends on:

1. `Upcoming Charge` — fires 3-7 days before a billing attempt (enables pre-dunning)
2. `Payment Failed` — fires immediately on the first failed attempt
3. `Payment Failed (Retry)` — fires on each subsequent retry attempt
4. `Subscription Cancelled` — fires if all retries are exhausted

Verify these events are arriving in Klaviyo by checking Activity Feed inside a test profile. Do not build flows until you can see clean event data.

---

Building the Pre-Dunning Flow

Pre-dunning is the highest-ROI part of this system. You're catching customers before failure, not chasing them after.

Trigger and Timing

In Klaviyo's Flow Builder, create a new flow triggered by the `Upcoming Charge` event. Set the entry condition to fire 5-7 days before the billing date — your subscription platform should pass the charge date as an event property so you can reference it.

Message Structure

The pre-dunning email has one job: prompt the customer to verify their payment method is current. Keep it short.

• Subject line: lead with utility, not urgency. "Your [Brand] order is coming up" outperforms "Action required."
• Body: one sentence explaining a charge is upcoming, one sentence with a direct link to their account to update payment details
• Include the charge amount using dynamic variables pulled from the event properties (`{{ event.charge_amount }}`)

Add an SMS step 24 hours after the email for customers who haven't updated their card. Klaviyo's conditional splits let you branch based on whether a profile has a phone number and has consented to SMS.

---

Building the Post-Failure Dunning Sequence

Flow Architecture

Create a second flow triggered by the `Payment Failed` event. This is your recovery sequence.

A standard four-touch sequence:

| Step | Timing | Channel | Message Focus |

|------|--------|---------|---------------|

| 1 | Immediately | Email | Payment failed — update now |

| 2 | Day 2 | SMS | Short, direct link to update |

| 3 | Day 5 | Email | What they'll lose (order, subscription) |

| 4 | Day 8 | Email | Final notice before cancellation |

Each email should contain a direct payment update link. Klaviyo lets you pass dynamic URLs through event properties — work with your subscription platform to generate a tokenized link that drops the customer directly into their payment update screen, no login required.

Using Conditional Logic

Inside Klaviyo's Flow Builder, add a conditional split after each step to check whether the payment has been recovered. Your subscription platform should push a `Payment Recovered` event when a retry succeeds.

Set the split condition: "Has done `Payment Recovered` zero times since starting this flow." If yes (still failed), continue the sequence. If no (payment recovered), send a confirmation email and exit the flow.

Without this logic, customers who successfully update their card still receive dunning messages. That creates friction and damages trust.

---

Segmentation for Smarter Messaging

Not every failed payment is equal. Use Klaviyo's Segment Builder to create risk tiers.

High-value subscribers (customers with predicted lifetime value above a threshold, using Klaviyo's predictive analytics feature): assign these customers a dedicated flow with a personal tone and potentially an offer — a one-time discount or free shipping on their next order to re-engage.

Long-tenure subscribers (active for 12+ months): these customers have demonstrated loyalty. Messaging them with urgency reads as punitive. Lead with appreciation before asking for action.

Recent subscribers (under 90 days): these customers have weak retention signals. Your messaging should reinforce the product's value — remind them what they signed up for.

Use Klaviyo's flow filters at the flow level to route profiles into the appropriate sequence based on segment membership.

---

Suppression and Exit Logic

Build a suppression list for customers who have already cancelled their subscription. If a `Subscription Cancelled` event fires, Klaviyo should suppress the profile from all active dunning flows immediately.

Set this as a flow filter: "Has not done `Subscription Cancelled` zero or more times" — anyone who cancels exits all active dunning flows automatically. Messaging churned customers with dunning emails is brand damage without recovery upside.

---

Klaviyo's Limitations for Dunning

Be direct about what Klaviyo cannot do here:

• No native retry control: Klaviyo cannot instruct your payment processor to retry a charge. Smart retry logic (timing retries to specific days of the month, card types, or failure reason codes) happens in your subscription platform, not Klaviyo.
• No card expiration prediction: Klaviyo does not have access to card metadata. A dedicated dunning tool like Chargebee Retention or Butter can read card expiration dates and trigger pre-emptive alerts. Klaviyo cannot.
• Event dependency: your entire dunning program is only as good as the event data your subscription platform sends. Gaps in event firing mean gaps in your coverage.
• No native reporting on dunning recovery rate: you'll need to build a custom metric in Klaviyo tracking `Payment Recovered` events attributed to flow sends, or pull this data from your subscription platform directly.

---

Frequently Asked Questions

Can Klaviyo trigger payment retries directly?

No. Klaviyo sends messages — it does not control payment processing. Your retry schedule is set inside your subscription platform (Recharge, Skio, etc.). Klaviyo's role is to communicate with the customer at each stage of the retry cycle, not to initiate the retries themselves.

What's the best timing for the pre-dunning email?

Five days before the charge date is a reliable default. It gives customers enough time to update their payment method without feeling like the alert is too distant to be relevant. If your average customer checks email every 2-3 days, five days provides at least one open opportunity before the charge attempt.

How do I stop dunning emails once a customer fixes their payment?

Add a conditional split after each flow step that checks whether the `Payment Recovered` event has fired. If the event exists on the profile since flow entry, route the customer to a confirmation email and end the flow. This requires your subscription platform to reliably push the `Payment Recovered` event to Klaviyo — confirm this is working in your test environment before going live.

Should I include a discount in my dunning emails?

Only for high-value or long-tenure segments, and only in the later steps of your sequence. Offering a discount in the first dunning email trains customers to wait for the offer rather than updating immediately. Reserve incentives for step three or four, after direct asks have not converted.