Documentation

Payments

Requires.

  • Payments with View to see the list.
  • Payments with Create to record a new payment.
  • Payments with Modify to edit an existing one.

The Payments pages record money received from a customer and apply it against the customer's open invoices. Payments and invoices are kept as separate records — that's deliberate, because it lets one payment cover several invoices, or a payment sit unallocated until you decide where to apply it.

Getting here

There is no dedicated "payments only" page — payments are managed through the Transactions tab and the payment create/edit forms.

  • Payments appear mixed with invoices on the Transactions tab.
  • Click + New Transaction > New Payment on the Transactions page (only visible if you have create permission).
  • Click a payment row on the Transactions list to open the edit form (only visible as a link if you have modify permission; otherwise the payment type shows as plain text).
  • Or navigate directly to /customers/{id}/customer-payments/create for the create form.

Permission visibility

  • No view permission — Payment rows are completely hidden from the Transactions list. The "Payment" filter type option and the + New Payment menu item are also hidden.
  • View but no create — You see payment rows in Transactions, but the + New Payment option is hidden in the dropdown.
  • View but no modify — You see payment rows, but the type column shows plain text instead of a clickable link. You cannot navigate to the edit form from the list.

Recording a new payment

Click + New Payment.

Parent/child redirect

If parent/child is enabled and this customer has a parent, creating a payment on the child redirects you to the parent. AR lives on the parent, so payments must be recorded there. You'll see the parent's customer in the URL and the form — but the payment still applies to the same invoices (parent invoices + children's "Bill with parent" invoices).

If you meant to record a payment on the child directly and don't want the parent redirect, the child has to not have a parent set. That's an admin/modeling decision, not a payments UI setting.

Payment form fields

Field Required? Type Validation Notes
Payment date Yes Date picker — Defaults to today.
Amount Yes Currency > 0 The total amount received.
Payment method / type Yes Select From the Customer Payment Types catalog Credit card, ACH, check, cash, etc.
Reference Recommended Text — Check number, transaction ID, confirmation code — anything that identifies the payment outside SecurityTrax.
Billing method Conditional Select An active Billing Method on the customer Only shown if the payment method is credit card or ACH. Picks a stored card/account to charge.
Allocations Yes (at least $0.01 total allocated) Multi-row Sum of allocations must equal the payment amount, or you can leave a portion unallocated One row per invoice being paid. Each row shows the invoice number, its balance, and lets you enter the amount to apply.
Notes No Text — Internal notes.

Allocating across invoices

The allocations table is the core of the form. For each open invoice on the customer:

  1. The row shows Invoice # | Amount Due | Amount Applied | Balance After.
  2. Type an amount in Amount Applied. SecurityTrax updates Balance After live.
  3. Repeat for as many invoices as you need.
  4. If the total payment isn't fully allocated, the difference is treated as unapplied credit — SecurityTrax carries it on the customer's account to apply against a future invoice.

Tip. When in doubt, under-allocate rather than over-allocate. Unapplied credit is easy to move later; applying too much to one invoice and having to reverse it creates a messy audit trail.

Saving the payment

Click Save. If you picked a billing method (credit card or ACH), SecurityTrax charges it and waits for confirmation before completing. If it's a check or cash, the payment is immediately recorded as received.

The new payment appears on the Transactions list right away, with a green negative amount (reducing balance) and a link back to each invoice it was applied to.

Editing an existing payment

Click a payment row on Transactions. The edit form has the same structure. You can:

  • Change allocations (re-apply to different invoices).
  • Update the reference or notes.
  • Void the payment (if your permissions allow).

Voiding a payment reverses the allocations — affected invoices go back to their prior balance. Voided payments stay on the list (greyed out or marked) for audit, they just don't affect the running balance.

Heads up. You can't change a payment's date or amount after it's saved without voiding and re-entering. That's deliberate — if the amount was wrong, voiding preserves the audit trail.

Payment methods

SecurityTrax supports:

  • Credit card — charged through your configured payment processor (see Integrations).
  • ACH / bank transfer — same processor path.
  • Check — manually recorded; your bookkeeper handles the actual deposit.
  • Cash — manually recorded.
  • Wire / adjustment / write-off — additional types may be available depending on your catalog.

Each type you see in the dropdown is configured by your admin in Customer Payment Types.

Refunds

If you need to send money back to a customer, don't create a payment — create a Refund Receipt invoice type from the Invoices page, or use the company-wide Refund Receipts flow. A refund receipt is the mirror of a payment: money leaves your account and goes back to the customer.

Related