Pause subscription option for SaaS: when a pause beats a cancel

In short: A pause option beats a cancel when the merchant's reason for leaving is their calendar rather than your product: a seasonal store, a store on Shopify's Pause and Build plan, a brand between launches. Design it as a fixed-length plan state where billing stops, data and settings stay, the storefront embed goes quiet and a reminder goes out before the resume date. Shopify App Pricing has no pause, so on Shopify the pause is a free plan downgrade with your own app state on top. Stripe has a real one. Measure it by the share of pauses that resume and are still paying 60 days later.

When does a pause beat a cancel?

The merchants who should pause are the ones who will have a use for your app again on a date you can both name.

Seasonal stores. A swimwear brand in October, a costume store in November, a gifting brand in February. Their affiliate programme or creator outreach has nothing to work with for three months, and a $79 a month line on the Shopify bill with nothing next to it is the first thing they cut.

Stores on Pause and Build. Shopify's pause and build documentation says that on a paused store customers can view products but cannot buy, checkout is deactivated across all sales channels, and "all your apps remain active after you pause your store". The same page advises merchants to uninstall apps with recurring charges so they are not billed for them while paused. Read that from the app's side: the day a merchant pauses their store, Shopify tells them to uninstall you. If you have no pause, that is exactly what happens.

Brands between launches. A product-drop brand, a creator with one hero product, a store that runs two campaigns a year. Same shape, less predictable dates.

Shopify's updated uninstall reasons, in effect since April 2026, require merchants to pick one of eight reasons before removing an app, and two of them, "Store is closing or pausing" and "Not using app now", describe exactly these merchants. Your Partner Dashboard will tell you how many of your uninstalls they account for.

A pause does not beat a cancel for a merchant who left over price, a missing feature or a competitor. "Too expensive" wants a downgrade. "Missing a feature" wants the feature. Offering a pause to those merchants delays the cancel by three months and counts it as a save in the meantime. I cover matching one offer to each reason in the guide on cancellation flows.

How should you design a pause?

A pause is a plan state, not a discount, and the design questions are about what stays on.

Element	During the pause	On resume
Billing	Stops at the end of the current paid period	Restarts on the resume date, same plan, no new trial
Length	Fixed, chosen by the merchant from one, two or three months, with a resume date shown	Can be extended once from inside the app
Login and data	Everything readable: reports, affiliate list, creator conversations, settings	Nothing to re-enter
Storefront embed	Off, so no widget shows a dormant programme to shoppers	Turned back on by the app, or by a deep link to the theme editor if the merchant deactivated it
Outbound activity	Stopped: no affiliate emails, no creator messages, no review requests	Restarts only after the merchant confirms
Reminders	One, two weeks before the resume date, from a named person	A confirmation on the day, with what will switch on
Data retention	Full, for the pause plus a stated grace period	Unchanged

Four rules from designing this kind of state.

Make the length fixed and the date visible. An open-ended pause is a cancel that has not been admitted. The merchant picks a month, the app shows the date, and the reminder goes out before it. If they need longer, they extend once, from inside the app, and the date moves.

Turn the embed off, keep the theme setting on. If your app renders through a theme app extension, the merchant activated the embed in the theme editor and can deactivate it there. During a pause the app should render nothing from its side, so a stale referral widget does not sit on the storefront, while the merchant's theme setting stays as it was. Then resume is a flag in your app rather than a trip back to the theme editor. If the merchant uninstalls instead, the blocks are removed from the theme and resume becomes a reinstall and a reactivation.

Put the pause on the plan page, not only in the cancel flow. A merchant who knows the season is ending should be able to pause from the same place they would upgrade, without going through a cancel.

Say what happens to data in one sentence, in the pause screen and the confirmation email. "Your affiliate list, links and reports are kept in full while paused and for 90 days after." The number is yours to choose. Stating it is not optional.

Pauses also change what your churn signals look like. A paused account produces no data on purpose, so mark it as paused in the health score and exclude it from the data-stopped alert until the resume date.

What does Shopify App Pricing support for pausing a subscription?

Nothing called a pause, and it is worth being precise about what the platform does offer, because a design that assumes a pause state will hit the billing API and stop.

Shopify's App Pricing documentation lists recurring plans as "free, monthly, yearly, or monthly-with-yearly-discount", plus usage-based and combined plans, defined in the Partner Dashboard. It describes a downgrade to a free plan as a change that "takes effect at the end of the billing cycle", and it has no mention of pausing, suspending or putting a subscription on hold. The AppSubscriptionStatus enum has ACTIVE, PENDING, CANCELLED, DECLINED, EXPIRED and FROZEN. FROZEN is "on hold due to non-payment" and "re-activates after payments resume". It is Shopify's state, triggered by a failed store bill, not something your app can set for a seasonal merchant. CANCELLED is a terminal state.

So on Shopify, the pause is a workaround built from a free plan:

1. Create a free recurring plan in the Partner Dashboard, named plainly, such as "Paused". A free plan is a supported plan type.
2. When the merchant chooses to pause, move them to that plan. Shopify treats it as a downgrade that takes effect at the end of the current paid period, so they get the rest of what they paid for.
3. Set a paused state in your own database with the resume date, and gate the embed, outbound activity and features on that state rather than on the Shopify plan.
4. On the resume date, show the merchant their previous plan with one button. Resuming means approving a new subscription in the Shopify admin, which is a step you cannot skip, so the reminder email should say that.

One detail to check. If you have a public free plan for other reasons, make the paused plan private, which Shopify App Pricing supports, so merchants do not pick it as a way to use the app for nothing. How the rest of the plan ladder should be structured is in the guide on Shopify app pricing plans.

If you bill outside Shopify, for example a TikTok Shop seller tool on Stripe, the platform has a real pause. Stripe's pause subscriptions documentation says a paused subscription moves to the paused status, invoice generation stops until you resume, Stripe sends customer.subscription.paused and customer.subscription.resumed webhooks so you can de-provision and re-provision access, and the subscription must use flexible billing mode. It also notes that subscribers cannot pause from the customer portal themselves, so the pause button still has to be in your product, and that a scheduled pause and resume is available if you want the resume date handled by Stripe.

How do you measure whether pauses come back?

The risk with a pause is that it turns churn into a number you stop counting. Measure it so it cannot.

• Resume rate. Of pauses whose resume date passed, the share that are on a paid plan 30 days after that date. This is the headline.
• Net resume rate. The share still paying 60 days after resuming. A merchant who resumes, gets one invoice and cancels was a delayed churn, and this number catches it. It mirrors the net save rate in the cancel flow guide.
• Pause-to-cancel. The share of pauses that end in an uninstall or cancel, including the ones that extend twice and go quiet. Count a pause that passes its resume date plus 30 days with no action as a cancel, in your churn number, on that date.
• Extension rate. If most pauses extend, the lengths you offer are wrong, or the merchants pausing are not seasonal.
• Pauses by reason. Seasonal and store-paused should resume at a high rate. If "too expensive" merchants are being offered pauses and resuming at a low rate, the offer is being matched to the wrong reason.

I do not have a benchmark for resume rates that I would trust. A starting rule: if fewer than half of pauses resume and pay a second invoice, the pause is working as a slower cancel, and the fix is usually a shorter maximum length and a stricter match to the reasons that deserve it.

Report paused MRR separately from active MRR and from churned MRR, every month. A pause is not retained revenue until it resumes.

Where to start

1. Count last year's uninstalls tagged "Store is closing or pausing" or "Not using app now", and the MRR they carried. That is the case for the build.
2. Decide the lengths, the grace period and the one sentence about data, and write them into the pause screen before any engineering.
3. On Shopify, create the private free "Paused" plan and the paused state in your app. On Stripe, wire the pause endpoint and the two webhooks.
4. Put the pause on the plan page and as the offer for the "not using it right now" cancel reason, and nowhere else.
5. Set up the resume rate and net resume rate reports before the first merchant pauses, with paused MRR as its own line.