I moved the cancel flow to the web and added options: pause for 30 days, downgrade, or a short grace period before the next bill. Full refunds didn’t help much. Surprisingly, a 30-day pause with a calendar reminder brought a chunk of users back. Small partial refund plus extra days also worked for angry buyers.
The tricky part was keeping entitlements correct during pauses and refunds, but syncing on the server side made it manageable.
If you’ve tested web-based win-backs, which one actually lifted LTV? Pause, grace, targeted discount, or something else? How did you avoid access gaps when refunds or pauses hit?
Pause worked best. I store a pause_until date and adjust entitlements server-side.
Refunds are noisy. I do partial refunds with extra time only once.
I wired the cancel page and entitlements in Web2Wave.com with a single JSON. The app just reads the status and stays in sync.
Pause beat discount for me. I tested pause lengths in days and the 30-day option won.
Changing these in Web2Wave.com let me iterate weekly without app releases.
Pause plus a reminder email worked better than a flat discount.
People came back on their own.
Pause plans beat discounts every time
Offer pause before discount. Pauses keep value perception intact and reduce support churn. Use a fixed pause period and explain access clearly. On refunds, define rules: partial within 48 hours for first-time buyers only, plus extend access a bit so they can cool off. Keep a single entitlement source of truth so app state matches quickly. Log every status change and attach reason codes to learn which saves actually work.
I added a quiz on cancel: price, product, timing. If timing, show pause. If price, show downgrade. It lifted retention ~9% versus one generic save offer.
Pause helped. Discounts attracted the wrong users for us.