Pushlane: Post-Purchase Push for Subscription Apps

The first hours after a subscription purchase are not a celebration campaign. They are a handoff from a billing decision to a product job. The person paid to accomplish something, and the next message should help them use what they bought.

A useful post-purchase push confirms access only when the subscription state is verified, points to one premium action and stops as soon as that action is complete. It does not send a receipt, ask for a review or introduce another upgrade.

This guide builds that flow in Pushlane using RevenueCat events and product activation signals.

Trigger from verified subscription state

RevenueCat defines INITIAL_PURCHASE as a new subscription purchase. Its current event reference also shows that period_type can be TRIAL, INTRO or NORMAL. A trial-start transaction and an immediately paid purchase therefore need different copy even when they share an initial purchase event in a store flow.

Pushlane bridges the webhook as revenuecat.initial_purchase and exposes properties including period type, product ID, store, environment, expiration timestamp and entitlement IDs when RevenueCat supplies them.

Start the paid welcome path only after checking the event you actually receive:

revenuecat.initial_purchase
  -> branch: is_production
  -> branch: period_type matches the paid path you designed
  -> branch: supported, reachable iOS user
  -> send or wait based on current session state

Do not fire a post-purchase flow from paywall_viewed, a button tap or a client-created purchase_completed event. Those events can describe intent or interface progress, but RevenueCat is the subscription source of truth.

For a trial that later becomes paid, verify which RevenueCat event and properties arrive in your project before reusing this path. RevenueCat documents trial conversion within renewal flows, while Pushlane also accepts mapped trial-specific webhook types where present. Build on an observed catalogue event, not an assumed name.

Decide whether a push is needed at all

If the person is still in the app and the premium experience is ready, use the interface. A push that arrives seconds after purchase can duplicate the confirmation screen and interrupt the next action.

Use a post-purchase push when it performs a job outside the active session:

• the person purchased and left before completing premium setup;
• a premium process finished after the app moved to background;
• the first useful action belongs at a later natural time;
• another device completed the purchase and this device needs a clear access handoff.

Do not send merely because the event exists. Branch on current activation state or wait until the session has ended. The best immediate post-purchase experience is often no push.

Define one premium activation event

Choose the first action that demonstrates paid value. It should be a completed outcome, not exposure to a screen.

Examples include:

• first_premium_workout_completed;
• first_advanced_report_exported;
• offline_pack_downloaded;
• first_premium_lesson_completed;
• automation_rule_activated.

Write the definition as a sentence: "A new subscriber experiences premium value when they _____." If the team cannot agree, a notification sequence will not resolve the ambiguity.

Track setup milestones only when they determine the next action. plan_selected or account_connected can help a flow branch, but they are not automatically the final outcome.

Build the smallest helpful sequence

A good first version has one push and one conditional reminder.

verified paid purchase
  -> wait until the active session ends or a justified use moment
  -> exit if premium activation already happened
  -> send: one direct premium action
  -> wait for the product's natural cycle
  -> exit on activation, refund-related state, expiration or opt-out
  -> optional send: remove a different blocker
  -> exit

The second message must add new help. Repeating "Try Premium" after the person already paid is not only weak, it signals that the product does not know their state.

For a training app, the first message might lead to plan creation. A later message can lead to the first scheduled session only if the plan exists and the workout is still relevant. For a finance app, the first message might open account connection, while the second explains a specific supported data source.

Do not choose "24 hours" because the article title or campaign template suggests it. Choose delays from the product's normal use cycle, and state the rationale before reviewing results.

Write copy that confirms access through action

The notification can acknowledge the purchase briefly, then focus on what the person can do.

Premium is active

Build your first weekly plan with the advanced training tools.

For a saved task:

Your full report is ready

Open the category trends now included with Premium.

For an unfinished setup:

Finish setting up offline access

Choose the lessons you want available without a connection.

Avoid "Welcome to the family" when no product action follows. Avoid asking for an App Store review immediately after payment. The person has not had time to evaluate the paid experience.

Do not quote a price, renewal date or entitlement that you cannot resolve accurately at send time. The purchase destination and account screen should display billing terms from the authoritative store state.

Deep link beyond the premium home screen

The tap should open the action named in the message. Preserve authentication and unfinished work where possible.

Test at least these states:

• app installed and logged in;
• app terminated;
• session expired and login required;
• purchased on another device;
• entitlement still syncing;
• requested content no longer available.

If access has not synced yet, show a recoverable loading state and refresh RevenueCat customer information. Do not display another paywall to a verified purchaser because the local cache is stale.

RevenueCat's customer identity guide explains how custom App User IDs support access across devices. That same stable ID should be passed to Pushlane so the webhook reaches the correct APNs registration.

Add stop conditions for changed subscription state

Product activation is the main exit. Subscription state changes also matter.

Stop or reevaluate the sequence on:

• a refund or cancellation state that removes access immediately;
• revenuecat.expiration;
• a product change that makes the promised feature unavailable;
• logout or identity change;
• explicit marketing opt-out;
• loss of a valid APNs device.

RevenueCat says cancellation does not always mean immediate expiration, and refund behavior depends on the event reason. Pushlane does not currently expose cancel_reason in flow properties. Keep generic branches conservative, and use a validated server event if cause-specific behavior is required.

A renewal should not restart first-purchase onboarding. Use a separate renewal-value flow only when there is a real annual or periodic product job, as explained in subscription renewal push notifications.

Coordinate with onboarding and trial flows

New subscribers may still be in general onboarding. Define precedence so two flows do not send competing next steps.

• Product onboarding owns setup required for everyone.
• Trial onboarding owns paid-value discovery before a charge.
• Post-purchase onboarding owns the first premium action after verified paid access.
• Renewal messaging owns continued value at a later period boundary.

One product event can end more than one sequence. If first_advanced_report_exported proves both general activation and premium activation, exit both flows rather than allowing each to send a congratulatory follow-up.

Use a contact policy as a final guard, not as the only coordination mechanism. Frequency caps prevent overload, but explicit exits prevent stale messages.

Localize the action, not only the sentence

Pushlane can select localized push content at send time from the user's locale attribute. Translate the product term, time context and fallback copy. Verify that the deep-linked screen is available in the same language.

Variables should have natural fallbacks:

Continue your {{ plan_name | premium plan }}

Do not insert raw product IDs or entitlement codes into customer copy. Use a user-facing plan name stored as a validated attribute, or write copy that does not require the variable.

Test the full state transition

Use distinct sandbox accounts and verify:

1. A paid initial purchase enters the flow once.
2. A trial-period initial purchase takes the trial branch, not paid copy.
3. A sandbox event is blocked from the production send path.
4. Activation during the first wait cancels the message.
5. Activation after the first push cancels the reminder.
6. A missing APNs device records a suppression.
7. The same user on a second device resolves to the intended account.
8. Logout prevents a shared device from receiving the previous user's message.
9. A stale local entitlement refreshes instead of showing a second paywall.
10. Every deep link works from a terminated app.

RevenueCat's webhook dashboard test verifies authentication but does not reproduce this lifecycle. Use a real sandbox transaction for the state machine.

Measure premium activation first

The primary outcome is completion of the defined premium activation event within a stable window. Report purchase count separately because everyone entering this flow has already purchased.

Diagnostic measures include:

• eligible verified purchases;
• no-push cases because the user activated in-session;
• sends and suppressions;
• notification interactions;
• deep-link success;
• premium activation after entry;
• time from purchase to activation;
• notification opt-outs and support contacts;
• early cancellation or refund state, without claiming the push caused it.

To estimate incremental effect, preassign an eligible holdout before the first possible send. Include people who activated without a push in the analysis. Otherwise the flow can look successful merely because it targets purchasers who were already likely to use the product.

Turn payment into product value

The post-purchase moment is successful when the message becomes unnecessary. A subscriber who completes premium activation in-session should never receive the reminder. A subscriber who needs help should get one direct path to the value they purchased.

Start with the verified RevenueCat event, one product activation exit and one real-device iOS test. Add a second message only after you can name the distinct blocker it solves.