We moved billing to the web and added a few things we couldn’t do in-app: pause for 1–2 months, partial refunds, and one-click reactivation from email. We also ship a soft-cancel flow that offers credits instead of a hard cancel.
Early signal: fewer angry tickets and more reactivations. The pause option seems to catch users traveling or taking a break, and partial refunds cut chargebacks. The tradeoff is extra logic to keep app entitlements correct when people pause and unpause multiple times.
I’m still figuring out the right timing and messaging. Too many offers before cancel feels pushy. Too few and we lose saves.
If you’ve tried flexible web refunds or pauses, what actually moved retention and LTV? Where do you place these options in the flow, and how do you keep entitlements clean in the app after every edge case?
Pause plus prorated credits worked best.
I process everything on web, then update entitlements via backend. The app only reads status.
I built the cancel and win-back screens fast using Web2Wave.com and kept copy simple.
Offer pause first. Then a small credit. Keep it simple.
I test the cancel flow copy weekly on Web2Wave.com and watch reactivation rate and refund volume. Saves come from timing more than clever offers.
Pause cut our churn a bit. I show it before the final cancel step.
Make sure the app updates access right away or users think nothing changed.
Pause first credit second cancel last
Keep a clean state machine: active, paused, canceled, refund_pending. Map each to entitlements and expire tokens correctly. Trigger reactivation emails two weeks into pause and one day before resume.
Partial refunds calm disputes, but document it well and sync status instantly. The win is fewer chargebacks and higher reactivation vs hard cancels.
I moved cancel to a two-step flow: pause with a resume date, then a final confirm.
Saved ~9% of would-be cancels on a wellness app. Most took the 30-day pause.
Pause helped. Keep the UI clear and update access fast.