Pushlane: Subscription Renewal Push Notifications

A renewal notification sits in an awkward place. The subscriber may appreciate a timely account update, but the same message can feel like a prompt to reconsider a purchase they were content to keep. The answer is not to hide the renewal or manufacture urgency. It is to make every notification useful enough to justify the interruption.

That starts with an accurate event model. RevenueCat's RENEWAL webhook tells you that an existing subscription renewed or that a lapsed subscriber resubscribed. It does not fire before an upcoming renewal. A reliable renewal program therefore separates post-renewal messages, which can use that webhook directly, from pre-renewal reminders, which need a future-date signal created by your app or backend.

This guide shows how to make that distinction in Pushlane, choose messages around customer needs, and avoid turning routine billing communication into an unwanted retention campaign.

Decide whether a push is needed at all

Not every renewal deserves another lock-screen interruption. Store receipts, account screens and email may already provide the required record. Push is useful when it adds something timely and actionable that those surfaces do not.

A push can earn its place when it:

• confirms that access continues and points to something newly available;
• helps a subscriber who deliberately asked for a renewal reminder;
• explains a failed payment and provides a route to manage billing;
• confirms that auto-renewal was restored after a cancellation;
• acknowledges a meaningful tenure milestone.

A generic message such as "Your plan renews soon" adds little. It interrupts the person, raises the question of cancellation, and offers no help. If the only purpose is to protect revenue by keeping the renewal out of mind, do not send it. Transparent retention comes from a product people still value, not from obscuring account state.

Apple's App Review Guidelines say push notifications must not be required for an app to function. They also require explicit opt-in and an in-app opt-out method when push is used for promotions or direct marketing. That makes the purpose of each message important. A billing status update and a promotional renewal offer should not be treated as interchangeable just because both mention a subscription.

Use the RevenueCat lifecycle as it actually exists

RevenueCat documents RENEWAL, CANCELLATION, UNCANCELLATION, BILLING_ISSUE and EXPIRATION as different lifecycle events. Each answers a different question.

RENEWAL means the transaction already happened. It can trigger a confirmation, a value recap or a next-step message. RevenueCat also notes that this event may represent a lapsed customer resubscribing, so copy should not assume uninterrupted tenure unless you have checked your own state.

CANCELLATION does not always mean access ended. For an ordinary voluntary cancellation, auto-renewal has been turned off while access can continue through the paid period. RevenueCat also uses cancellation events for refunds, so inspect the reason and current entitlement state before messaging.

UNCANCELLATION means auto-renewal was re-enabled before expiration. A short confirmation can reduce uncertainty: "Your membership will continue. No other action is needed."

BILLING_ISSUE means a charge attempt failed, not necessarily that access ended. Grace periods and store retry behavior matter. The helpful action is billing management, while the honest wording avoids claiming the account is already locked.

EXPIRATION means the subscription expired. That is the point for an access-state message or a carefully permissioned reactivation flow, not a renewal confirmation.

RevenueCat's current event types and fields reference is the source of truth for these meanings. Its webhook guide also warns that delivery is at least once, so event consumers must be idempotent. Pushlane deduplicates RevenueCat webhooks by event ID before they enter flows.

There is no pre-renewal webhook to wait for

This is the implementation trap behind many renewal campaigns. A future renewal is not a completed lifecycle event, so RevenueCat does not emit a generic "renewal approaching" webhook. The expiration_at_ms field describes the end of the transaction period, but receiving that field is not the same as receiving a new event shortly before that timestamp.

If you want a pre-renewal reminder, create the signal deliberately. Common approaches are:

1. Let the subscriber request a reminder in the app, then have your backend schedule a custom event such as renewal_reminder_due for the chosen date.
2. Maintain the next relevant subscription date in your backend from authoritative subscription state, then run a scheduled job that emits the custom event for eligible users.
3. Start a delayed flow from a known purchase or renewal only when the term is fixed and your flow can be cancelled or excluded when a later CANCELLATION, PRODUCT_CHANGE, SUBSCRIPTION_EXTENDED or billing-state change makes the schedule stale.

The third approach can drift when plans change, billing dates move or a grace period begins. Never calculate "monthly" as an unquestioned number of days and assume it will stay aligned.

Pushlane can trigger flows from your own tracked events as well as bridged RevenueCat events. Keep the names semantically precise. renewal_reminder_due means your system reached a planned reminder point. revenuecat.renewal means RevenueCat reported a completed renewal. Those two events should never share copy or analytics labels.

Build three separate renewal flows

One large flow with every billing branch is harder to audit and easier to get wrong. Start with three narrowly owned flows.

1. Requested pre-renewal reminder

Entry: your custom renewal_reminder_due event.

Eligibility: notification permission is available, marketing consent is appropriate for the message, the subscription is still active, auto-renewal is still enabled, and the reminder preference still exists.

Message: state the date, plan and available action without pressure.

Renews Friday

Your Annual plan is set to continue on August 14. Review your subscription anytime in Settings.

Deep link to a clear account or subscription-management screen. Do not deep link to an upsell paywall. The person already subscribes and came for account information.

2. Successful renewal and value continuation

Entry: revenuecat.renewal.

The default choice can be no push. Send one when there is useful context beyond a receipt, such as a refreshed allowance, a new training block, a new reporting period or a benefit the person can use now.

Your next plan is ready

Membership continues, and your new four-week training plan is ready to review.

This works because the destination is product value, not billing administration. It acknowledges continuity and helps the subscriber take the next meaningful action.

Use a branch on is_trial_conversion if you need different treatment for a first paid period. RevenueCat documents that field on renewal events. A trial conversion message should orient a new payer, while a routine renewal message should respect an established customer.

3. Renewal exception handling

Entry: revenuecat.billing_issue, with separate flows for revenuecat.uncancellation and revenuecat.expiration.

The billing-issue push should say what happened, what remains true, and what the person can do. Do not say "Your subscription ended" if the event only says an attempt failed.

We could not process your renewal

Your billing method needs attention. Review it in your subscription settings.

RevenueCat's billing issues and grace periods guide explains that access may continue during a configured grace period and that a successful recovery produces a renewal event. Suppress later reminders as soon as recovery arrives.

Write copy that protects trust

Renewal copy works best when it answers four questions quickly: What happened? When does it matter? What happens to access? Where can I manage it?

Use exact account language when you have reliable data. "Renews August 14" is better than "Renews soon." If a date or localized plan name is missing, use a neutral fallback rather than exposing an empty variable. Pushlane resolves user variables at send time and suppresses a message when a required value has no usable fallback.

Avoid vague loss framing. "Don't lose everything" is especially poor when customer data remains available or access continues until a later date. Describe the actual consequence. For a billing issue, that might be "Premium access may pause if billing is not updated." For a voluntary cancellation, it might be "You can keep using Premium through August 14."

Do not disguise marketing as service. "Your renewal is coming, upgrade now for 40% off" is an offer. Treat it as promotional, apply the correct consent, and make the offer terms clear. Apple's notification design guidance emphasizes timely, high-value information that people can understand at a glance.

Add exits before adding more messages

Every delayed renewal flow needs explicit reasons to stop. At minimum, stop or suppress when:

• auto-renewal was disabled;
• the product or billing period changed;
• the subscription expired or was refunded;
• a billing issue recovered;
• the user opted out;
• the planned date is now in the past or no longer matches authoritative state.

Pushlane honors marketing opt-outs at delivery. You should still model business exits in the flow because consent and subscription state solve different problems. A person can remain opted in while no longer belonging in a renewal sequence.

Frequency matters too. A pre-renewal reminder, a store receipt, an in-app banner and a post-renewal push can become four messages about one routine transaction. Inventory every surface before deciding what push adds. One clear message is often more respectful than a sequence.

Measure the customer outcome, not the tap

Push opens are diagnostic. They can reveal a broken deep link or unclear copy, but they do not tell you whether the renewal experience helped.

For requested reminders, track whether people keep the reminder enabled, visit account settings successfully, and avoid support contacts caused by surprise. For post-renewal value pushes, measure the product action named in the message, such as starting the new plan or viewing the refreshed report. For billing issues, measure recovery on a later successful renewal while accounting for store retries that may have succeeded without a push tap.

Do not call an ordinary renewal a campaign conversion. The renewal already occurred before a RENEWAL-triggered message was sent. Attribute only downstream behavior that the push could plausibly affect.

You can use Pushlane's A/B step for meaningful choices, such as a product destination versus an account destination, but keep the lifecycle outcome primary. The guide to A/B testing subscription push notifications explains how to choose stage-specific metrics without inventing significance.

Set it up in Pushlane

First, connect RevenueCat using a shared app user ID and authenticated webhook, following the RevenueCat and Pushlane integration guide. Then build narrowly scoped flows for the lifecycle events you actually receive. Use your own server event for any pre-renewal schedule, and reserve revenuecat.renewal for what it means: the transaction completed.

That event discipline produces better copy, cleaner measurement and fewer accidental messages. More importantly, it treats the subscriber as a person managing an ongoing purchase, not as a renewal metric to be nudged at any cost.