Shopify Subscription Model: How to Set It Up Step by Step

What does a shopify subscription model actually contain?

A shopify subscription model is not a plugin you switch on. It is a bundle of decisions that end up as fields on a selling plan: how often the product ships, when the card is charged, what the subscriber saves, how stock is held, and what happens when something goes wrong. The first four get attention at launch. The last one, what happens when something goes wrong, decides whether the base still exists in month six.

This guide differs from the app roundups and the “start a subscription business” posts that rank for the same phrase in one respect. It gives the field values in the order you set them, then spends real time on the failed-payment and exit path, which most setup guides skip because it has no screenshot-friendly toggle. If you want the box-and-curation angle instead, read how Shopify subscription boxes work. If you are comparing vendors, the subscription app comparison is the better start.

The guide is written for operators running $3M+ in revenue on Shopify Plus or a paid subscription platform. It is not for a store still deciding whether anyone wants to reorder its product; a schedule cannot create a habit that does not exist. It is also not for brands that want subscriptions as a discount-code trick with no plan for the second charge. Those brands get a spike in month one and a cliff at the first renewal.

Selling plans sit underneath whether you call it a subscription model ecommerce teams run themselves or a subscription model Shopify supports natively: selling plans underneath, an app or the native subscriptions feature on top.

What do you need in place before you configure anything?

Four things need to exist before any setting is worth choosing.

A payment gateway that supports stored payment methods for subscriptions. Not every gateway and payment method supports recurring charges from a vaulted token. Wallets, buy-now-pay-later options and some regional methods may be excluded from subscription checkout. Check your gateway’s and your subscription platform’s documentation for what is supported, and decide what to do for a shopper whose preferred method is not.

A replenishment interval you can defend. Consumable products have one: a 30-day supply is a 30-day plan. Write the interval next to each SKU, and note where it is an estimate. That number sets the default frequency, and a wrong default is the most common cause of a subscriber’s first skip.

A margin figure per cycle. Take price, then subtract product cost, fulfilment, packaging, payment fees and expected support. That is the number a discount comes out of. If finance has not agreed how to calculate it, stop and agree it first.

An owner for failure. Someone has to own declined cards and cancellations, whether that is retention, lifecycle or support. If the answer is “nobody yet”, the model will launch and leak.

How do you set up a shopify subscription model in seven steps?

The steps run in dependency order. Frequencies inform discounts, discounts inform billing choices, and all three feed the retry and exit rules. Working backwards from the theme or the app UI tends to produce a model that looks finished and behaves badly.

Step 1: Choose which kind of subscription you are selling

Three types cover almost everything, and each behaves differently once live.

Take from the table that the model type decides what a skip is worth. Replenishment tolerates skips because the customer still has product at home. Curation and access do not, because the subscriber pays for the surprise or the perk.

Most Shopify operators at this revenue level are running replenishment, sometimes with a bundle or curated first order. Pick one primary type for launch. A store that mixes all three in one plan group ends up with portal copy that is wrong for two of them.

Step 2: Write the selling plan groups

A selling plan group is the container. Inside it, each selling plan is one way of buying: for example, “Deliver every 4 weeks” and “Deliver every 8 weeks”. Products are attached to the group, and the customer picks a plan on the product page.

Group by behaviour rather than by category. Two products with the same replenishment interval and discount rule can share a group. A large pack that ships every three months should not share one with a monthly item, even if both are in the same collection, because the group’s plan names are what the subscriber sees in the portal.

Name plans in the subscriber’s language: “Every 4 weeks”, not “SP-MONTHLY-01”. Those names appear in checkout, emails and the customer account. A short, plain naming convention also saves support from decoding what “Plan B” meant a year later.

Offer the natural interval plus one shorter and one longer. Every extra plan is another forecast line, another portal option and another question for support.

Step 3: Set the discount and decide how long it lasts

The pricing policy on a selling plan takes an adjustment type (a percentage off, a fixed amount off, or a fixed price) and a value. Some platforms let you apply it to the first cycle only, or until a set number of orders, then revert to full price.

Work the arithmetic before choosing. In this illustrative example, a product sells for $60 and leaves $33 of margin after cost, fulfilment and fees. In the same illustrative example, with invented numbers, a 15% subscription discount takes the price to $51 and the margin to $24. In those illustrative, invented numbers, margin per order falls by more than a quarter, so a subscriber would have to place about 38% more orders than a one-off buyer before the discount pays for itself. The exact break-even depends on your own numbers, which is why the arithmetic matters more than the percentage.

Two decisions follow.

Permanent or temporary. A permanent discount is simple and keeps the offer clear. A temporary one protects margin but creates a price step at the renewal, and that step is a cancellation trigger. If you use one, say so at checkout and in the first renewal reminder.

Whether it stacks. Confirm what happens when a subscriber arrives with a site-wide code, a bundle offer or a loyalty reward. Discount logic that treats subscription line items differently is a common source of “I was charged the wrong amount” tickets. Test each combination on a real cart, not in the settings screen.

Step 4: Set billing timing and inventory behaviour

Four fields carry the weight here.

Billing policy. This is the interval and the number of cycles. Set a minimum number of cycles only if you sell something with a real commitment, such as a device with a consumables plan. A minimum term on a routine replenishment product raises cancellation friction and reviews with it. Maximum cycles suit fixed-length programmes, such as a course of product.

Delivery policy. This is the shipping interval. It is normally the same as billing for pay-per-delivery. It diverges for prepaid, where the customer pays for several deliveries at once.

Pay-per-delivery or prepaid. Pay-per-delivery is the default for consumables: low entry price, one charge per shipment, and a billing event every cycle that can fail. Prepaid collects cash earlier and removes most renewal failures, but it raises refund exposure and the first-checkout price. Which suits you depends on the price point and on how much you trust your retry path, which is Step 5. See why supplement subscribers cancel at month three for what happens when the first renewals are the weak point.

Inventory policy. Decide whether stock is reserved when the subscription is sold or when the order is fulfilled. Reserving at sale ties up inventory for shipments weeks away and can make a popular SKU look out of stock. Reserving at fulfilment keeps availability honest but risks an order you cannot ship. Pair whichever you pick with a written out-of-stock rule: skip, substitute or delay.

Step 5: Configure the failed-payment retry path

The failed-payment path is the step most teams get wrong, and it earns a longer explanation than the others.

Every renewal is a card charge made when the customer is not present. Some of those will fail: expired cards, insufficient funds, issuer blocks, changed billing details. The subscriber did not decide to leave. Stripe reports that about 25% of lapsed subscriptions trace to a payment failure (Stripe, vendor-reported), and Paddle and ProfitWell put involuntary churn at 20–40% of all churn. Baremetrics puts about 9% of MRR lost to failed payments. The three sources measure different bases, so do not add them together; they agree on direction, which is that this is not a rounding error.

The reason teams get it wrong is timing. At launch there are no failed payments to look at, so the retry schedule stays on whatever the platform ships with and nobody reads it. The first failures arrive at the second and third renewals, a month or two after the launch retrospective has closed. By then the model has been declared a success, and the leak has no owner.

Set these five things explicitly:

1. Retry schedule. How many attempts, and how many days apart. Look at your platform’s default, and compare it with the payment-processor guidance for your gateway. A retry pattern that hammers a declined card on consecutive days can be worse than one that spaces attempts. The right numbers depend on your decline mix, so mark this metric to confirm until you have a month of real declines to sort by reason code.
2. Which declines to retry. A hard decline (card reported lost, account closed) should not be retried; a soft one (insufficient funds, temporary issuer block) should. Sort by the decline code your gateway returns.
3. The card-update message. The first email after a failure should link directly to a page where the subscriber updates payment details, with no login maze. Write it from the customer’s side: what failed, what happens next, one button.
4. The grace state. Decide whether a subscription in retry is “active”, “past due” or paused, and make sure fulfilment does not ship product against an unpaid renewal.
5. The end point. State the moment a subscription is cancelled for non-payment, and send a final message before it happens.

For a deeper treatment of retry design, see dunning management and, if you run on that platform, Recharge dunning. The broader mechanics of avoidable churn are in involuntary churn.

Step 6: Build the exit path: skip, swap, pause, cancel

The customer portal is where the retention rules live. Configure it deliberately rather than accepting the theme’s defaults.

Offer options in order of how much revenue each keeps. A skip keeps the subscription and moves one shipment. A swap (different product or size) keeps it and the revenue. A pause keeps the relationship and the payment method. A cancel ends it. Present them in that order, and make sure the cancel button still works, because hidden cancellation earns chargebacks and complaints, not retention.

Ask for a reason at cancellation, from a short fixed list with a free-text field: too much product, price, quality, moved on, card problem, other. Store it against the subscription record. Without it, every cancellation looks identical and you cannot tell a price objection from a stockpile.

Set the skip limit deliberately. Unlimited skips can hide a subscriber who has effectively left; a cap of your choosing pushes them to pause or cancel. The value depends on your replenishment interval, so derive it from the interval you wrote down before Step 1, not from a round number.

Step 7: Wire the lifecycle messages

Subscription events should feed your email and SMS platform as data, not as one-off campaign sends. At minimum, these need to fire from real subscription state:

• an upcoming-renewal reminder, sent before the charge, with a skip link;
• a payment-failed message, with the card-update link from the retry path;
• a shipment confirmation that names the subscription;
• a cancellation confirmation with a reactivation link;
• a win-back message for cancelled subscribers.

If you use Klaviyo, the Klaviyo flows guide covers the event and flow structure. The point here is the mapping: each subscription event needs to exist in the data layer before a flow can use it. Check that your subscription platform’s integration sends the events you need, and confirm the property names before you build anything on them.

How do you verify the model works before real subscribers arrive?

Verification should cover the second charge, not the first. A launch test that stops at “the order appeared in Shopify” proves only that checkout works.

Run this sequence on a test subscription, on a staging store or with your platform’s test mode:

• Place a subscription order with each plan and confirm the discount, shipping and tax on the order match the settings.
• Force the next charge date forward, or trigger the renewal manually, and confirm the second order is created with the same price and the correct address.
• Simulate a failed payment with a test card that declines, and confirm the retry timing, the card-update email and the grace state all behave as written in Step 5.
• Use the portal as a subscriber: skip a delivery, swap a product, pause, update a card, then cancel with a reason. Confirm each event reaches your email platform.
• Check inventory: put a plan-attached SKU out of stock and see what the renewal does.
• Change a product price and see which price the existing subscription pays.

Record what each test produced. If any answer differs from what the subscriber-facing copy says, the copy or the setting is wrong, and it is cheaper to find out now.

What breaks once the base grows past a few hundred subscribers?

Small subscription bases hide problems that large ones expose.

Price changes. Raising a product price with live subscriptions is a decision, not a setting. Either the subscription is locked to its signup price, or it follows the live price. Whichever your platform does, tell subscribers before the change and give them a skip or pause option first.

Discount stacking. Sale events, site-wide codes and loyalty rewards interact with subscription pricing in ways the settings screen does not show. Re-run the discount cart tests before each promotion.

Retiring a SKU. A discontinued item still has subscriptions attached. Decide the substitute rule before the SKU disappears, and notify affected subscribers before the next charge.

Tax and shipping changes. A shipping-rate change or a new tax obligation applies to future renewals at different prices from the original order. Test a renewal after any rate change.

Support load. Each plan, discount rule and exception becomes a support macro. If agents cannot explain the model in two sentences, the portal copy is too clever.

Platform migration. Moving between subscription apps requires payment-token migration through your gateway and a line-by-line reconciliation of next-charge dates. A migration that resets billing dates produces a wave of surprise charges. For vendor context, see Recharge alternatives and Loop Subscriptions.

When does a shopify subscription model stop being worth it?

A subscription model has running costs that the setup guides leave out.

There is the platform fee, which varies by vendor and usually scales with revenue or orders; check current pricing pages rather than trusting a blog. There is the payment-processing cost of every renewal, including failed attempts. There is the discount, taken from every cycle. There is support and portal maintenance. And there is the cost of stock you must hold or reserve for scheduled shipments.

The model stops paying when the retained-order gain no longer covers the discount plus running cost. You can find that point with your own data: compare the order count and gross margin of subscribers against similar one-off customers over the same window, after allowing for the fact that people who choose to subscribe are already more loyal. That selection effect makes a raw comparison flatter the programme. The honest test is a holdout: offer the subscription to a random share of eligible customers and compare.

A product without a natural cycle also fails this test. If subscribers cancel at the first renewal whatever you change, the product may not suit the model.

Which numbers should you track, and how do you work them out?

Track four, and calculate each from your own data rather than from an industry table.

Subscriber churn by cycle. The share of subscribers who leave at each renewal. Split it into voluntary (a cancellation with a reason) and involuntary (a payment that never recovered). Our subscription churn calculator works through both from your own counts.

Recovery rate on failed payments. The share of failed charges that end in a successful payment. Its value depends on your decline mix, so compute it from a month of data: a figure to confirm.

Skip and pause rate. A rising skip rate ahead of cancellations is an early warning that the frequency is wrong.

Margin per cycle after discount. Recompute after every price or discount change.

For context on how consumable subscriptions behave in aggregate, the DTC consumables churn benchmark is the reference page. Compare your own numbers with it, and treat any gap as a question to investigate rather than a score. The wider conversation about average churn for subscription services covers why single averages mislead.

A subscription programme is a retention problem long before it is a discount problem: the plan structure gets a customer in, and the failed-payment and exit paths decide who is still there in six months. If your base is shrinking at renewals and you cannot say which part is involuntary, that is the work subscription retention covers at Pointerflow.