Collect in context
Connect recurring plans, add-ons, packages, services, retail, and account balances to the same member relationship.
Payments & billing
Connect recurring billing, one-time purchases, packages, balances, failed payments, recovery, and revenue visibility to the member relationship behind every transaction.
The payments operating advantage
Payments become operationally useful when the team can see what was charged, why it was charged, what member relationship it belongs to, what changed, and what should happen next.
Connect recurring plans, add-ons, packages, services, retail, and account balances to the same member relationship.
Surface failures, past-due balances, refunds, credits, disputes, and account changes before they become hidden back-office work.
Give billing, member service, access, communication, and reporting workflows the context needed to coordinate the next action.
Payments workspace
The revenue summary, transaction detail, recurring obligations, past-due work, and reconciliation picture should agree because they are built from the same operating context.
See your billing modelRevenue relationships
Recurring plans are central, but the full financial relationship may also include add-ons, packages, appointments, classes, retail, merchandise, credits, and adjustments.
Primary plans and recurring add-ons with billing cadence, renewal, account status, and member context.
Prepaid sessions, appointments, assessments, recovery services, and other one-time purchases.
Retail, merchandise, drop-ins, and desk transactions connected to inventory and the member where appropriate.
Refunds, credits, discounts, account corrections, and other changes with an auditable operating reason.
The billing lifecycle
Each stage adds context the next stage should not have to reconstruct.
Connect the agreement, plan, package, service, amount, cadence, and payment method.
Process recurring and one-time obligations while preserving the member and revenue context.
Separate successful collections, failures, refunds, credits, adjustments, and open balances.
Coordinate payment updates, recovery, member support, access decisions, and account changes.
Match transactions, settlements, adjustments, and reporting back to the operating record.
Exceptions in context
Attendance, membership value, service use, communication, access, and prior account history can change the right next action.
Connected to the rest of the platform
Memberships, services, scheduling, access, communication, and reporting should use the same account truth instead of maintaining parallel versions of payment status.
Payments questions
The right billing setup depends on memberships, add-ons, packages, services, locations, payment rules, access policies, and the way the team resolves exceptions.
Yes. The financial relationship can include recurring memberships and add-ons alongside packages, appointments, classes, retail, merchandise, credits, and other one-time transactions.
Transactions can retain the member, plan, package, add-on, service, or point-of-sale context behind the charge so billing history and operational history stay aligned.
The failed obligation can be surfaced with the member relationship, amount, plan, attendance, services, communication, and account history. The exact recovery and access workflow should be configured around the business policy.
Refunds, credits, discounts, and account adjustments can be recorded with the related transaction and operating reason so reporting and reconciliation reflect the change.
Multi-location setups can preserve the shared member and account relationship while still reporting transactions, services, registers, and revenue by location where needed.
The transition plan depends on the current processor, memberships, future billing obligations, balances, payment methods, transaction history, packages, locations, and required integrations. Those details are mapped before a specific migration sequence is recommended.
See your revenue model in BuzOps
A useful walkthrough should show how money moves through the real member relationship—not only how a transaction is processed.