What the stores let you offer someone who cancelled

When a subscriber turns off auto-renew, both stores can send your server a notification about it. Most apps do nothing with that event. Apple and Google each give you several ways to put a cheaper price in front of that person later, but the tools are scattered, they have different rules about who is allowed to see them, and one of the most obvious ones quietly refuses to work on the people you built it for.

First, find out why they left

A lapsed subscriber is not one kind of person. Some people stopped paying because their card expired. They never decided to leave, and a discount is the wrong answer for them. The fix there is billing retry, plus the grace period both stores let you switch on so access continues while the store retries the card. Apple tells you about this with DID_FAIL_TO_RENEW, and Google sends its own grace-period and account-hold notifications. Read those before you spend a cent on discounts.

The people who did choose to leave split roughly into three groups. Some thought the price was too high. Some finished the job they subscribed for, like the trip, the exam or the launch. Some never got the app into their routine. A win-back price only helps the first group, and helps the second when the job comes back around. Neither store can tell these groups apart for you, so the targeting decisions below are yours.

Apple has four tools, and only one goes looking for the customer

Win-back offers are the newest, and they work on devices running iOS 18 and later. You set them up in App Store Connect as a free or discounted period on an auto-renewable subscription, and Apple decides who sees them using rules you choose: how long the person paid for, how long ago their subscription expired, and how long they must wait between redeemed offers. What makes them different is distribution. Apple can show an eligible customer the offer on the App Store itself and in their account's subscription settings, and StoreKit can show a win-back sheet inside your app on its own. App Store Connect also gives you a direct link in the form apps.apple.com/win-back/<id> for email. Apple's documentation asks you to check eligibility from your server before sending it; the subscription's renewal info lists the offers the customer qualifies for, best first.

By default a win-back redeemed outside your app completes there and then, and your app just receives a finished transaction the next time it runs. This setting is called Streamlined Purchasing. Turn it off and your app gets a purchase intent instead, which gives you a chance to ask the person to sign in before they pay. That matters if your entitlements are tied to an account rather than to an Apple ID.

Promotional offers are older and more flexible. Apple treats anyone with a current or expired subscription as eligible, and any extra rule is yours. Your server signs each offer before the app can present it, and each signature can be redeemed once. Use these when you want to pick the audience yourself, for example people who cancelled within a week of a price rise. The catch is that the person has to open your app to see the offer.

Offer codes are codes you hand out yourself. They come as one-time codes or as custom codes you name, can be redeemed in the App Store, through a redemption URL or in your app, and are limited to 10 active offers and a million codes per app per quarter. They suit email campaigns and support replies, where you want a specific person to get a specific deal.

Introductory offers are the fourth, and they don't help here. A customer only gets one per subscription group, so anyone who started on a trial has already used it.

Google leaves the targeting to you

On Play, a subscription offer has one of three eligibility types. New customer acquisition and upgrade are checked by Google. Developer determined is the one for win-backs, and Google's help page is blunt about it: Google Play does not evaluate any eligibility criteria. Your app decides who qualifies and applies the offer when it starts the purchase. Developer-determined offers also can't be bought outside your app, so they won't appear anywhere on the Play Store. A lapsed user sees one only if they reopen your app.

Play does do one thing without being asked. A user can resubscribe from the Play subscriptions center for up to a year after their subscription expires, and this is on by default. They get your normal price, not a discount, and the purchase arrives as a new subscription with a new purchase token. Your backend has to recognise it as a returning user rather than a stranger.

For anything outside the app there are promo codes, and the catch is in the small print. A subscription promo code gives a free period of 3 to 90 days, not a discount. One-time codes (up to 10,000 per subscription per quarter) can be redeemed by new, current or previous subscribers. Custom codes, the memorable kind you would put in an email subject line, can only be redeemed by users who have never subscribed. A COMEBACK code sent to your lapsed list on Play will fail for every single person on it.

Don't teach your subscribers to cancel

Any price you offer to people who left is a price your current subscribers would like too. If the win-back deal is permanent, generous and easy to find, some people will learn to cancel on purpose and wait for it. Three habits keep the deal from becoming your real price.

• Make it a period, not a new price. Three months at half price that then renews at the full price is a trial of coming back. A permanent discount is a price cut that only rewards people who left.
• Wait before offering. Someone who cancelled yesterday still has access until the period ends and may not have decided anything yet. Apple's eligibility rules let you require time since expiry. On Play, put the same delay in your own logic.
• Limit repeats. Apple's rules include a minimum gap between redeemed offers. Use it, and do the same in your own records for developer-determined offers on Play, so nobody can cycle between cancelling and redeeming every quarter.

Count win-backs on their own line

Returning subscribers flatter every chart they land in. Fold them into new subscriptions and your acquisition looks healthier than it is. Fold them into renewals and your retention looks better than it is. Both stores tell you which offer a purchase used. Apple puts the offer identifier on the transaction, and Play reports the offer on the subscription purchase. So there's no excuse to blend them. Track three numbers per offer: how many lapsed users saw it, how many redeemed it, and how many were still paying at full price one renewal after the discount ended. The third is the only one that tells you whether the offer earned money or just delayed a second cancellation.

If you're planning a win-back because you raised prices and lost people, the order of operations matters, since both stores have their own rules for moving existing subscribers to a new price.