Skip to content
Membership capability

Membership freezes: pause the member, keep the billing honest

Updated 4 min read

Freezes in the Membership accelerator are date-bounded records, not status flags. Frozen status is derived from the freeze dates, billing swaps the recurring fee for a configurable freeze fee inside the window (with add-ons and discounts suspended), every charge references its freeze, and the whole operation can be previewed before it commits.

What does the freeze capability do?

It gives operators a retention tool that does not create billing debris. A member pausing for injury or travel gets an accurate, previewed financial change; the operator keeps the mandate and the relationship; and nobody spends month-end unwinding wrong charges.

  • A freeze is a record. Request date, start date, optional end date, and whether it was member-requested or staff-created. Everything else derives from it.
  • Fee replacement, not patching. Billing dates inside the window produce the freeze fee instead of the recurring fee, through the same billing machinery, with add-ons, ad-hoc charges, and discounts suspended for the duration.
  • Traceable charges. Each freeze-period charge references the freeze that produced it, so “why was I charged this?” is answered from the record.
  • Preview before commit. The freeze runs through the identical lifecycle logic in a non-persisting mode first, returning the exact charges and resulting state for the member to confirm.
  • Derived status. Active, frozen, and cancelled are computed from the freeze and cancellation records, including a grace date marking when the current freeze ends. Editing the freeze’s dates updates status and billing with no secondary edits.

Where the freeze fee is configured

Freeze fees are prices, and they are modelled with the same depth as every other fee: set per package per site alongside the recurring and joining fees, captured per member at signup so later list-price changes respect existing agreements, and changeable on a future effective date through scheduled price changes.

Why it matters

A freeze is the alternative to a cancellation, which makes it a revenue feature. The operational difference between a flag-based freeze and a record-based one is the difference between manual refunds, forgotten end dates, and disagreeing status fields on one side, and a previewed, self-resolving, auditable pause on the other. The freeze fees themselves flow through the Billing Engine’s recurring collection, and the companion guide below sets out the full design with demonstration tests for evaluating any membership product.

Frequently asked questions

What happens to billing while a membership is frozen?
For billing dates inside the freeze window, the recurring fee is replaced by the package's freeze fee, and add-on charges, ad-hoc extras, and discounts are suspended. Every freeze-period charge references the freeze record that produced it, so the financial history is auditable.
Can members see the cost of a freeze before agreeing to it?
Yes. Freezes can be previewed by running the identical lifecycle and billing logic in a non-persisting mode, returning the resulting charges and membership state. What was previewed is what committing produces, because both share one code path.
Do open-ended freezes work?
Yes. A freeze records its request date, start date, and an optional end date, so an indefinite freeze is simply one whose end date is set later. Billing and status follow the dates automatically once the end date is known.
See it live

See this working in a demo

Book a consultation and we will demonstrate this capability on the Membership accelerator, against your own scenarios.

Book a demo