# Payments (/docs/incidents/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](/docs/incidents/linking-records) — the money always lives on the booking's payment history; the incident holds a reference to it.

Tracking against a damage amount [#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 [#damage-charges-dont-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 [#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.

How a hold behaves when captured depends on how it was created, not on whether it's attached:

* A hold **authorized from the incident page** (Take payment → Authorize Only) is a damage hold. Capturing it — from anywhere — settles it as damage money: no over-charge permission needed, and the booking balance is untouched.
* A **normal booking hold** that you attach to an incident keeps its normal behavior: capturing it from the booking page still reduces the booking balance and still respects the over-charge cap. Attaching is just a link — it never changes what a payment does.

Detaching [#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.

<Callout type="info">
  A payment can belong to at most one incident at a time. If a payment is already attached to another incident, detach it there first.
</Callout>

Related How-To Guides [#related-how-to-guides]

* [Take a Payment for an Incident](/how-to/incidents/take-a-payment-for-an-incident)
* [Link Records to an Incident](/how-to/incidents/link-records-to-an-incident)