Transactions

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.

A transaction is a single line of “X owes Y for Z.” Every chargeable event in 1Club - a booking, a membership creation, a recurring membership period, a signup fee, a product sale, an external program entry - writes exactly one transaction. Settlement happens separately through payments linked over a join table. Open the page at Billing > Transactions. The grid pages on the server and is tab-filtered into All, Pending, Overdue, Paid.

​

Anatomy of a transaction

Each row carries:

• Date of the obligation.
• Type (booking_creation, booking_cancellation, membership_creation, membership_recurrence, membership_signup_fee, membership_cancellation, product_sale, external_program_entry, checkin_creation).
• Description describing what was billed.
• Contact the transaction is against.
• Amount, Tax amount, Total amount, and Currency (the organization currency at the time of creation).
• Payment status: pending, paid, void, failed, settled, overdue, partially_paid, refunded, or cancelled.
• Invoiced flag. Once a transaction has been wrapped into an invoice (manually or by a bill run), this is true and the obligation will not be picked up by future bill runs.
• Optional foreign keys to a booking, membership, product, external program, tax rate, and revenue account.
• Optional parent / child links, used to chain related entries together (for example a booking_cancellation referencing the original booking_creation).

Zero-amount transactions are auto-marked paid at creation, so a free booking still produces a transaction but it never blocks anything.

​

How transactions get created

Most of the time you won’t create transactions by hand. They arrive when:

• Someone is booked into a class, an area, or with an instructor. The booking flow writes the transaction at the price implied by the membership or the override.
• Someone buys a plan. You get membership_creation plus, when applicable, membership_signup_fee.
• A recurring membership period rolls over. The hourly recurring-transactions job writes the next membership_recurrence transaction.
• A booking is cancelled with a refund or charge policy. You get booking_cancellation linked to the original.
• A product is sold through the POS.

You can also create one by hand from the page header Add button - for example to record an ad-hoc charge that doesn’t correspond to a booking or membership.

​

Transaction actions

From a row or from the details page:

• Add payment. Available when the status isn’t paid or void. Opens the payment dialog, where you pick a payment method (manual or Stripe) and record the settlement.
• Add invoice. Available when the transaction hasn’t been invoiced yet, has a contact, and isn’t void. Wraps the single transaction into a new one-line invoice and navigates to the invoice page.
• Void. Available for any transaction not already void. Marks the transaction void so it stops showing as owed and stops being picked up by bill runs. Voiding is a soft delete - the row remains for audit.
• View opens the details page.

​

Batch actions

Multi-select in the grid unlocks two batch operations:

• Charge. Calls Stripe for every selected transaction’s contact, charging their default payment method. The results dialog summarises which transactions succeeded, which failed, and the reason for each failure (no default method, charge declined, etc.). It uses idempotency keys built from the transaction ID and current date so reruns on the same day won’t double-charge.
• Record manual payment. Opens a dialog where you choose a configured manual payment method (cash, bank transfer, etc.) and a payment date, then writes a payment row against each selected transaction. Transactions already paid or void, or with zero remaining balance, are skipped and counted in the summary so you can see exactly what landed.

​

Transaction details

Beyond the same fields shown in the grid, the details page exposes:

• The payment method column lists each payment row linked to this transaction with amount and date, each linking to the payment.
• The full tax breakdown when a tax rate applied (rate name, percentage, description).
• Recurrence info for membership_recurrence transactions: auto-renew flag, billing frequency, and the period start/end dates.
• The linked booking or membership as a clickable card.
• A Transaction relationships card showing the parent and any children, so you can trace a cancellation back to the original booking or follow a chain of recurring periods.
• All linked Payments in a grid at the bottom, including partial and refunded payments.

​

How payment status flows

When a payment is recorded, its outcome determines the transaction’s new status: A successful payment also flips any pending booking on that transaction to confirmed. The hourly job that processes recurring memberships also runs a sweep that flips any pending transaction with a date in the past to overdue (start of UTC day). overdue is treated as a flavor of pending when invoice status is derived.

​

Caveats

• The user-facing “outstanding transactions” query treats anything not paid as payable, so theoretically a cancelled transaction could surface there until it’s explicitly excluded.
• Voiding a transaction doesn’t refund associated payments. If money was actually collected and now needs returning, refund the payment first, then decide whether to void the obligation.

​

Related

• Payments - the settlement events linked to transactions.
• Invoices - how to wrap transactions in a sendable document.
• Bill runs - sweeping pending transactions into invoices in bulk.
• Booking policies - decides when a booking’s transaction is created and when it must be paid.