Installing a subscription app on an empty dev store is trivial — click install, drag the widget block onto a product page, done in 10 minutes. Installing one on a live store that's already taking orders is a different exercise. You need to audit what's currently running, decide what changes in the customer-facing storefront, pick which products go subscribable on day one, test the full path end-to-end before flipping the switch, and have a clear rollback plan in case something breaks. This guide walks through every step in the order you should do them, plus the install-day surprises (theme conflicts, gateway incompatibility, currency mismatches, app permission scopes) that catch out merchants who skip the audit.
Pre-install audit: what's already running on your store
Before you install anything, take a snapshot of what currently lives on your store. The single biggest source of install-day breakage is conflict between the new subscription app and an existing app, theme block, or custom code that already touches the product page or checkout. The audit takes 30 minutes and saves hours of debugging.
Walk through three things: the active theme (which version, customized or vanilla, when it was last updated), the apps already installed that touch the product page or cart (upsell apps, reviews apps, bundle apps, cross-sell widgets, sticky add-to-cart), and the payment gateway in use. Your subscription app needs Shopify Payments or another gateway with stored payment method support — most third-party gateways (some PayPal configurations, certain regional processors) don't qualify, and you'll find out the hard way on the first renewal day when the recurring charge can't pull from a vaulted card.
- Current theme name + version (vintage 1.x vs Online Store 2.0 theme app extensions behave differently)
- Active apps that inject blocks into product pages — list every one, note which ones touch price display, add-to-cart, or cart drawer
- Payment gateway: confirm it's Shopify Payments or a gateway that supports vaulted cards for recurring charges
- Existing customer accounts setup (classic vs new customer accounts — the portal embed point depends on this)
- Any custom Liquid code in product.liquid, cart.liquid, or checkout customizations that touch price or quantity
- Current order volume and peak day (so you know when NOT to launch — never on your busiest day)
A third-party payment gateway can happily process the initial subscription checkout. The breakage shows up 30 days later when the renewal tries to charge a card that was never actually vaulted — every renewal silently fails, customers don't get billed, and you don't notice until support tickets start arriving. Verify gateway compatibility before install, not after.
What actually changes in the customer-facing storefront
Customers won't notice an installed subscription app until you add the widget block to a product page — installation itself is invisible. Once you add the widget, four touchpoints change for the customer.
- Product page: the subscribe-and-save widget appears below or next to the buy button, showing cadence options and the discounted recurring price
- Cart: subscription line items show the plan name and next charge date alongside the perDeliveryPrice — the cart total now includes a forward-looking recurring commitment
- Checkout: Shopify's native checkout displays the subscription disclosure (recurring price, frequency, cancellation note) before payment — this is rendered by Shopify itself, not the app, but the wording is driven by what your selling plan defines
- Customer account: subscribers now have a self-service portal to manage their subscriptions (pause, skip, swap, update card, cancel) accessed from their order history or a dedicated portal link
What doesn't change is just as important. Non-subscribable products look identical. One-time buyers see the same flow they always did. The footer, navigation, and brand experience stay untouched. A well-designed subscription install adds an option without removing or changing anything that already worked.
Some merchants get excited and rename their primary buy button to "Subscribe & Save" across the catalog. This usually hurts conversion — most visitors still want a one-time purchase and the relabeling confuses them. Let the subscribe option live alongside the one-time buy button as a clear secondary choice for the first month, then optimize based on data.
Theme app extension vs. legacy script-tag approach
Modern Shopify subscription apps inject their widget via a theme app extension — a Shopify-native mechanism that exposes the widget as a drag-and-drop block in the theme editor. This is the supported, recommended approach and it's what every reputable app uses today. Older apps (and some legacy installs) used script tags — JavaScript injected into every page that finds the product form and grafts the widget on. Script-tag apps still work but are fragile: they break when themes update, they don't compose well with other apps, and Shopify is gradually deprecating script tags entirely.
If you're installing a new subscription app, confirm it uses theme app extensions (also called "app blocks"). The difference at install time: theme-extension apps require you to open the theme editor, navigate to a product page template, and drag the subscription widget block into your chosen location. Script-tag apps appear automatically but you have less control over where, and they often conflict with other apps that also inject script.
One nuance: if you're on a customized vintage 1.x theme, theme app extensions may not work without theme upgrades. Online Store 2.0 themes (the default for any theme purchased or updated in the last few years) handle app blocks natively. If your theme dates from before 2021 and has been heavily customized, talk to your theme developer before installing — you may need to migrate the theme first.
Choosing which products get selling plans on day one
The instinct on install day is to enable subscriptions on every product. Resist it. Stores that launch subscriptions on 100% of their catalog see lower per-product conversion (decision overload), more confused customer support tickets ("why is there a subscribe option on this gift item?"), and higher cancellation rates (customers signing up to products that don't make sense as recurring).
Start with your top 5-10 SKUs that genuinely make sense as recurring purchases — consumables, refills, anything customers already buy multiple times per year. Get the flow working there, watch the data for two weeks, then expand. A clean catalog where 30-40% of products are subscribable typically outperforms a sprawling catalog where 100% are.
- List your products by repurchase frequency from your existing customer data (Shopify analytics → returning customer purchases)
- Pick the top 5-10 SKUs with the highest natural repurchase rate — those are your launch list
- Decide the cadence per product (or product family): weekly, biweekly, monthly, quarterly
- Set the discount (10% off + free shipping is a safe starting point for consumables)
- Attach selling plans to those products only — leave the rest one-time-only for now
- Plan a second-wave expansion at week 4 based on what's converting
Test on a development store before pushing to live
Shopify gives every Partner account free development stores you can install your subscription app on without spending a dollar. Use one. Install the app, build a test product with a selling plan, add the widget, place a test order using Shopify's test gateway (bogus card 1, 2, 3 patterns), trigger a renewal manually if the app supports it, and confirm the second order is created with correct tax, shipping, and fulfillment metadata.
Things to verify on the dev store before touching production: the widget renders correctly on desktop AND mobile (mobile is ~70% of Shopify storefront traffic — widget bugs on mobile kill most subscription conversion), the widget price matches the cart price exactly, the customer portal is accessible from the customer account, dunning emails send (check spam folder), and the order created at renewal has the right tax/shipping calculation.
If your app supports a 1-minute renewal interval for testing, use it. Set up a subscription, wait one minute, watch the renewal fire, confirm the second order appears in the orders admin with everything correct. Three minutes of test work catches the bugs that would otherwise show up in month two on live customers.
- Widget renders cleanly on desktop and mobile (test 5+ products, multiple variants)
- Widget perDeliveryPrice matches cart price matches checkout price
- Subscription line item in cart shows plan name + next charge date clearly
- Checkout disclosure shows recurring price + frequency + cancel mechanism (auto-renewal disclosure law)
- Customer portal is accessible from the customer account / order confirmation email
- Pause, skip, swap, and cancel all work from the portal
- Dunning email actually sends when a renewal fails (test with a card that declines)
- Renewal creates a real Shopify order with correct tax, shipping, line items, and customer notification
Going live: the 30-minute rollout that doesn't crash conversion
When you've audited, dev-store-tested, and picked your launch SKUs, the live rollout is short. Don't do it on your peak traffic day. Pick a low-traffic window (Tuesday morning for most consumer stores, mid-morning local time), have your dev store tab open as a comparison reference, and follow this sequence.
- Install the app on the live store from the Shopify App Store
- Approve scopes (read_customers, write_customers, read_orders, write_orders, read_products, write_products, read_own_subscription_contracts, write_own_subscription_contracts, read_customer_payment_methods at minimum)
- Create selling plan groups for your launch SKUs only — don't bulk-enable
- Open the theme editor, navigate to a product page template, drag the subscription widget block into place (typically below the price, above the buy button)
- Preview the change in the theme editor — verify widget renders, price displays correctly, mobile preview looks right
- Click "Save" in the theme editor (this is when it goes live for customers)
- Place a real test order on the live store using a real card for one of the subscribed products — verify the full path works end-to-end (you can refund/cancel afterward)
- Monitor your analytics dashboard for the first hour for any error spike, support ticket spike, or conversion-rate drop on the products you enabled
Dev stores can hide configuration issues that only appear on live. Place one real order through the full customer-facing flow on launch day — your money, your real card. If anything looks wrong, you'll see it before the first paying customer does.
Day-1 monitoring: what to watch in the first 48 hours
Most install-day bugs surface within the first 24-48 hours, often through three signals: a conversion-rate dip on the products you enabled, a spike in support tickets, or an error log in your app's admin showing rejected billing attempts. Watch all three actively for the first two days.
Conversion-rate monitoring matters most. If your subscribable products had a 3% conversion rate before install and dropped to 1.5% after, something about the widget is friction (price mismatch, slow load, mobile layout). The fix is usually obvious — open one of those product pages on mobile, watch what happens, compare to the dev-store version. Most issues are layout-related and resolve with a theme-editor tweak.
- Conversion rate on subscribable products (before vs after install, hour-by-hour for the first day)
- Number of subscription contracts created (you should see at least 1 in the first 24 hours if you have meaningful traffic)
- Support tickets mentioning the widget, the subscription option, or the cart — even one ticket usually means 10 silent confused customers
- Failed billing attempts in your subscription app's admin dashboard — should be zero on day 1 since no renewals have fired yet
- Page load speed on product pages (widgets that add 500ms+ kill mobile conversion)
- Mobile-specific conversion (often diverges from desktop dramatically when widgets have layout bugs)
Rolling back safely if something breaks
If something goes wrong on install day — widget breaks the page layout, cart shows wrong price, customers report errors — you need a rollback that takes minutes, not hours. The trick is to roll back the customer-facing change without uninstalling the app (which would lose any contracts that did get created).
- Open the theme editor, navigate to the product page template
- Remove the subscription widget block (or set it to hidden)
- Save — the widget disappears for customers; product page is back to one-time-only
- Active subscription contracts already created continue to work — they're not affected by the widget being hidden
- Debug what went wrong in the dev store, fix it, re-add the widget when ready
If the issue is more severe (the app itself is misbehaving, taking unauthorized actions, charging customers unexpectedly), the nuclear option is uninstalling. Uninstalling does not delete subscription contracts on Shopify's side — they remain in your store but won't have a UI to manage them until you install a replacement app. Most reputable subscription apps offer migration-from-uninstalled-state because this scenario does happen. Don't uninstall if you can avoid it; a hidden widget is a far less destructive rollback.
Deleting a selling plan group while contracts exist on it orphans those contracts. They'll fail their next renewal because there's no plan to bill against. Hide the widget, keep the plans intact, fix forward.
Removing or switching apps later: data ownership and contract migration
You're picking an app to install today, but pick with the future in mind: what happens when you want to switch? Because subscriptions live on Shopify's native Subscription Contract API, the contracts themselves are Shopify-owned data — they don't disappear if you uninstall the app. The customer payment methods are also Shopify-vaulted, not app-vaulted, so they transfer too. This is one of the under-appreciated benefits of using a modern, native-Shopify subscription app.
What does sit with the app: the customer portal UI, the dunning email cadence and templates, the analytics dashboards, the selling plan configuration UI, and the cron infrastructure that triggers renewals. When you switch apps, you re-create selling plans in the new app, point them at the same products, and the new app picks up renewal management for your existing contracts. Reputable apps offer a free migration where they handle the contract-mapping for you — see our subscription migration guide for the step-by-step.
Apps that use a parallel billing system (charging customers outside of Shopify's contract API) lock you in much more aggressively — switching means contracts have to be recreated from scratch and customers re-enter their payment details, which is the fastest way to lose 30-50% of your subscriber base. Verify before install: "do you use Shopify's native Subscription Contract API end-to-end, or do you run your own billing in parallel?" The answer should be the first one.
Common install-day surprises and how to dodge them
Even with a clean audit and a dev-store test, install day still surfaces predictable surprises. Here are the recurring ones — knowing they exist usually means you'll catch them in your audit instead of in production.
- Theme conflicts: another app already injects a block exactly where you want the subscription widget. Resolve by reordering blocks in the theme editor or moving one of the conflicting blocks to a different section.
- Gateway incompatibility: your payment gateway technically processes the first order but doesn't actually vault the card for renewals. The first renewal fails silently 30 days later. Verify gateway compatibility (Shopify Payments is the safest bet) before install.
- Currency setup: stores using Shopify Markets need to confirm subscription pricing works in all enabled currencies. Selling plans price in the shop's default currency; Markets handles conversion at checkout. Test a non-default-currency subscription end-to-end if you sell internationally.
- App permission scopes: some merchants are surprised by the breadth of scopes a subscription app requests (write_customers, write_orders, write_products, read_customer_payment_methods). Each scope is needed for legitimate functionality — read the app's scope justification before approving, but the list shouldn't surprise you.
- Order tagging conflicts: subscription apps tag orders with "subscription" or similar labels. If your fulfillment software or 3PL filters orders by tag, make sure subscription orders still route through your normal pipeline.
- Customer account integration: classic vs new Shopify customer accounts have different portal embed points. If you've recently migrated to new customer accounts, verify the subscription app's portal appears in the right place.
- Tax configuration on subscription orders: Shopify Tax handles subscription renewals identically to one-time orders, but if you've manually configured tax rates per product, make sure the same rates apply to the subscription versions. Test one tax-calculated renewal end-to-end.
Have a checklist, follow it in order, monitor for an hour after, and don't do it on a Friday afternoon when your support team is signing off. Install on a Tuesday morning and you'll have your full team available if something goes sideways.
Install-day FAQ
Will installing affect my existing customers?
No. Installing a subscription app doesn't change anything for existing customers or existing orders. The app only becomes visible to customers when you actively add the subscription widget block to a product page and create selling plans. Until then, your storefront looks and behaves exactly as before.
Do I need to pause my store during install?
No. The install itself is invisible to customers — it happens entirely in the Shopify admin. Even adding the widget block to a product page is non-disruptive: customers who land on the product mid-edit see the previous version until you save the theme change. There's no maintenance window required.
What happens to existing one-time purchases?
Nothing. Existing one-time orders, customer accounts, payment records, and fulfillment workflows stay exactly as they were. The subscription app only affects products you explicitly attach selling plans to, and only in the new subscription line items it creates — not in existing order history.
Can I uninstall without losing subscription data?
Subscription contracts and customer payment methods are stored on Shopify's side via the native Subscription Contract API — they survive app uninstalls. What's tied to the app is the customer portal UI, the dunning email cadence, the renewal cron infrastructure, and the analytics dashboard. If you uninstall, contracts remain in Shopify but renewals stop firing until a replacement app is installed and configured to manage them.
How long does the install actually take?
Technical install: 5-10 minutes (install app, approve scopes, configure first selling plan, drop the widget on a product page). Audit and dev-store testing beforehand: 1-2 hours. Total realistic install-day timeline including monitoring: half a working day for a careful rollout.
Will the widget slow down my product page?
Modern theme-app-extension widgets are lazy-loaded and typically add 50-150ms to page load. Older script-tag widgets can add 500ms or more, which hurts mobile conversion. If you're picking an app, choose one that uses theme app extensions for performance. Measure before/after with Lighthouse on a few product pages to confirm.
Does installing a subscription app affect my Shopify Plus or Advanced plan billing?
No. Subscription apps are billed independently of your Shopify subscription. Some apps take a percentage of subscription revenue (Recharge, Loop, Skio); some are flat-fee (SimpleSubscription). Neither model changes what you pay Shopify directly for your store.
Can I install on a development store first to learn the app?
Yes — and you should. Shopify Partner accounts include free development stores you can install any app on, with no monthly fee and no real charges. Build a test selling plan, place a test order, trigger a renewal, see the whole flow before you touch your live store. Most subscription apps offer this as part of their onboarding documentation.
Do customers need to create an account to subscribe?
Yes. Subscription contracts are tied to customer accounts because the renewal needs a vaulted payment method and an address. Shopify creates the customer account automatically at first checkout, the same way it does for any logged-in checkout. From the customer's perspective they're just placing an order; the account exists silently after.
What if my theme doesn't support theme app extensions?
Vintage 1.x themes that have been heavily customized may not support theme app extensions. You have two options: upgrade to an Online Store 2.0 theme (rebuild your customizations in the new model — a real project), or use a subscription app that still offers a script-tag fallback (rarer now; quality varies). Long-term, upgrading the theme is the better answer because Shopify is investing in app blocks, not script tags.
Should I install before or after a sale event?
After. Never install a new app in the lead-up to or during a major sale event. The risk-reward is wrong: any install-day issue costs you peak-day conversion, and you don't have the bandwidth to debug while support volume is high. Install during a low-traffic period, run for 2-3 weeks to stabilize, then enter your next sale event with a known-good setup.
What scopes does a subscription app need and why?
Typical scopes: read/write customers (to manage subscriber data), read/write orders (to create renewal orders), read/write products (to attach selling plans), read_own_subscription_contracts + write_own_subscription_contracts (the core subscription API), read_customer_payment_methods (to bill renewals), read/write purchase_options (to manage selling plan groups), read/write themes (to install the widget block), and write_discounts (for any subscription-specific discount logic). Each scope corresponds to a documented feature; an app that asks for more than these without justification is worth questioning.