Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.1club.ai/llms.txt

Use this file to discover all available pages before exploring further.

Billing in 1Club is built on three distinct concepts that are deliberately kept separate. Once you have the model in your head, every screen in the Billing menu lines up.
  • A transaction is what someone owes you. One row per obligation (a booking fee, a membership charge, a signup fee). Has a paymentStatus of pending, paid, overdue, void, partially_paid, refunded, or cancelled.
  • A payment is how money was collected. One row per settlement event, linked to one or more transactions via a join table.
  • An invoice is a document that groups outstanding transactions for a contact, with a number and a due date. Invoices don’t move money on their own.
This separation is why you can record a payment without ever issuing an invoice (e.g. taking cash at the front desk for a single booking), and why an invoice can contain transactions from several different bookings or memberships.

​
The Billing menu

PageWhat it listsWhen to use it
PlansMembership and pass templatesSet up pricing tiers and recurrence rules.
TransactionsIndividual obligationsAudit what’s owed, void mistakes, charge or record payment in bulk.
InvoicesReceivable documentsIssue formal invoices, send payment links, download PDFs.
Bill runsBatch invoice generationsRoll up a month of pending transactions into invoices in one go.
PaymentsSettlement recordsSee what’s been collected, including who recorded it.
Payment methods is also part of billing, but lives under Settings because it’s a one-time configuration: which methods (Stripe, cash, bank transfer, wallet) your organization accepts.

​
How a charge usually flows

The typical flow for a paid activity is:
  1. A booking, membership, or signup fee is created. 1Club writes a transaction with paymentStatus = pending (or paid if the amount is zero).
  2. Either the system or an admin collects payment. That can happen up front (Stripe Payment Element in the member portal, or an admin recording a manual payment), at check-in if the booking policy says so, or later from an invoice.
  3. When the payment succeeds, 1Club creates a payment row, links it to the transaction(s) via payment_transactions, and flips the transaction’s status to paid. Pending bookings tied to that transaction are confirmed.
Invoices are optional. They get created when:
  • You manually invoice a transaction from its details page.
  • You run a bill run, which sweeps every pending non-void transaction for a period and groups them into invoices.
  • A scheduled bill run fires on a cron (configured under Settings > Billing > Automated bill runs).

​
Recurring memberships

For recurring plans, an hourly job (recurring-transactions) does three things:
  • Creates the next membership_recurrence transaction when a billing period rolls over.
  • For memberships flagged payment required up front, it attempts to charge the contact’s default Stripe payment method when the recurrence becomes due. If no default method is on file or the charge fails, the transaction stays pending.
  • Marks any pending transaction whose due date is in the past as overdue.
It does not send invoices and it does not retry failed charges. Retries are manual: open the transaction or invoice and use Charge or Add payment.

​
What lives where

  • Transaction obligations: Billing > Transactions.
  • Settlement events and the Created by column: Billing > Payments.
  • Invoice documents, PDFs, and payment links: Billing > Invoices.
  • Batch invoice generation: Billing > Bill runs.
  • Plan templates: Billing > Plans.
  • Stripe connection, manual payment methods, tax rates, revenue accounts: Settings > Billing.