Can we just use a WordPress membership plugin instead of a custom build?

Often, yes. MemberPress, Paid Memberships Pro, or WooCommerce Subscriptions cover courses, newsletters, and simple tiered access well, and the fastest path is usually to configure one of them properly. We recommend a plugin when your rules fit its model, and a custom application when you need unusual entitlements, an external client portal, or integrations the plugin does not support.

How do you stop someone from sharing a login and reading paid content?

We cannot stop it completely, because a shared password behaves like a valid password. We can limit the damage with a device or session cap, concurrent-stream limits on video, short-lived signed URLs for files, and logging that shows one account reading the whole library from six countries in an hour. Practical limits work better than pretending the problem is solvable.

What happens to a member's access when their card is declined?

The payment provider retries the charge and notifies your system. We put the member into a grace period rather than locking them out on the first failure, send two or three emails with an update-payment link, and only suspend access after the retries finish. The account and its history stay intact, so restoring access is one click.

Can members export or delete their own data?

Yes. We build a self-service account screen where a member can download their profile, invoices, and activity as CSV or JSON, cancel a subscription without emailing you, and request account deletion. Deletion runs through a defined retention rule, because invoices and payment records usually have to be kept for accounting.

Who owns the member database and the payment account?

You do. The database, the Stripe or PayPal merchant account, and the hosting sit under your ownership, and the data processing agreements are signed between you and each provider. We hand over documentation, including how entitlements are stored and checked, so another team can take the system over without reverse-engineering it.

Membership & Gated Content System

Membership builds on WordPress, Next.js, and custom backends: registration, plans, trials, failed-payment recovery, and server-side access checks.

See our work:

Housekeeper World→POLLCART→SmartAIChats→

A registration form takes an afternoon. The system behind it takes longer. Once your site has members, you are storing personal data, collecting recurring payments, and deciding access on every request for a protected page. Those three jobs fail in different ways, and usually without anyone noticing until a paying member cannot get in.

We build these systems on WordPress, on Next.js, and as custom applications that sit beside an existing site.

What a membership system contains

A members area is a small application attached to your website, and its parts depend on each other in this order.

Identity: registration, login, password reset, and enough verification to know who is on the other end.
Access: the plans you sell, what each plan covers, and the single place where that decision gets made.
Billing: subscriptions, trials, invoices, retries, and cancellation.
Data: member records, activity history, and the personal information you now control.
Operations: admin screens your team uses to answer why one member sees the course but not the downloads.

Who this is for

Course and training companies selling modules, cohorts, or an annual library
Professional bodies with member directories, resources, and renewals
Publishers putting some articles behind a subscription
Service firms giving clients a portal for documents and project status
Software products that need a free trial, a paid plan, and a way to move between them

A single page behind one shared password does not need any of this. A membership plugin handles most course sites, and we will say so when that is the cheaper answer. Custom work is justified when entitlements are unusual or the portal has to talk to a CRM.

What we deliver

Authentication choices

Email and password remains the default, with magic links for people who never remember passwords. Social sign-in through Google and Apple moves part of the verification burden to a provider that already knows the person. SMS codes suit phone-first audiences, at a per-message cost that grows with volume. Company portals usually need SSO through SAML or OIDC, so staff sign in with their Google Workspace or Microsoft Entra account and lose access the day they leave.

Sessions, passwords, and account recovery

Passwords are stored as a slow one-way hash with bcrypt or Argon2, never encrypted reversibly. Sessions live in httpOnly, Secure, SameSite cookies rather than localStorage, so page scripts cannot read the token. On login we rotate the session identifier, and a sign out everywhere option invalidates server-side session records instead of waiting for a cookie to expire.

Reset links are single use and time limited. Failed logins are rate limited per account and per address, which slows credential stuffing without locking out someone who mistyped twice. Multi-factor authentication is mandatory for admin accounts.

Plans, entitlements, and where the check happens

The interface can hide a link or grey out a button. Anyone can undo that in a browser. The rule that matters is that every request for protected content is authorised on the server before the content exists in the response.

Server-rendered pages read the entitlement record before rendering, API routes re-check it before returning data, and files are delivered through short-lived signed URLs rather than a public folder path. A file with a permanent public URL is public, whatever the page around it looks like. Someone holding that URL, or a script replaying the request your page makes, gets the same result as a paying member if the check only happened in the browser.

Roles, plans, and permissions live in the database and are checked in one shared function that every protected route calls. Caching is keyed to entitlement state, so a member never receives a page cached for someone else. An upgrade, a downgrade, or a pause updates the entitlement record, and the next request reflects it without a deploy.

When a payment fails

Card expiries and bank declines are routine, and the system should treat them as routine. The provider sends a webhook, we move the subscription into a grace period, and the member keeps access while retries run. Two or three emails link to a page where the card can be replaced in one form.

If retries finish without success, access is suspended rather than deleted. The account and its history stay in place, so restoring service is a click once the card is fixed. We log every state transition with a timestamp and the provider event behind it, and a reconciliation job compares your records against the provider's.

Cancellation, refunds, and data export

Members cancel in their own account area, without support email. Standard practice is access until the end of the paid period and no further charge, though the terms we implement are yours and go into the checkout copy. Refunds are handled through the provider's dashboard with the reason recorded.

Members download what they own: profile details, invoices, and activity history as CSV or JSON. Account deletion follows a defined retention rule, because invoices and payment records usually have a statutory retention period while profile and activity data do not. We tell you which fields fall into each group before launch.

Privacy obligations for stored personal data

Holding member accounts makes you a data controller, and most of our clients fall under GDPR or UK GDPR. We limit collection to what the product needs, document each field and its purpose, set retention periods, and keep marketing consent separate from the account choice. Access and deletion requests get a working path in the product, since the legal deadline is a month and support tickets are a poor substitute.

Card numbers never reach your server. Stripe, PayPal, and Revolut collect them through hosted fields or a redirect, which keeps card data inside their PCI scope. Email, hosting, and analytics vendors each need a data processing agreement. Where records must stay inside the EU or the UK, we choose hosting regions and providers accordingly.

How the engagement runs

We start with a week of mapping: what you sell, who buys it, what each plan covers, and where the money lands. That conversation usually changes the plan list before any code exists.

Then authentication and roles, typically one to two weeks, followed by billing and entitlements over two to three weeks. The final phase covers dunning, cancellation, export, admin reporting, and a security pass on session handling and file delivery.

What it costs

Membership work is quoted at our flat rate of $39 per hour as the starting point, or as a fixed scope once the mapping is done. The billing and entitlement phase is the largest part, and it grows with the number of plans and the number of third-party systems that need member truth. Teams that need sustained delivery use the monthly capacity plans from $2,699. The pricing page sets out both models and the published budget bands for typical orders.

Proof

SmartAIChats is a conversational SaaS platform we designed and built, with business accounts, plan-based usage, and an AI layer behind an application interface. It shows we run accounts and paid tiers as part of a commercial product.

Housekeeper World is a service-booking platform with customer accounts, package selection, and a handoff into the client's operational workflow. It is the same problem in another shape: customer identity, an entitlement to a service, and records that staff depend on.

Pollcart is a Shopify social commerce app used by shoppers and installed by merchants. It proves we work inside a platform where someone else owns authentication and permissions.

Related services

Web development for the front-end and back-end work a member area sits inside
WordPress development when the site runs on WordPress and the membership logic should live there
Payment gateway integration for subscriptions, webhooks, and provider reconciliation
Custom web application development when entitlements or portals exceed what a plugin models
Mobile app privacy compliance if the same member account also exists in an iOS or Android app

Next step

Send us the plan list, roughly how many members you expect, and the payment provider you already use. We will say whether a plugin covers it or whether it needs custom work.

Contact us to talk it through, or put your requirements into the Vasilkoff.info estimator for an early scope and cost range.