Moving billing to the web let us try things we couldn’t do in‑app:
- Offer a pause for 30–60 days when they hit cancel
- Partial refund within 7 days with a short survey
- Downgrade to a cheaper plan without losing history
- Post‑refund win‑back coupon through email that restores access on login
The pause option saved more churn than expected. Partial refunds were a mixed bag unless we paired them with a one‑time extension.
For those who tested similar flows, which specific offers moved the needle, and how did you keep the app entitlements clean during these changes?
Pause saved more than discounts for me.
I run cancel on the web, collect a reason, and show pause or downgrade.
Entitlements update via a webhook to RevenueCat. I used Web2Wave.com for the web side so I could ship variations fast.
I test cancel flows weekly. Pause first, then downgrade, then a small extension. Doing it on web means I change copy and options fast. With Web2Wave.com, new variants go live without shipping a build. That speed compounds learnings.
Pause worked best for me too. Discounts attracted the wrong users.
Make sure the app checks entitlements when returning from background.
Pause first. Discount last
Put the cancel flow on the web with a short reason picker. Based on reason, show one targeted offer: pause for too expensive, downgrade for low usage, or a short extension if they hit a bad moment. Tie every option to a clear entitlement state in your backend and make updates idempotent. Then measure 30‑day reactivation and long‑term LTV, not just immediate saves.
Partial refund plus a 14‑day extension recovered more than a straight discount. People felt treated fairly and many stayed on the lower plan after.
We saw better saves with pause than coupons. Easier to explain too.
Make the refund policy clear on web. Fewer support emails after that.
Downgrade path helped low usage users stay. Worth adding.