subscription-push-lifecycle

Pushlane Subscription Price Increase Push Notifications

Use push to support a subscription price change without replacing store notices, inventing consent status or messaging the wrong subscriber cohort.

A subscription price increase push notification can help an affected customer understand what is changing and where to review the plan. It cannot replace the App Store or Google Play notice, collect consent on the store's behalf or prove which price a person will pay.

Price changes vary by storefront, billing period, current price, preserved-price status and consent rules. The safe workflow begins with the store's affected-subscriber data and ends at a destination that displays current localized terms.

This guide is an operational messaging framework, not legal advice. Confirm the current platform requirements and your obligations for every market before scheduling customer communication.

Treat the store notice as the source of truth

Apple's official subscription pricing documentation explains that an increase can either notify subscribers or require consent, depending on the subscriber and the change. Apple handles its required email, push and in-app communications. App Store Connect can also preserve the existing price for selected subscriber cohorts.

Google Play likewise distinguishes opt-in and opt-out price increases in its subscription documentation. Eligibility and notification periods differ by country, account standing and change type.

These rules can change. Do not encode a simplified threshold from a blog article into a Pushlane flow. Review the store dashboard and current official documentation for the actual change.

Your own push is supplemental. Its job can be to:

  • explain the product value connected to the plan;
  • direct the customer to current plan details;
  • show available support or plan-management paths;
  • remind a verified affected customer before a real deadline;
  • measure whether the explanation was understood.

It should never claim that consent was accepted, a price is preserved or cancellation is required unless the current account record proves that exact state.

Build the affected cohort outside the copy

Start with a subscriber export or server-side account record that identifies the actual affected cohort. Segment at least by:

  • store and storefront;
  • product and billing period;
  • current price cohort, including preserved pricing;
  • scheduled effective or renewal date;
  • whether the store reports notice-only or consent-required state;
  • current entitlement and auto-renew state;
  • locale and reachable push device.

RevenueCat webhooks remain useful for verified purchase, renewal, cancellation and expiration transitions. However, do not treat RevenueCat PRODUCT_CHANGE as a generic price-increase event. That webhook describes a customer's move between products. A developer changing a product's price is a different operation.

If Pushlane needs a flow entry, emit an explicit server-side product event only after your billing job has resolved the current affected cohort. For example:

subscription_price_change_notice_due
  properties:
    change_id
    store
    product_id
    effective_date
    consent_mode

Keep the localized amount and billing terms on the destination unless your send-time data can guarantee they are current for that subscriber. User attributes persist, so a stale price stored as an attribute can create a false notification later.

The segmentation guide explains why durable state, event context and delivery eligibility need separate treatment.

Give each message one job

Initial explanation

Send only after the store change is scheduled and the affected cohort is stable. Keep lock-screen copy neutral because the price and account status may be sensitive.

An update to your subscription plan

Review what is changing and the options available for your account.

The destination should show the current localized price, billing period, effective date, preserved-price status if relevant and a route to manage the subscription.

Value reminder

A second message is useful only when it points to benefits the customer already has and when the store's real notice or consent window is still open.

Review your plan before the next renewal

See your current benefits, updated terms and plan options.

Do not write "lock in your price" unless that option truly exists for the recipient. Do not invent a discount to prevent cancellation.

Support handoff

For customers who open help or express a real unresolved question, provide a direct support path. Push should not pressure someone who already reviewed or declined the change.

Need help with the plan update?

Review the details or contact support from your subscription page.

Recheck state immediately before send

A planned message can become wrong when the store change is edited, the user changes plans or billing state moves. Before every send, suppress when:

  • the change was cancelled or rescheduled;
  • the subscriber is no longer in the affected price cohort;
  • the current price is preserved;
  • the person already completed the intended review or consent action;
  • the subscription cancelled or expired in a way that makes the message irrelevant;
  • the user opted out of marketing push;
  • the destination no longer shows the promised details.

Use change_id as an idempotency key so the same notice job cannot enter twice after a retry. If one subscriber has several products, resolve eligibility per subscription rather than sending a blended claim.

Apple exposes price-increase status in StoreKit and App Store Server Notifications for supported cases. Its price increase status documentation is the primary contract for those states. Forward only statuses your server has actually received and mapped.

Coordinate channels without duplicating the store

The store may already send email, push and an in-app sheet. Your Pushlane message should add product context, not repeat the same alert on the same day.

Build a communication calendar from the official notice window, then choose the minimum additional contact needed. Frequency-cap price-change messages with other marketing flows, while allowing required operational surfaces to remain available.

Do not suppress or hide the store's consent interface to improve your own conversion metric. A Pushlane deep link can open an account page that explains the change and then hands off to the platform's supported subscription-management path.

Measure comprehension, not prevented cancellations

Useful operational metrics include:

  • affected subscribers successfully matched to a Pushlane identity;
  • reachable rate for that verified cohort;
  • sends and suppressions by reason;
  • plan-details page opened;
  • support path opened;
  • store consent status when the platform provides it;
  • renewals, cancellations and expirations after the change;
  • complaints about incorrect price or account claims.

Do not attribute every later renewal or cancellation to the push. Price changes, product value, store messages and customer circumstances all affect the outcome. If scale supports an eligible holdout, never withhold required information; test only a supplemental message after confirming that the store and in-app notice remain complete.

The goal is not to make a price increase feel invisible. It is to make the change understandable, route each customer to current terms and stop messaging as soon as the account state no longer supports the claim.

Pushlane Subscription Price Increase Push Notifications