Payments
Amount due and balance
The Sale checkout review shows the authoritative total, payments and remaining amount. See Sales cart & checkout before recording tenders.
Mixed payments
The Sale checkout accepts three tenders, in any combination. Payments belong to the Sale and are allocated to its line-specific Invoices:
| Method | Use for | Notes |
|---|---|---|
| Cash | Physical cash | Feeds the drawer's expected-cash figure |
| EFTPOS | Card via terminal | Process on the terminal first, then record the approved amount |
| HICAPS | Health-fund claims | At most one HICAPS entry per checkout, and it must name a service line — a retail-only Sale cannot take HICAPS. See workflow below |
Voucher, package and coupon redemption are allocations against a service line that the server supports, but the current POS checkout screen has no control to select them. There is no free/comp tender. The recorded tenders must add up to exactly the Sale total before you can confirm — there is no part-payment.
📷 Screenshot placeholder — Payment modal with mixed methods
Example: a $150 Sale = $100 HICAPS on its service Invoice + $30 EFTPOS + $20 cash. Three entries, fully allocated.
Packages
A guest with a prepaid package doesn't "pay" at the till — a package session is allocated to the service line on the server side, deducting one session and linking the service to the package. There is currently no Package control in the POS checkout screen. The therapist's commission is calculated on the service's full menu price, not zero.
The HICAPS workflow
HICAPS claims happen on the terminal, not in the browser. POS records the outcome:
- Swipe the member card and process the claim on the HICAPS terminal.
- Terminal approves → note the benefit amount and approval reference.
- In POS, add a HICAPS payment entry with that amount + reference.
- Any gap → take it as EFTPOS/cash entries as usual.
- At Final Settlement, the period's terminal totals must match the terminal's own batch report — that's the reconciliation.
Terminal declined with a code you don't recognise? Open HICAPS Help in the sidebar to look up HICAPS and EFTPOS response codes.
Once a HICAPS payment is recorded, a Treatment Record draft (Pending completion) is created on the Visit's Treatment Records tab. Complete it; only a manager can lock it. See Receipts.
Record exactly what the terminal approved. If the terminal declined, there is nothing to record in POS — a HICAPS entry without a terminal approval behind it will surface as a variance at Final Settlement.
Refunds
Refunds for a Sale-linked Visit are scoped to the exact Sale line, original Invoice and Payment allocation. The retired Visit payment buttons are intentionally unavailable for these Visits, so they cannot create a second transaction history.
Only service lines can be refunded from POS — use Refund service on the closed Sale's service line (see Sales cart & checkout). Voucher, package and retail lines are refunded or returned from Admin. Refunds are refused once the Visit is closed.
The refund belongs to the Business Period in which you record the refund. The original payment stays in its original Business Period. For example, refunding yesterday's payment after today's period has opened records the refund in today's active period; it does not rewrite yesterday's Settlement.
Reversing a voucher / package / coupon redemption
Redemptions paid from a customer asset are not refunds — no cash ever left the till, so nothing can be "refunded". Their reversal is likewise scoped to the exact Sale line: use Reverse redemption on that line.
A reversal restores the asset in full (voucher balance, package session, or coupon), removes the amount from the visit's payments, and keeps the original redemption visible in history. A reason is mandatory. A redemption can be reversed once; it is refused if the payment already carries an ordinary refund, or if the asset has expired or been cancelled. Attempting an ordinary refund on these entries is rejected by the system.
The visit may become partly or fully unpaid after the reversal. Check the new balance and collect another tender when required. The TaxInvoice stays valid because it follows the sale/service, not its tender. Cancelling or changing the service—and any related invoice or credit-note correction—is a separate workflow.
Duplicate-submission protection
The system blocks duplicate payment/refund submissions (double-click, network retry) and answers with a "duplicate request" notice.
- This is protection, not an error.
- Before retrying, check the payment list — in most cases the first attempt already landed.
Closing a visit
- Balance = 0 → Close visit completes the story.
- Balance outstanding → normal close is refused. Take payment first.
- Guest left unpaid → Force close: PIN + written reason. The gap is recorded as what it is.
Force close exists so reality gets recorded — not to make unpaid visits disappear. Managers see forced closes and their reasons in Admin.