Shopify Subscriptions: payments, billing and native app limits

Postazione e-commerce con prodotti e un ciclo di consegna ricorrente visualizzato su tablet, simbolo degli abbonamenti Shopify

Shopify Subscriptions is Shopify’s free first-party app for selling products with recurring charges without immediately relying on an external solution. For a straightforward subscription model, it can be enough: you create one or more plans, set frequency and discounts, manage contracts, and let customers handle an important part of the subscription from their account. The key is to check the limits before building your commercial process around the app.

The choice between native functionality and a dedicated app should not be based on feature counts. Start from the model you actually need to run: payment method, product, frequency, contract changes, error handling, and how much control customers should have.

What Shopify Subscriptions does

Shopify Subscriptions adds subscriptions as a purchase option. You can create plans with different frequencies, apply discounts, and associate plans with products. Shopify handles checkout, creates the subscription contract after purchase, and securely stores the payment details needed for future charges.

On the merchant side, you can change products, quantities, and delivery frequency on a contract, skip an upcoming order, and pause, resume, or cancel the subscription. The main information remains available in the Shopify admin and customer profiles.

This makes the app especially suitable when the model is simple: the same product or a limited range, defined schedules, and relatively few operational exceptions.

Customers can manage a lot without contacting you

With customer accounts enabled, subscribers can access their account and manage several actions themselves. Shopify documents the ability to update the payment method and shipping address, skip an order, pause or resume the subscription, and cancel it.

Shopify Subscriptions also sends an automatic reminder three days before each recurring order is charged. Customers therefore have time to act before renewal, for example by skipping the order or updating payment details.

For a small or medium-sized store, this self-service can reduce manual support work. It still needs to be tested on the store’s real flow: customer account, email, management page, checkout, and what happens after a change.

Payments are the first thing to verify

Subscriptions require a gateway and payment method that support recurring charges. Shopify maintains a list of supported gateways and notes that availability depends on the country and provider. Local, manual, or non-card payment methods may not be available for subscriptions.

Check this before designing the offer. If your audience mainly uses a payment method that cannot be charged again, a better-looking widget on the product page will not solve the underlying problem.

If you are reviewing the full payment stack, I cover it separately in the guide to Shopify payment methods in Italy.

How failed payments and stock problems are handled

In Shopify Subscriptions settings, you can configure billing retries for failed payments or insufficient inventory. You can choose how many attempts to make, how many days to wait between attempts, and what should happen when all retries are exhausted.

Shopify documents skip, pause, or cancellation as possible outcomes, with a customer notification. This is a decision to make before launch: a failed payment and a temporarily out-of-stock product are not necessarily the same problem and do not have to lead to the same outcome.

Limits to know before choosing the native app

Shopify Subscriptions does not cover every recurring-commerce model. Shopify documents several explicit limits:

subscriptions cannot be used with draft orders;
bundles are not compatible with Shopify Subscriptions;
the Order Edits API does not support subscriptions;
products sold only by subscription, with no one-time purchase option, can be sold only through the Online Store sales channel;
a supported payment gateway is required.

These constraints matter more than the app’s price. If your model depends on dynamic bundles, complex order changes, or commercial flows outside the standard path, forcing everything into the native solution can create more work than it removes.

Online Store 2.0 and the subscription widget

After creating plans, the app can display a subscription widget on the product page. On an Online Store 2.0 theme or a theme compatible with theme blocks, configuration happens in the theme editor and should be checked on the actual theme in use.

I would not stop at confirming that the widget appears. I would check the hierarchy between one-time purchase and subscription, readability of frequency and discount, variant selection, cart, checkout, and mobile behavior. A recurring purchase option should be understandable before the customer reaches payment.

When the native app is enough

I would use it as the first option when the business model stays within its boundaries: straightforward recurring plans, compatible products, a supported gateway, standard self-service management, and no strong need for bundles or custom contract logic.

In that scenario, the advantage is practical: a free first-party solution integrated with Shopify admin and checkout can avoid adding complexity without a clear reason.

When I would consider a specialist app or custom development

A dedicated solution makes sense when the problem is no longer simply “renew this product every X weeks.” Examples include advanced bundles, specific retention logic, complex migrations, external integrations, highly customized customer experiences, or rules beyond what the native app exposes.

This does not mean a third-party app is automatically better. Its cost should be compared with the operational cost of handling exceptions. The same logic applies across the Shopify stack: in my guide to Shopify app costs, performance, and replacement, I explain why app count alone is not a useful metric.

Minimum checklist before launch

Before enabling a subscription offer, I would test the entire flow, not only plan creation:

one-time purchase and subscription selection on the product page;
frequency, discount, and terms visible before payment;
the actual gateway and payment method are supported;
reminder emails and access to the customer account;
skip, pause, resume, and cancellation;
payment method and shipping address updates;
behavior after a failed payment or insufficient stock;
a cancellation policy configured for the store.

For the last point, Shopify creates a dedicated purchase-options policy and links it from checkout. The wording needs to be configured for the store and, whenever legal or regulatory interpretation is involved, checked in the relevant context: the app does not replace that review.

The decision rule I would use

If Shopify Subscriptions covers the model without workarounds, I would start with the native solution. If making it work requires bypassing limits around bundles, payments, order changes, or contract logic, I would move to a better-suited architecture before accumulating exceptions.

Native-first means using the native tool when it solves the problem well. It does not mean forcing every business model into the limits of that tool.