The 4 Subscription Push Flows Every RevenueCat App Should Have

Most subscription apps treat push as a marketing channel: a campaign here, a discount blast there. The apps that retain well treat it as infrastructure. They wire push directly to the subscription lifecycle, so the right message fires when a trial starts, a charge fails, or a subscriber cancels, without anyone touching a dashboard that day. If you run your subscriptions through RevenueCat, four flows cover the moments where revenue is actually won or lost. This post walks through each one: the trigger event, the steps and timing, the exit conditions, and one copy example you can adapt.

Why subscription events, not app events, should trigger these flows

You can build engagement pushes off in-app events, and you should. But the four flows below hinge on billing state, and billing state lives on the server. The user's phone does not know that a renewal charge failed overnight, or that a cancellation was processed from the App Store settings screen, entirely outside your app.

RevenueCat already tracks all of this. Its webhooks fire a server-side event for every lifecycle transition: trial started, trial converted, billing issue, cancellation, expiration, renewal. Pushlane consumes those webhooks directly and matches each event to a device through the shared app user id, so there is no client-side purchase tracking code to write. You point RevenueCat's webhook at Pushlane, call identify with the same user id you pass to RevenueCat, and every flow in this post becomes a trigger away. The full wiring is covered in our RevenueCat push notification integration guide and in /docs/revenuecat.

One honesty note before the list: Pushlane's delivery through APNs on iOS is proven end to end. On Android, the drop-in client registers FCM tokens, but we do not claim end-to-end Android delivery today. If your revenue is mostly iOS (true for many subscription apps), you are in the proven path.

Flow 1: Trial nurture

This is the highest-leverage flow in the list, because the trial window is short and the user's intent is at its peak. Someone who starts a trial has already decided your app might be worth paying for. The flow's job is to get them to the moment where the value is obvious before the trial clock runs out.

Trigger event: trial_started

Exit conditions: trial_converted (they paid, stop selling), cancellation (they turned off auto-renew, a different conversation), or the trial expires.

Steps and timing:

1. Within the first hour: point them at the single action that best predicts conversion in your app. Not a tour, one action. If you do not know what that action is yet, pick your best guess and measure it in your app.
2. Day 2: surface a second feature or a depth cue. The goal is to widen what they would lose by not subscribing.
3. One day before the trial ends: an honest heads-up. Users who feel ambushed by a charge refund and churn; users who were reminded and stayed are your best subscribers. Say when the charge happens and what they keep.
4. A few hours before expiry: the last call, only if they have not converted or cancelled. Keep it factual, not desperate.

Copy example (day-before reminder):

Your trial ends tomorrow. Your saved routines and your 6-day streak carry over the moment you subscribe. Nothing to re-do.

The exit condition is what makes this a flow rather than a scheduled campaign. The moment RevenueCat fires trial_converted, the user leaves the flow and never sees the last-call push. Nobody who already paid should ever be asked to pay.

Trial nurture deserves more depth than one section can give it. We wrote a dedicated breakdown of the trial-to-paid push notification sequence with step-by-step copy for each message.

Flow 2: Billing failure recovery

This is the least glamorous flow and the one most apps skip. It recovers revenue from people who never decided to leave. A card expired, a bank declined, a payment method got rotated. The subscriber still wants your app; the charge just failed.

Both stores give you a recovery window. Apple offers a billing grace period for auto-renewable subscriptions (see Apple's subscription documentation), and Google Play has its own grace period and account hold states (see Play Billing subscription states). During grace, the store retries the charge and the user can keep access. When grace ends, the subscription expires and you are into win-back territory, which converts worse because the habit is broken.

That framing matters: the grace period is a race against involuntary churn. Every day that passes without the user fixing their payment method is a day closer to an expiration they never chose.

Trigger event: billing_issue

Exit conditions: renewal (the retry succeeded or the user fixed the card, stop immediately) or expiration (grace ran out, hand off to the win-back arc).

Steps and timing:

1. Immediately: tell the user plainly that a payment failed and that their access is safe for now. Most users have no idea a charge bounced; the store's own email often lands in a folder they never open. A push reaches them where the app already lives.
2. 48 hours later: a second nudge if the issue is still open, with the fix spelled out (update the payment method in App Store or Play settings).
3. Near the end of the grace window: the stakes message. Access is about to pause, and here is what pauses with it.

Copy example (first message):

A payment for your subscription did not go through. Your access is still active. Update your card in your App Store settings to keep it that way.

Notice what this copy does not do: it does not blame, and it does not fake urgency. The urgency is real, so plain language carries it.

Flow 3: Cancellation save and win-back

First, a distinction that trips up a lot of teams: in RevenueCat's model, cancellation and expiration are different events. A cancellation means the user turned off auto-renew. They still have access until the end of the period they paid for. Expiration is when that access actually ends. Your messaging has to respect the difference, because a "come back!" push sent to someone who still has full access reads as broken.

Trigger event: cancellation, with a second arc picking up at expiration.

Exit conditions: the user resubscribes or uncancels at any point (exit instantly), or the win-back arc completes and the flow ends. Respect the ending: a win-back arc that never stops is spam.

Steps and timing, save arc (while they still have access):

1. Within a day of cancelling: acknowledge the cancellation and ask what went wrong. This is also the moment your best subscribers-by-accident surface: people who cancelled to avoid a charge while deciding, or who cancelled the wrong app.
2. A few days before access ends: a factual reminder of what they still have and when it stops. No guilt, just the date and what disappears.

Steps and timing, win-back arc (after expiration):

3. Around 3 days after expiration: a light touch. Something changed, something new shipped, or simply what their account still remembers.
4. Around 2 weeks after: a stronger reason to return. New content, a feature they never tried, progress waiting for them.
5. Around 6 weeks after: the last message of the arc. After this, stop. If they come back, it will be on their own schedule.

The exact spacing is a starting point, not a law. Measure re-subscription timing in your own app and stretch or compress the arc to match.

Copy example (save arc, first message):

Your plan stays active until August 2. If something was not working, tell us in the app, we read every note. If you cancelled by mistake, one tap in your settings turns renewal back on.

Flow 4: Renewal and engagement for paying users

The first three flows react to problems. This one prevents them. Subscribers who use the product renew without thinking about it; subscribers who drift open the renewal receipt and start doing math. The goal of this flow is simple to state: keep paying users active enough that renewal is a non-event.

Trigger event: trial_converted or the initial purchase, and re-anchored by each renewal.

Exit conditions: cancellation or billing_issue (the user moves to Flow 3 or Flow 2, which take over the conversation), or opt-out. Pushlane is consent-aware end to end, so a user who opts out of push simply stops receiving the flow, no code on your side.

Steps and timing:

1. First week after converting: reinforce the decision. Show them something the free tier never gave them, so the subscription immediately has a face.
2. Ongoing, spaced by weeks rather than days: usage-anchored nudges. Milestones they hit, features they have never opened, content added since their last session. Paying users have granted you attention; spend it carefully.
3. When engagement drops: this is where audience segments earn their keep. Build a segment of subscribers who have gone quiet and give them their own branch with a stronger re-engagement message, instead of blasting the whole paying base.

Copy example (milestone nudge):

You logged 20 sessions this month, your most yet. Your monthly recap is ready in the app.

Do not send renewal-date warnings to healthy, active subscribers by default. The stores handle legally required notices, and for an engaged user your reminder mostly plants the idea of cancelling. If you believe proactive reminders build trust in your category, test it as a variant rather than assuming either way: Pushlane supports A/B testing inside flows, so you can split a step's copy or presence and watch what your own users actually do.

Setting these up in Pushlane

You could build all four flows from scratch in Pushlane's visual flow builder, and the building flows guide shows you how: trigger, timed steps, branches, exits, all on a canvas. But you do not have to start from a blank canvas. Pushlane ships flow templates that map directly onto the four flows in this post, wired to the RevenueCat events described above. Pick the template, adjust the timing to your trial length and your grace period, and edit the copy. If writing eight variants of a billing reminder is not how you want to spend an afternoon, AI-generated push copy can draft them and you keep editorial control.

Setup cost is deliberately low. The iOS SDK installs via Swift Package Manager, and Expo, React Native, Flutter, and Android each get a zero-dependency drop-in client: one pasted file, no npm package to trust. If an AI coding agent does your integrations, Pushlane also supports agent-driven install via MCP. For a wider look at what a push stack should do for a subscription business beyond these four flows, see push notifications for subscription apps.

Start with one flow this week

You do not need all four on day one. Start with the flow closest to your current leak: trial nurture if conversion is the problem, billing recovery if you have never once messaged a failed charge (most apps have not). Each flow is one trigger, a handful of timed steps, and honest exits.

Pushlane has a free tier, and the RevenueCat webhook plus one pasted client file is enough to get your first flow live. Start free at https://pushlane.io.