Payments

When an incident ends with the customer paying for damage — a cracked hull, a lost paddle, a torn sail — the Payments section of the incident keeps that money tied to the case file. There are two ways a payment ends up on an incident:

• Take payment — charge the customer right from the incident page: card on file, a new card, a card reader, or a manual payment (cash, transfer, other). The payment is recorded on the linked booking and attached to the incident automatically.
• Attach from booking — link a payment that was already taken on the booking (for example, a security-deposit hold placed at check-in, or a charge staff took from the booking page before the incident was written up).

Both require the incident to have a linked booking — the money always lives on the booking's payment history; the incident holds a reference to it.

Tracking against a damage amount

The incident's Total damage amount field (in the Details card) records the assessed cost of the damage. It's optional and purely informational — nothing is enforced against it. When set, the Payments section shows a running Total collected of $X damage line so you can see at a glance whether the damage has been recovered. Holds that haven't been captured yet don't count toward the collected total.

Damage charges don't touch the booking balance

A charge taken through Take payment is a damage charge, not a booking payment:

• It never applies to the booking balance. A fully-paid booking stays fully paid — it won't show as overpaid after a $200 damage charge, and refund tooling won't treat the damage money as booking credit.
• It's exempt from the over-charge cap. Normally staff without the payments: overcharge permission can only charge up to the remaining balance; a damage charge from the incident flow is deliberate, so any staff member with the Incidents permission can take it.
• It still appears in the booking's payment history and transaction list, and can be refunded through the normal refund flow — refunding it won't disturb the booking balance either.

Payments attached with Attach from booking keep whatever balance behavior they already had — attaching is just a link, it never changes the money.

Working with holds

If you placed an authorization hold (e.g. a security deposit) on the booking, you can attach it to the incident while it's still a hold — it shows with a Hold (not captured) badge and a Capture button.

This is the recommended flow for the classic security-deposit case: hold a deposit at check-in, and if damage happens, attach the hold to the incident and capture it from there. Capturing from the incident page settles the hold as damage money — no over-charge permission needed, and the booking balance is untouched. Partial captures work too: capture just the repair cost and the rest of the hold is released back to the customer automatically.

Where you capture from matters:

• A hold captured from the incident page is damage collection: exempt from the over-charge cap, never applied to the booking balance.
• A hold authorized from the incident page in the first place (Take payment → Authorize Only) is a damage hold from birth — capturing it from anywhere settles it as damage money.
• A normal booking hold captured from the booking page keeps its normal behavior even if it's attached to an incident: the capture reduces the booking balance and respects the over-charge cap. Attaching is just a link — it never changes what a payment does on its own.

Detaching

Detaching a payment removes the link only — the payment itself stays on the booking untouched. Use it when a payment was attached to the wrong incident.

Related How-To Guides

• Take a Payment for an Incident
• Link Records to an Incident