Gym Membership: Subscription, Freeze, Cancellation, and Collection in One Customer State

A membership is not a boolean. It is one of five states, and every transition between them has a defined effect on the next charge and on entry at the door. When the app, the front desk and the billing system each hold their own version of that state, the member gets a different answer in every one of them. What follows is a technical description of a data model, not legal or financial advice.

Five states, and what each does to three systems

One state has to answer three questions at once: do we bill, does the door open, and what does the member see in the app.

The third row is the one that collapses first in any system holding a boolean: "cancelled but still walking in" is not a contradiction, it is a perfectly legitimate state that lasts until the end date. The general model, beyond fitness, is taken apart in a state machine for recurring subscription billing.

The transitions, and what each does to the next charge

A well-defined state model is a list of permitted transitions, not a list of states. Each transition carries a trigger, an effect on billing, and an effect on the end date:

What the table omits matters just as much: there is no direct move from frozen to cancelled without an explicit decision in between, and no move from cancelled back to active. A renewal is a new membership pointing at the old one, not the resurrection of a closed record.

Why does a frozen member still get charged?

Almost always for one of two reasons, and both are immediately identifiable.

The first: the collection run read the state at the moment it started, rather than the state in force on the charge date. If the freeze was recorded on the 28th and starts on the 1st, and the run went out on the 31st, "active" is what the run saw. The fix is not in the scheduling but in the query: the state you ask for is the state on the charge date.

The second: the collection file has already gone. A batch of direct-debit instructions is a document that leaves you and arrives somewhere, and once it has been sent, removing a line from it is no longer a change inside your system. That is why every charge deserves a field marking it as included in a dispatched batch, and locked. The difference between debit batches and card standing orders is discussed in Masav direct debits vs card payments.

Effective dating: a state is a range, not a value

The row holding the state should look like this:

• membership_id - the membership, not the customer. One customer can hold two memberships over time.
• state - one of the five values, from a closed list.
• valid_from and valid_to - the validity range. An empty valid_to means this is the current state.
• requested_by and approved_by - who asked and who authorised. Sometimes the same person, in which case both fields carry the same value.
• reason - from a list, never free text.
• document_ref - a pointer to the request as received, where one exists.

"What was the state on 1 October" becomes a range query rather than a guess. The other side of that coin is that an existing row is never updated: a change closes the previous range and opens a new one. Commercial billing models are built this way explicitly, and what it looks like in an external system is visible in Stripe Billing subscriptions.

Is in-arrears a state or a flag?

For management purposes it is a state; for door access it is a flag. Both can be true at once if you separate them properly.

Arrears is derived from the charge ledger: a charge exists whose due date has passed and which has not been matched to a payment. It is not written by hand and not typed in by a receptionist. The moment it is typed in, there are two sources for one fact, and they will diverge within weeks.

Door access is a separate decision resting on the state and the balance:

1. Immediate block - rare, and usually excessive for a single day of lateness.
2. Block after a day threshold - the threshold is a setting, not a rule in code.
3. A front-desk alert with no block - entry opens and a note appears for the receptionist.

All three options derive from the same data. What changes is one setting, which is exactly what lets a club change policy without touching code. Building the surrounding operations is covered in automation for gyms and coaches.

A daily reconciliation between the door and the ledger

At the end of each day it is worth running a short check that looks only for contradictions:

• Members in a frozen state with a recorded entry.
• Members in a cancelled state for whom a charge was created.
• Charges created for a date on which the state was not active.
• Members past the arrears threshold whose entry opened anyway.
• Active members with no valid collection instrument.

Those five lines are a short report on most days, and when it lengthens it is a sign that one specific transition is failing repeatedly. An empty report is not the goal. A report nobody reads is the problem.

What actually breaks

• A freeze recorded as a note. "Frozen, we spoke" in a comments field is not a state and affects no calculation.
• Two memberships for one person. An old membership never closed keeps generating charges alongside the new one.
• A cancellation dated today. A member who asked to finish at month end is blocked at the door immediately.
• A manual payment never matched. The money arrived, the charge stayed open, and the member stayed in arrears.
• A run that executed twice. With no unique key per charge, the same month is collected twice.
• An expired payment instrument. A card past its expiry creates arrears that look like non-payment and are not.

Sources

• Stripe Billing - Subscriptions overview
• Stripe - Idempotent requests
• Masav - the Israeli banking clearing centre