Subscription e-commerce development

The hard part is the lifecycle, not the checkout

The fit test for a subscription project is not whether customers buy from you repeatedly. It is whether you are agreeing to bill them again on a schedule and to deliver something for each of those periods. That agreement is the thing being built. The checkout that starts it is the smallest part of the work, and treating it as the project is why so many of these builds are finished and then quietly unusable.

A managed recurring agreement differs from repeat purchase, where the customer decides again each time, and from a saved reorder, where they press a button when they run out. It decides once and runs until somebody changes it. So the planning sequence follows the agreement: the offer, the first purchase, each recurring payment, the delivery or access for that period, the failed renewal, the pause, the cancellation and the refund.

Platform choice, catalogue structure and the shared order chain belong to e-commerce website development. This page covers the recurring workflow only. Said plainly at the start: subscription and recurring billing is a custom build scoped to how your business operates, not an off-the-shelf package we resell. If a subscription extension on the platform you already run covers what you need, that is usually the cheaper answer and we will say so.

Write the recurring agreement down before choosing features

Nearly every later argument traces back to a line nobody wrote down. Record eight things: what is subscribed, and whether that is goods, access or both; the price basis; the cadence; when it takes effect; the renewal rule; what the customer may change; what you may change and with how much notice; and how either side ends it. None of it is technical. All of it decides what gets built.

Then separate two dates people assume are one. The billing date is when you take money. The fulfilment or access date is when the customer receives something. They can be deliberately different: bill on the first, dispatch on the tenth, end access at the close of the paid period rather than the moment a card fails. That relationship is an explicit decision, not a consequence of setting up a recurring charge.

Then answer the question that shapes most of your exception handling. What happens to an order that already exists, or a period already paid for, when a future renewal is changed or cancelled? A cancellation on the twenty-eighth of a paid month is not the same event as one on the second. Both answers are defensible. Only one can be the rule your system enforces, and support has to know which.

Deliveries, access, or both

A physical subscription inherits everything a shop has and adds a schedule: what ships each cycle, whether the contents vary, how stock is reserved against a known dispatch run, and what happens when a subscriber's parcel goes missing. An access subscription adds entitlement instead, meaning the permission a paid period grants: what opens, when it closes, and what the customer sees the day after. Combined offers need both, and should not share one state.

Billing, entitlement and fulfilment are three states, not one

The most useful decision on a recurring build is to stop treating paid as a synonym for served. Give the agreement, the payment for a period, the entitlement and the dispatch each their own source of truth, then name who is accountable when they disagree. Sooner or later they will.

Stripe's subscriptions documentation, read on 19 September 2026, illustrates that separation. It states that creating a subscription which requires an immediate payment also creates an Invoice and a PaymentIntent, that the subscription starts incomplete and becomes active once the first invoice is paid, and that an active subscription creates an active entitlement for each feature of the subscribed product. Those are Stripe-specific behaviours on the day we read them, varying by provider, payment method and configuration. The structural point transfers: payment, subscription and access are separate records that can contradict one another.

WooCommerce's order documentation, read the same day, supplies the operational half: orders are usually created at checkout, can be added manually from the admin dashboard, can also be created by external systems through its REST API, and test orders matter for checking new flows and integrations. That is a WooCommerce example, not evidence about any particular build, and the shape still transfers. Every renewal creates an order somebody must be able to find, correct and test.

The table works one fictional example through that sequence, a monthly physical-product subscription. Every role, rule and response is an assumption made for illustration, and the last column lists tests still to run rather than results being claimed.

Failed renewals, and the part that is a commercial decision

A renewal fails quietly. Nobody is on your website, no error page appears, and the first to notice is usually the customer who lost access or never received a delivery. So design the failure path in advance: detect the billing result, apply the agreed retry or grace policy, tell the customer something they can act on, decide what happens to access and to delivery, then reconcile the records.

Stripe documents one version of that machinery: listen for the payment-failure event, monitor for the subscription moving to past due or unpaid, configure smart retries or custom retry rules, and choose in the failed-payment settings what happens after the final retry. It also states that when a subscription is unpaid, payments are no longer attempted and access should be revoked. That is one provider's documented behaviour, dependent on configuration and payment method, not a universal retry policy.

No documentation answers the commercial question underneath. How long do you keep serving somebody whose payment has failed? Serve too long and a dunning problem becomes a debt you will not collect. Cut too fast and you lose a good customer whose bank simply reissued a card. Write the number down, name who may override it, and let whoever answers the message see that state first.

Pause, cancel and proration are four questions, not one

Pausing collection, pausing the service, stopping future renewals and ending a period already paid for are four policies that people collapse into one word. Stripe treats pausing payment collection as its own operation and reserves its paused status for a trial that ended without a payment method, while its cancellation is terminal: the documentation says a customer who wants to resubscribe needs to supply new payment information for a new subscription. Decide your version of each, then decide which of them a customer may do at two in the morning without asking anyone.

Proration is where mid-cycle changes become expensive to explain. Stripe's prorations documentation describes the standard mechanic, a credit for unused time on the old price and a charge for the remaining time on the new one, and notes that negative prorations are not automatically refunded and positive ones are not immediately billed, although both can be done manually. It documents three settings controlling that behaviour and calculates prorations to the second. Your decision is not the setting. It is what the customer is told, because a credit they cannot see looks exactly like a billing mistake.

Some of this is ordinary self-service. Seeing the next renewal date, updating approved details and requesting a pause are account tasks; once identities, roles, documents or approvals are involved you are building accounts and portals. The stored payment method, the order record and the refund route belong with payment and checkout, and whether a gateway supports recurring charges, retries, authentication and refunds the way your plan needs has to be checked against its current documentation.

Turning the workflow into a scope somebody can be held to

Organise the scope around what has to be agreed rather than around features: customer tasks, operational roles, each record and where it lives, the integrations and their permissions, the notifications, any migration of existing subscribers, the normal path, the exception paths, the acceptance evidence for both, and who owns each part after launch. Whether the answer is configuration, one integration or a custom build follows from those constraints rather than being decided first.

• The recurring offer as you would explain it to a customer, including what varies between cycles.
• Who uses it: subscribers, whoever fixes billing, whoever packs the box or grants the access.
• What you run today, and where subscriber, payment and order records live now.
• Your answers on grace periods, pauses, cancellation effective dates and refunds.
• The exceptions you handle by hand today, and who decides them.
• Any constraint that cannot move: a launch date, an existing gateway, an accounting package that has to balance.

The nearest thing in our own work is VITALE, and it is worth being exact about it. VITALE is a concept prototype of a direct-sales back office. It is not client work and it is not a subscription store: nobody buys a plan and receives a box in it. What it demonstrates is recurring machinery, which is the hard half of this page. It runs a deterministic, re-runnable commission cycle producing the same payouts every time, and carries an autoship list with next billing dates against active, paused and dunning states.

Talk to us about a subscription build

Bring the offer, the people who use it, the systems you already run, what has to be delivered or unlocked each period, the exception rules you apply today and any constraint that cannot move. Send that as a scoped enquiry and we will tell you which parts look ready to build, which need a policy decision from you first, and where we would start.