Payments

The payments page is a read-only history of every payment transaction recorded for your organisation. Payment records are created automatically by the booking and checkout flow — you cannot create payments here, and the amount, payment method and status of a transaction can never be changed on this screen.

Overview

Payments are shown in a paged table, most recent first. Each row covers one transaction: when it happened, which client it belongs to, how it was paid, the linked order reference, the amount and its current status. The only thing you can change here is the tags and internal notes attached to a transaction (see Expanding a row).

Payment status lifecycle

The status shown in each row is a colour-coded chip that the page derives entirely from the transaction's lifecycle timestamps — it is never set by hand:

• Pending (grey) — the transaction exists but has not yet been authorised.
• Authorised (blue) — the payment has been authorised but not yet captured.
• Captured (green) — the funds have been captured. This is the normal completed state.
• Failed (red) — the payment failed.
• Refunded (orange) — the payment was refunded.

A refund takes precedence over every other state, then a failure, then a capture, then an authorisation; if none of those timestamps is present the transaction is shown as pending.

Columns

The table shows these columns:

• Date — the most relevant lifecycle moment for the row (captured, otherwise authorised, otherwise failed, otherwise refunded), shown with date and time.
• Client — the client the payment belongs to.
• Payment method — how the payment was made.
• Order reference — the reference of the linked order.
• Amount — the transaction amount, formatted in your currency and right-aligned.
• Status — the colour-coded status chip described above.

A trailing cell shows a small tag icon when the row has tags and a note icon when it has internal notes, so you can spot annotated transactions at a glance.

Searching and filtering

Use the search bar to find transactions. The search runs automatically a moment after you stop typing.

Next to the search bar, the month/year picker restricts the list to a single calendar month. You can pick any month within the last five years up to the current month. The list always covers a whole month — there is no arbitrary date range or single-week selection.

Expanding a row (timeline, tags & notes)

Every row can be expanded to reveal more detail:

• A timeline table with four columns — Authorised at, Captured at, Failed at and Refunded at — each showing the exact date and time the step occurred, or left blank if it never happened.
• A tags and internal notes panel. You can add tags and post timestamped internal notes here (each note records who wrote it and when). Changes are not saved until you press Save; the button stays disabled until you have made a change.

These tags and notes are the only data you can change on the payments page.

Exporting to Excel

The Excel button above the table exports the rows currently shown to a spreadsheet — date, client, payment method, order reference, amount and status. The button is disabled while the list is empty.

Read-only and offline behaviour

Payment history is loaded live from the server in pages of 25 rows, with sorting handled server-side. Because the data is never cached locally, this page needs an internet connection: when you are offline it shows a message that a connection is required instead of the table. The list reloads automatically when you switch organisation. If the page failed to load because you were offline, it retries automatically as soon as a background sync completes — a sync that finishes while the list is already showing does not refresh it.