Websites
Subscription website: how paid access works
What a website subscription actually consists of: access levels, the free trial, recurring payments and what happens to content when payment lapses.
A subscription is often ordered as "hide some pages from people who haven't paid". In practice that's the smallest part of the task. Paid access isn't a lock on a door but a combination of access rights, recurring charges and rules for when content opens and closes. Below is what that combination consists of and where it usually breaks.
Why a password on a page isn't a subscription
The most common first version: one shared password for the private section, handed out after payment. It works exactly until the first subscriber forwards the password to friends. It can only be revoked by changing it for everyone at once, and every such change means emailing a new password to the whole base.
The second problem is that payment and access aren't linked. With a shared password, the system doesn't know who exactly is viewing the material right now, until what date they've paid, or what to do when a payment fails. All these decisions have to be made by hand, and the manual workload grows with the number of subscribers.
A subscription begins where each user has their own account, and the account has a state: active, in trial, overdue, cancelled. Everything else is built on top of that state.
Access levels: what to put behind what
Before writing code, it helps to list everything on the site and mark next to each item who can see it. Usually you get three or four groups:
- Open to everyone. The storefront, the description, some materials in full. This is what search engines index and what a person uses to decide whether to pay.
- Open to registered users. Comments, saved items, viewing history. Registration is free and serves as a step towards paying.
- Open to subscribers. The core value of the product.
- Open on the higher plan. If there's more than one plan — consultations, exports, access to private breakdowns.
The mistake here is always the same: too much is locked. If the open part doesn't show what the money is for, there's nothing to pay for. A sensible approach is to leave enough open for a person to be convinced of the quality, and lock what's valuable with regular use: the archive, tools, updates.
What happens when someone tries to open locked content is a separate decision. Showing an empty page with an error is the worst option. Better to show the title, the first part of the material and a clear explanation of which plan unlocks it.
The free trial and the first payment
A free trial solves one problem: it removes the need to take your word for it. But it has a cost — some people come purely for free access and leave on the day it ends.
The main forks you'll have to choose deliberately:
- Whether to ask for a card upfront. With a card, trial-to-paid conversion is higher but there are fewer trial sign-ups. Without one, the reverse. It's a choice between the volume of the top of the funnel and its density; there's no universally right answer.
- Limit by time or by volume. "A week of access" and "three free materials" produce different behaviour: the first creates urgency, the second lets people try it at their own pace.
- What to do about repeat trials. If a trial isn't tied to the person at least by email and card, some users will create new accounts endlessly.
Before the trial ends, the person must be warned — by email and in the interface. A charge without warning almost always comes back as a chargeback and a complaint, and a disputed payment costs more than a lost subscription.
Recurring payments: charges, failures, cancellation
A recurring charge is a separate mechanism on the payment provider's side. The site doesn't store the card: it receives a token from the provider and asks it to charge an amount on schedule. Several practical things follow from this.
A charge can fail. Insufficient funds, an expired card, the bank declined the transaction. This is a normal part of operations, not an emergency. You need a retry scenario: several attempts at intervals, emails to the user in between, and a clear state of "payment failed, access remains until such-and-such date". Cutting access the second a bank declines a single transaction is a way to lose paying customers for nothing.
Cancellation must be available in the account. A two-click cancel button, with no emails to support and no need to explain why. Hidden cancellation doesn't retain subscribers — it converts them into chargebacks and negative reviews, and in some jurisdictions it directly violates the rules for online subscriptions.
Cancellation and expiry are different events. A person cancelled — so there'll be no next charge, but access stays until the end of the paid period. Cut it off immediately and you've taken away what they paid for.
A subscription isn't a one-off sale stretched over time. It's a decision to renew that the user makes again every month.
Plan separately for changing plans mid-period, pausing a subscription and refunds. Even if you decide "no pauses", that decision should be made in advance and reflected in the interface, not invented in a conversation with the first person who asks.
What to do with content after a subscription ends
This is the question most often forgotten. The subscription has ended — what happens to what the person has already done on the site?
Possible options, from least to most strict:
- Everything is kept but becomes unavailable until renewal. Personal data, notes and progress don't go anywhere.
- Personal data stays accessible; only the content is locked. The person can export their own data but can't read anything new.
- Everything is deleted after a retention period. Rarely applicable, and requires an explicit warning in advance.
A sensible default is the second: the user isn't punished for stopping payment and can come back without starting from scratch. Revoking materials downloaded during the subscription is pointless — it's almost always technically impossible, and attempts at such control damage attitudes to the product more than the losses themselves.
If material is partially open to search engines, make sure the locked part isn't served in the page's source code. The classic mistake is hiding paid text with styles: it stays in the markup and is available to anyone who opens the source. Locked content must not leave the server for someone who hasn't paid.
Practical pre-launch checklist
Before opening subscription access, check that every point has a ready answer in the system, not in the owner's head:
- There's a "section — who can see it" table, and the open part is enough to understand the value.
- It's decided whether a card is needed for the trial and how repeat trials are limited.
- There's a warning email before the first charge.
- The failed-charge scenario is described: how many retries, at what interval, when access is closed.
- Cancellation is available from the account and doesn't cut the paid period short.
- It's defined what happens to the user's data and materials after the subscription ends.
- Locked content isn't served in the page markup to non-paying users.
- The admin panel shows each subscriber's state and payment history.
If everything checks out on these points, what remains is technical work. We go through these scenarios at the design stage — more about our approach to paid-access websites on the subscription websites page, and you can discuss your specific task via the form.