Shopify subscription development: the technical side

Shopify's subscription machinery is native but not turnkey. The platform provides the primitives; an app assembles them into something a merchant can use. Understanding the primitives is what tells you whether an app will do, or whether you're building.

The merchant-facing version of this is in building a subscription store.

The three objects

Selling plans. A description of a recurring purchase — frequency, discount, billing and delivery policy. Selling plans are grouped, and groups are attached to products or variants. One product can offer several: monthly, quarterly, and a one-off purchase.

Subscription contracts. Created when a customer subscribes. Holds the schedule, the payment method, the line items and the delivery details. This is the durable record.

Billing attempts. On schedule, a billing attempt is made against the contract. Success creates an order, which then behaves like any other Shopify order for fulfilment and reporting.

That last point matters: subscription orders are ordinary orders downstream, so your fulfilment and accounting integrations don't need to know they came from a contract.

What creating a subscription requires

An app with the right scopes, a payment method vaulted for future use, and a contract created against it. The vaulting is the part you can't do casually — storing a payment method for later charging has its own requirements, and it's one reason building subscriptions from scratch is a bigger job than it looks.

This is why almost everyone uses an app for the core and builds around it.

Where apps stop and building starts

Apps handle: selling plan management, the checkout flow, contract creation, scheduled billing, dunning, and a customer portal. That's a lot of unglamorous work.

You end up building when:

• Contents change per cycle. A box whose products differ each month isn't a fixed contract; something has to update the lines on a schedule.
• Pricing depends on customer-specific rules. Trade rates, volume tiers, contract pricing — usually Functions reading a metafield that an integration wrote, since a Function can't call your systems.
• Subscription data must reach an ERP or fulfilment system with your own logic — predicting next month's demand, generating pick lists in advance.
• The customer portal needs behaviour the app's version won't do.
• You need a bespoke sign-up flow — a quiz, a configurator, a bundle builder — that creates the contract.

The billing edge cases

This is the actual project, and it's a conversation with the business rather than a technical task. Each needs a decision:

• Failed payment: how many retries, over how long, what does the customer see? Dunning is the largest single lever on involuntary churn.
• Expired card: prompt before expiry, not after failure.
• Skip a cycle: customers who can skip stay subscribed.
• Pause and resume.
• Out of stock at billing time: substitute, skip or delay — pick one and be consistent.
• Plan change mid-cycle: proration rule.
• Refund one cycle without cancelling the contract.
• Address or payment method change mid-contract.

Stores that skip this list discover each item individually, in production.

Webhooks to handle

Subscriptions generate their own events, and an integration needs to react to them: contract created, contract updated, billing attempt success, billing attempt failure. Plus the ordinary order webhooks for the resulting orders.

The usual rules apply — verify the HMAC, respond fast, process asynchronously, and be idempotent, because delivery is at least once. Webhooks and error handling.

Customer self-service is churn control

Every action a customer can't perform themselves becomes an email, and a proportion of those become cancellations because emailing is more effort than clicking cancel.

Minimum: skip, reschedule, change quantity or products, update payment method and address, pause, cancel. In a headless build that portal is built on the Customer Account API, which exposes subscription contracts for the authenticated customer.

What to check before committing

1. Does an app already do 90% of it? Usually yes — buy before build.
2. Can the app's API be extended for the missing 10%, or does it have to be replaced?
3. What does the app do on failed payments, and can you change it?
4. Does subscription data reach your fulfilment system in a usable form?
5. Have you written down a decision for every edge case above?

Question five is the one that determines whether the project takes six weeks or six months.

The subscription itself is a fortnight. The billing edge cases are the project, and they're decided in a meeting rather than an editor.