Dunning Optimization with Braze

What Dunning Optimization Actually Requires

Failed payments are not a billing problem. They are a retention problem. When a card declines, you have a narrow window — typically 7 to 14 days before a subscription lapses — to recover that revenue through a combination of smart retry timing, personalized outreach, and frictionless payment updates.

Braze handles the communication layer of this problem well. Its real-time event architecture, Canvas Flow orchestration, and cross-channel delivery (push, email, SMS, in-app) make it a strong fit for dunning sequences. What it does not do is manage retry logic natively. That lives in your billing infrastructure — Stripe, Recurly, Chargebee, or similar. Your dunning strategy requires both systems working in coordination.

This guide covers how to build that coordination using Braze as the engagement layer.

---

How the Architecture Works

Your billing system owns the payment state. Braze owns the customer conversation. The integration between them is event-based.

Every meaningful billing event — initial failure, retry attempt, retry success, retry exhaustion, grace period start — should fire as a custom event into Braze. Pair those events with custom attributes that carry context: failure reason code, number of retries attempted, days remaining in grace period, subscription tier, payment method type.

With that data flowing, Braze can trigger personalized, time-sensitive outreach at each stage of the dunning cycle without requiring manual campaign management.

---

Step-by-Step Implementation

1. Define Your Billing Events and Attributes

Before touching Braze, map the events your billing system will send. A minimal dunning event schema looks like this:

• `payment_failed` — fires on first decline
• `payment_retry_failed` — fires on each subsequent decline
• `payment_retry_succeeded` — fires when a retry recovers the charge
• `payment_method_updated` — fires when the customer updates their card
• `subscription_grace_period_started` — fires when access is at risk
• `subscription_cancelled_involuntary` — fires at churn

Alongside these events, pass custom attributes:

• `dunning_failure_reason` (e.g., `insufficient_funds`, `card_expired`, `do_not_honor`)
• `dunning_retry_count` (integer)
• `dunning_grace_period_end_date` (date)
• `subscription_tier` (string)
• `payment_method_type` (e.g., `credit_card`, `paypal`)

These attributes are what allow you to personalize messaging — telling a customer their card expired is different from telling them their payment was generically declined.

2. Build a Pre-Dunning Alert (Optional but High-Value)

Pre-dunning means contacting customers before a payment fails. If a card's expiration date is approaching, or if your billing system flags a card as likely to decline based on network signals, you can send a proactive update request.

Set a scheduled audience sync in Braze using a Segment filter on `card_expiry_date` within the next 30 days. Run a simple Canvas Flow that sends an email at T-30 days, a push notification at T-14 days, and an in-app message on next session before T-7 days.

This sequence alone can reduce your involuntary churn rate by deflecting failures before they happen.

3. Build Your Core Dunning Canvas in Canvas Flow

Canvas Flow is where the dunning sequence lives. Create a single Canvas triggered by the `payment_failed` custom event.

Structure the Canvas with these components:

Entry: Action-based trigger on `payment_failed`. Set re-eligibility to allow re-entry after 30 days so customers who churn and resubscribe are not excluded.

Exit criteria: Add `payment_retry_succeeded` and `payment_method_updated` as exit events. The moment a customer recovers, they leave the Canvas. This prevents follow-up messages after resolution — one of the more common dunning mistakes.

Step 1 — Immediate notification (Day 0): Send an email and push notification simultaneously using a Message Step with multi-channel delivery. Use the `dunning_failure_reason` attribute to personalize the subject line and body copy. A card expiry message reads differently than a soft decline.

Step 2 — Wait + Retry alignment (Day 3): Add a Delay Step for 72 hours, timed to coordinate with your billing system's first retry attempt. Follow with a second email that leads with urgency — the customer's access is at risk.

Step 3 — Decision Split (Day 5): Use an Audience Path to split customers by `dunning_retry_count`. Customers on their third retry get a higher-urgency message with a direct payment update CTA. First-time failures get a softer reminder.

Step 4 — SMS escalation (Day 7): For high-value subscribers (filter by `subscription_tier`), add an SMS touchpoint. Reserve this channel for customers where the lifetime value justifies the additional friction.

Step 5 — Final notice (Day 10-12): Send a final email with a hard deadline. Reference the `dunning_grace_period_end_date` attribute dynamically so the date is accurate per customer, not generic.

4. Use Connected Content for Real-Time Payment Status

Braze's Connected Content feature allows you to make an API call at message send time to pull live data. If your billing system exposes an endpoint for current payment status, call it inside your email templates before rendering.

This prevents the scenario where a customer receives a dunning email hours after they already updated their card — a trust-eroding experience that is entirely avoidable.

5. Track Recovery Attribution

Create a conversion event on your Canvas tied to `payment_retry_succeeded` or `payment_method_updated` within a 14-day window. This gives you Canvas-level recovery rate data, not just open rates.

Segment your Canvas results by `dunning_failure_reason` and `subscription_tier` to understand which customer segments and failure types are recovering and which are not.

---

Limitations of Braze for Dunning

Braze is a messaging platform, not a billing orchestrator. Be clear about where its responsibility ends.

• No native retry logic. Braze cannot tell your billing system when to retry a charge. That scheduling lives entirely in your payment infrastructure.
• No payment UI. Braze cannot render a card update form. Your messages must link to a hosted payment update page built outside Braze.
• Event dependency. The entire system depends on clean, timely event delivery from your billing platform. If events arrive late or inconsistently, your Canvas timing breaks. Build monitoring around event ingestion latency.
• No direct suppression sync. If your billing system cancels a subscription without firing the correct Braze event, customers can remain in an active dunning Canvas. Implement a nightly data sync as a fallback.

---

Frequently Asked Questions

How many emails should a dunning sequence include?

Four to five touches over a 10 to 14 day window is a reasonable default. Front-load your sequence — the first 48 hours after a failure have the highest recovery rate. After day 10, response rates drop sharply. More messages past that point tend to increase unsubscribes without recovering meaningful revenue.

Can Braze handle dunning for both mobile and web subscribers differently?

Yes. Use Audience Paths in Canvas Flow to branch the sequence based on whether a user has a push token registered (indicating a mobile app user) versus email-only. Mobile users can receive an in-app message on next session as an additional touchpoint that web-only users cannot.

What is the right way to suppress users who cancel voluntarily from the dunning Canvas?

Add `subscription_cancelled_voluntary` as a Canvas exit event alongside the payment recovery events. You can also add a Global Control filter at Canvas entry that excludes users whose `subscription_status` attribute equals `cancelled_voluntary`. Belt and suspenders approach — use both.

Does Braze integrate directly with Stripe or Chargebee?

Not natively through a first-party connector for real-time billing events. You will send events from Stripe or Chargebee to Braze via the Braze REST API or through a data pipeline like Segment or mParticle. Several CDP and reverse-ETL tools also support this sync. The integration is straightforward but requires engineering time to instrument correctly.