Dunning Optimization with OneSignal

Why Dunning Fails Before You Even Send a Message

Most failed payment recovery falls apart not because the messaging is wrong, but because the timing is. Businesses either contact customers too late — after the payment has failed three times and the account is already suspended — or they send generic "your payment failed" notifications that give the customer no clear path forward.

Dunning optimization means building a system that catches failing payments before they become cancellations, and recovering them when they do fail. OneSignal gives you the infrastructure to do this through push notifications, in-app messages, email, and SMS — all coordinated through a single platform.

This guide covers exactly how to build that system.

---

What OneSignal Actually Offers for Dunning

OneSignal is primarily known as a push notification tool, but its current feature set makes it viable as a lightweight dunning orchestration layer — particularly for mobile-first products.

The relevant features for dunning work are:

• Journeys — OneSignal's visual automation builder. This is where you sequence your pre-dunning alerts and post-failure retry prompts across multiple channels.
• In-App Messages — Triggered messages that appear inside your app. Critical for catching users who have notifications disabled.
• Segments — Dynamic user groups based on data you send via the OneSignal SDK or API. You'll build your dunning cohorts here.
• Data Tags — Key-value pairs attached to user profiles. These drive the logic that determines where someone sits in the dunning sequence.
• Templates — Reusable message content you can reference across channels and Journeys.
• REST API — Lets your backend trigger messages and update user data in real time, which is essential for payment event-driven workflows.

OneSignal's free tier supports up to 10,000 subscribers with push and in-app messages. For most early-stage SaaS products, this is sufficient to run a full dunning workflow before you need to upgrade.

---

The Dunning Framework: Pre-Dunning and Post-Failure

Structure your recovery effort in two phases.

Pre-dunning targets customers whose cards are about to expire or whose payment is scheduled to process within 7–14 days. The goal is preventing the failure before it happens.

Post-failure recovery targets customers whose payment has already failed. The goal is getting them to update their payment method before they churn.

Each phase requires different timing, different messaging, and different channel prioritization.

---

Step-by-Step Implementation in OneSignal

Step 1: Set Up Your Data Tags

Before building any automation, you need structured data flowing into OneSignal. Use the OneSignal SDK or REST API to tag users with payment-relevant attributes.

The minimum viable tag set for dunning:

• `payment_status` — values like `active`, `failed`, `expiring_soon`
• `card_expiry_month` and `card_expiry_year`
• `failed_payment_count` — integer tracking retry attempts
• `days_until_retry` — countdown from your billing system
• `subscription_tier` — lets you prioritize high-value accounts

Update these tags from your billing system (Stripe, Paddle, Chargebee) via webhook → your backend → OneSignal API. This keeps the data current without requiring manual intervention.

Step 2: Build Your Dunning Segments

In the OneSignal dashboard, navigate to Segments and create the following:

1. Expiring Card Segment — Filter: `payment_status = expiring_soon`
2. First Failed Payment — Filter: `payment_status = failed` AND `failed_payment_count = 1`
3. Repeat Failure — Filter: `payment_status = failed` AND `failed_payment_count >= 2`
4. High-Value at Risk — Combine a failed payment filter with your `subscription_tier` tag

These segments update dynamically as your backend pushes tag updates, so users move through them automatically.

Step 3: Build Your Journeys

Journeys is where you orchestrate the sequence. Access it from the OneSignal dashboard sidebar.

Pre-Dunning Journey:

1. Entry trigger: User enters the "Expiring Card" segment
2. Day 0: Push notification — "Your card expires soon. Update it to keep access uninterrupted."
3. Day 3: In-app message — surfaces when user opens the app, with a direct link to billing settings
4. Day 6: Email — final reminder before the charge attempt

Post-Failure Journey:

1. Entry trigger: User enters the "First Failed Payment" segment
2. Hour 1: Push notification — inform them of the failure, link to payment update page
3. Hour 24: In-app message — appears on next app open
4. Day 3: Push notification — second attempt messaging
5. Day 5: Email — escalated message, potentially with a support offer
6. Exit condition: User's `payment_status` tag updates to `active`

Set the exit condition carefully. Without it, recovered users continue receiving dunning messages — which damages trust fast.

Step 4: Write the Message Templates

In Templates, create channel-specific variants for each message. The rules here are simple:

• Push notifications: 50–90 characters. One clear action. Link directly to your billing update page.
• In-app messages: Use the visual builder. Include a button that deep-links to payment settings. Keep body copy under 40 words.
• Email: More room for context, but still lead with the action in the first sentence.

Avoid vague subject lines like "Account Notice." Something like "Your payment didn't go through — here's how to fix it" outperforms generic messaging consistently.

Step 5: Trigger Updates via REST API

Your billing system needs to update OneSignal in real time when payment events happen. Use the [OneSignal REST API](https://documentation.onesignal.com/reference) to update Data Tags on the user's profile immediately after Stripe or your payment processor fires a webhook.

A failed payment webhook flow looks like:

1. Stripe fires `invoice.payment_failed` webhook
2. Your backend receives it, identifies the customer
3. Backend calls OneSignal API to update `payment_status = failed` and increment `failed_payment_count`
4. User enters the relevant Journey segment automatically

This event-driven approach removes all manual work from the ongoing process.

---

Limitations of OneSignal for Dunning

OneSignal is not a purpose-built dunning tool, and you'll feel that in a few places.

No native Stripe or billing system integration. You're building and maintaining the webhook bridge yourself. Platforms like Braze have partner integrations that reduce this work significantly.

Journey logic is less sophisticated than enterprise alternatives. Complex branching — like routing users based on account value or payment method type — requires workarounds using multiple segments rather than inline conditional logic.

Email deliverability requires DMARC/SPF setup. If you're sending dunning emails through OneSignal, invest time in authentication setup. Transactional dunning email that lands in spam is functionally useless.

No built-in analytics for payment recovery rates. You'll need to track recovered revenue separately, cross-referencing OneSignal delivery data with your billing system.

For products under $30K MRR, these limitations are manageable. Above that threshold, evaluate whether a dedicated dunning tool like Recover or a more capable CRM integration makes sense.

---

Frequently Asked Questions

Can OneSignal send SMS for dunning in addition to push and email?

Yes. OneSignal supports SMS as a channel and you can include it in Journeys. You'll need to connect a Twilio account through OneSignal's SMS setup. For dunning, SMS is worth adding as a final-stage touchpoint for high-value accounts where push and email have not converted — not as a first contact.

How do I prevent recovered users from continuing to receive dunning messages?

Set an exit condition in your Journey based on a Data Tag update. When your billing system confirms a successful payment, fire a OneSignal API call that sets `payment_status = active`. OneSignal will remove the user from the failed payment segment, which triggers the Journey exit. Test this explicitly before going live.

Does OneSignal's free tier support Journeys?

Journey automation is available on paid plans. The free tier gives you access to manual segments and API-triggered notifications, which means you can build a basic dunning sequence using API calls from your backend — but you lose the visual orchestration layer. For a production dunning workflow, the Growth plan ($9/month as of current pricing) is the practical minimum.

What's the single highest-impact change for dunning recovery rates?

Timing the first message. The fastest recovery happens when the customer hears from you within one hour of a failed payment, before they've moved on mentally. Build your webhook → OneSignal API flow so the first notification fires within minutes of the failed charge event, not the next morning when a batch job runs.