Dunning Optimization with Segment

What Dunning Optimization Actually Requires

Failed payments are not a billing problem. They are a data problem. The card declines because your payment processor lacks context — wrong retry timing, no pre-failure warning sent, no signal connecting a customer's behavior to their payment risk. Segment does not fix your billing logic directly, but it gives you the data infrastructure to make your dunning stack significantly smarter.

This guide shows you exactly how to wire Segment into a dunning optimization workflow, which features to use at each step, and where the tool hits its limits.

---

The Core Architecture

Dunning optimization through Segment runs on three capabilities working together:

• Event collection — capturing payment lifecycle events from your billing tool into Segment
• Audience segmentation — grouping at-risk accounts by failure type, plan tier, and behavioral signals
• Downstream orchestration — routing those audiences to your email, CRM, or retry tools with the right context

Segment sits in the middle. It is the routing layer, not the decision engine.

---

Step 1: Connect Your Billing Source

Start with Sources. Add your billing platform — Stripe, Chargebee, Recurly, or Braintree — as a Segment source. Most major billing tools have native Segment integrations or send webhooks you can route through a HTTP API Source.

The events you must track:

• `payment_failed` — include `failure_code`, `attempt_number`, `amount`, and `plan_id` as properties
• `payment_retried` — timestamp and retry count
• `payment_recovered` — to close the loop on campaign attribution
• `subscription_canceled` — to distinguish voluntary from involuntary churn

If your billing tool does not send these natively, build a server-side tracking call using Segment's Node.js, Python, or Ruby libraries. Do not rely on client-side events for payment data — they are unreliable and create compliance risk.

---

Step 2: Enrich the User Profile in Segment Profiles

Raw payment events are not enough. You need behavioral context on the same profile.

Use Segment Profiles (formerly Personas) to build unified customer profiles that merge:

• Payment events from your billing source
• Product usage events (login frequency, feature adoption, last active date)
• Support ticket data from Zendesk or Intercom
• Subscription metadata from your database

A customer who has not logged in for 30 days and just had a payment fail is a different risk than an active daily user with an expired card. Segment Profiles lets you build that distinction into a single profile accessible by downstream tools.

Create Computed Traits to generate signals like:

• `days_since_last_login`
• `total_failed_payments_90d`
• `last_product_activity`

These traits become properties you can use in audience filters and pass to your messaging tools.

---

Step 3: Build Dunning Audiences in Segment Audiences

Segment Audiences (within Twilio Engage or Unify, depending on your plan) is where you define who receives each dunning intervention.

Build distinct audiences for each dunning scenario:

Pre-dunning audience — cards expiring within 30 days, no failed payment yet. Filter by: `card_expiry_date` within next 30 days AND `payment_failed count in last 90 days = 0`. Route to a proactive card update email before the failure happens.

First failure — high-value accounts — `payment_failed attempt_number = 1` AND `plan_id` in [enterprise, pro]. These accounts get prioritized outreach, potentially a direct sales or success team notification via Salesforce or HubSpot.

First failure — standard accounts — same `attempt_number = 1` filter, lower plan tiers. These go to automated email sequences.

Persistent failure — 3+ attempts — `payment_failed attempt_number >= 3`. These accounts need a different message — urgency, specific card update instructions, potential pause offer.

Recovered — `payment_recovered in last 7 days`. Exit audiences above, trigger a confirmation message, update CRM status.

Keep your audiences narrow and specific. A single catch-all "failed payment" audience produces generic messaging that converts poorly.

---

Step 4: Route Audiences to Your Tools

This is where Segment's 300+ integrations do the work. The routing logic depends on which tools you use.

If you use Braze

Sync your dunning audiences to Braze using the Braze (Actions) destination. Segment will push audience membership as user attributes — for example, `in_dunning_first_failure: true`. Inside Braze, use Canvas to build multi-step dunning flows triggered by these attributes. Canvas handles the timing, branching, and channel selection (email, push, SMS) without you needing to rebuild that logic in Segment.

If you use Iterable

The Iterable (Actions) destination syncs audience membership and computed traits. Use Workflow Studio inside Iterable to build the retry communication sequences. Segment feeds the audience; Iterable controls the messaging cadence.

If you use Salesforce or HubSpot

For high-value account dunning, sync the enterprise failure audience directly to your CRM. Use the Salesforce (Actions) or HubSpot (Actions) destination to create or update contact records with dunning status. This surfaces at-risk accounts in your sales team's queue without any manual reporting.

Retry timing logic

Segment does not control payment retry timing. That stays in your billing platform. What Segment improves is the communication around retries — ensuring your email sequence aligns with when retries actually fire. Pass `next_retry_date` as an event property from your billing source, and use it as a dynamic variable in your messaging templates.

---

Limitations to Understand Before You Build

Segment is a data routing and profile layer. It has real constraints in this use case.

No native retry logic. Segment cannot instruct your payment processor to retry at a specific time. You still need Stripe's Smart Retries, Chargebee's Dunning configuration, or a tool like Churnkey or Gravy for retry orchestration.

Audience sync latency. Depending on your plan, audience membership updates in Segment can take minutes to hours. For time-sensitive first-failure messaging — where every hour matters — test your sync latency and account for it in your SLA.

Limited built-in suppression. Segment does not natively suppress messaging after a payment recovers mid-sequence unless you build an exit audience and configure suppression in your downstream tool. Build the `payment_recovered` exit condition explicitly in every dunning flow.

Warehouse dependency for complex logic. If you need multi-variable scoring — combining payment failure recency, product usage drop, and plan value into a single dunning risk score — you will likely need to compute that in your data warehouse and sync it back via Reverse ETL using a tool like Census or Hightouch.

---

Frequently Asked Questions

Can Segment trigger payment retries directly?

No. Segment routes data and syncs audiences — it does not send instructions to payment processors. Retry scheduling stays in your billing platform. Segment's role is ensuring the right communication fires at the right time around those retries, and that your CRM and support tools have accurate status information.

Which Segment plan do I need for dunning audiences?

Audience building requires Twilio Engage (formerly Segment Personas). The base Segment connections plan gives you event routing to destinations but not the Audiences or Profiles features that make dunning segmentation precise. Confirm your plan includes Engage before building this workflow.

How do I measure whether the dunning setup is working?

Track `payment_recovered` events back through the same Segment pipeline. Create a Funnel Analysis in your analytics tool using Segment data: `payment_failed` → `dunning_email_opened` → `payment_recovered`. Attribution requires consistent `anonymous_id` or `user_id` threading across your billing and messaging events — verify that before you try to measure results.

What do I do if a customer updates their card but the audience does not exit?

This is a suppression gap. Create a `payment_recovered` audience in Segment, then configure suppression or exit logic in your messaging tool using that audience as a block list. Do not rely on Segment alone to stop a dunning sequence — build the exit condition into both Segment and the downstream tool as a redundant safeguard.