Selling by Subscription: What the Site Must Handle After the First Payment

Selling a subscription is easy the first time: there's a payment, just like any order. The difference starts the following month, when the payment repeats on its own — and especially when it doesn't. A recurring sales system is judged by how it handles the cases that go wrong, not by how it collects the first charge.

Before looking at tools, it's worth putting three things in writing: what renews, what the customer can change on their own, and what happens when they stop paying. Every answer left vague here later becomes a case to handle by hand, one customer at a time.

What you're actually selling

• The frequency: monthly, yearly, or other, and whether renewal falls on the same calendar date for everyone or on the anniversary of activation.
• The content: what's included in the subscription fee and what's paid separately. This is where nearly all disputes originate.
• The changes allowed during the period: quantity, number of users, locations served, added options.
• Pauses: whether one is allowed, for how long, and what effect it has on the renewal date.

These look like commercial questions, and they are. But each one becomes a rule someone will have to write into the system, and undeclared rules become exceptions handled from memory.

The life cycle, status by status

A subscription isn't simply on or off: it passes through intermediate statuses, and that's where the problems come from. The scheme below is illustrative and needs to be adapted to your offer.

The column that gets forgotten is the third one. A customer who doesn't understand why the service stopped calls in, and every call like this is a flaw in the system, not a support activity.

When the payment doesn't go through

This is the most frequent case, and almost never due to bad faith: expired cards, spending limits, account changes. You need a rule written in advance and the same for everyone, because handling it case by case becomes unmanageable.

1. How many attempts are made and how far apart they are.
2. What is communicated to the customer, how far in advance, and on which channel.
3. After how long access is suspended.
4. What stays accessible during suspension.
5. Who checks the list of suspended accounts, and how often.

The delicate point is the fourth one. If suspension also closes off the way to pay, a customer who wanted to stay can't: it's always worth leaving their data visible and the payment page reachable.

The status must actually control something

A subscription isn't much use if its status is just a label in a panel. It needs to determine access: who gets in, what they see, what they can do. If the service sold is off-screen — a periodic delivery, maintenance, on-site coverage — the status needs to drive the work list of whoever carries it out, otherwise you keep serving people who aren't paying and forget the ones who just renewed.

Plan changes, pauses, and cancellation

• Upgrading to a higher plan: from when it takes effect and how the already-paid portion of the period is handled.
• Downgrading to a lower plan: immediately or at renewal, and what happens if the customer exceeds the new plan's limits.
• Pause: whether it's allowed, for how long, and whether it shifts the renewal date.
• Cancellation: by when it can be requested, until when the service stays active, what happens to the data.

Each of these cases has a commercial answer and a technical one, and they need to match. If whoever sells says “cancel whenever you want” and the system requires advance notice, the contradiction always surfaces, and always with the most upset customer.

Support: the questions that will come in

It's worth preparing for the five questions that always come in and deciding who answers them and with which tool: where's my invoice, why was I charged this amount, how do I change my payment method, how do I cancel, can I get a refund. If each one requires opening a technical panel, support will become the bottleneck as subscribers grow.

The simplest way to lower the volume is to show the customer, in their profile, what they need without having to ask: next renewal date, amount, payment method in use, document history.

What this guide doesn't cover

This guide covers how the system works. Contractual terms — minimum duration, automatic renewal, notice period, withdrawal, data handling at closure — need to be defined and validated separately, with whoever has the expertise: the system carries them out, it doesn't set them. Handling paid, failed, and refunded orders, and the messages to send after an order, have their own guides.