Plans and pricing
Plans with intervals, trials, setup fees, add ons, seat counts and grandfathered pricing preserved when public prices change.
Solution
Membership and Recurring Billing Systems
Plans, entitlements, renewals, dunning and cancellation handled by a state machine driven from processor events, so access always matches what has been paid.
Overview
What the system does
Recurring revenue looks simple and is not. A member upgrades mid cycle, a card fails on renewal, a plan changes price, someone cancels and rejoins, a payment succeeds after a retry. Each of those is a state transition and each one has to leave access correct.
The failure mode is a system where entitlement is a boolean somebody updates. It drifts, and the result is either unpaid access or a paying member locked out.
We derive entitlement from verified billing events and explicit access rules. Scheduled reconciliation detects missing or delayed events before temporary inconsistencies become persistent access problems.
Who needs this
Member services and software businesses connecting recurring payments with access to a product or service.
What we build
Billing and entitlement are related but separate states. Define grace rules, effective cancellation dates, upgrades and failed renewals. Reconciliation is necessary because webhook delivery and provider state can temporarily disagree.
Modules
Core modules
Subscription state machine
Trialing, active, past due, paused, cancelled and expired, with defined transitions and the event that causes each one.
Entitlement resolution
Features and limits derived from the current subscription state at request time, so nothing has to be synchronised by hand.
Proration and plan changes
Upgrades, downgrades and interval switches with proration handled by the processor and reflected immediately in access.
Dunning
Retry schedule on failed payment, notification sequence, grace period and the exact point access is suspended, all configurable.
Cancellation and retention
Cancel at period end or immediately, pause, reactivation, and a record of the reason given.
Member area
Self serve plan changes, payment method update, invoice history and receipts.
Revenue reporting
Active members by plan, churn, expansion, failed payment recovery and cohort retention, computed from billing events.
Architecture
How it fits together
A typical implementation flow, with explicit responsibilities at each boundary.
Integrations
- Payment processors for subscriptions and invoicing
- Transactional email for dunning and receipts
- Accounting software for revenue posting
- Access control in the product being sold
- Tax calculation services where required
- CRM for member records
- 01
Subscribe
Create the processor subscription and record the selected terms.
- 02
Resolve
Derive access from verified billing state and explicit entitlement rules.
- 03
Reconcile
Compare provider records, delayed events and manual adjustments.
Security and controls
Design for the exceptions, not just the happy path.
Use hosted payment-method updates. Audit complimentary access and manual billing changes. Do not grant access based solely on a client-supplied payment result.
Technology options
We select the final stack after reviewing your existing systems and operating requirements.
Security and IP practicesFit
Industries that use this
FAQ
Questions people actually ask
Why derive entitlement instead of storing it?
Because a stored flag drifts. Derived entitlement reads the current subscription state at request time, so a failed renewal, a mid cycle upgrade or a late webhook can never leave access wrong.
What happens when a renewal payment fails?
The subscription moves to past due, the retry schedule and notification sequence start, and access is suspended at the point in the grace period you choose rather than immediately by default.
Can we keep old prices for existing members?
Yes. Grandfathered pricing is held on the subscription, so a public price change does not touch current members unless you decide it should.
Do you support seats for organisations?
Yes, with seat counts, proration when seats change, and an administrator who manages membership within the organisation.
How are duplicate webhooks handled?
Events are stored by processor identifier and processed once. State transitions are idempotent, so a repeated event is a no operation.
Does card data touch our systems?
No. Payment details are collected by processor hosted fields or a processor managed checkout, so cards never reach your application.
Let’s talk about the system you need.
Tell us where the current process breaks down. We can map the workflow, examine the integration requirements and define a practical scope for the build.
- A mutual NDA is signed before project details are shared.
- Scope is fixed in writing before any build starts.
- You own the source code, the IP and the documentation at delivery.
- Support plans are available and tailored on a discovery or technical call.