Payments and deposits

Payment events come from your payment provider and are recorded against the booking they belong to: authorizations, captures, refunds and voids, each with the provider’s event identifier, reference, amount and time. An event counts only once it is verified. A booking moves from held to confirmed only with the deposit evidence in place, and any action with a money effect needs verified payment evidence behind it.

Because each event carries the provider’s identifier, the same event delivered twice is recognised. Refunds and voids are their own events, so the booking’s payment history reads in order: deposit authorised, captured, partly refunded after a cancellation.

The payments clerk verifies events; coordinators read them before confirming.

• Verified or not counted. Unverified events do not support confirmation.
• Every event kept. Refunds and voids are recorded as events, never as edits to earlier ones.
• Duplicates recognised. The provider’s event identifier stops the same payment counting twice.

Agree how payment events reach the system from your provider and who verifies them. Agree the deposit needed to confirm each event type and your refund rules for cancellations and no-shows. Card processing stays with your provider. Prepare examples of a deposit, a deposit captured later, a partial refund and a voided authorization.

A client pays a deposit online. The authorization arrives from the provider but is not yet verified, so the coordinator cannot confirm the booking. When the capture is verified the next morning, the coordinator confirms. Three weeks later the client cancels inside the refund window; the refund is recorded as its own event and the booking’s history shows the full sequence.

If the capture had failed instead, the booking would have stayed held and the coordinator would have seen the unverified authorization on the list, with time to chase the client before the hold expired.

• Unverified payment events — Events waiting for verification.
• Payment events by type — Authorizations, captures, refunds and voids per booking.

• Request to confirmed booking: Where deposit evidence is needed.

Plan integrations with your payment provider.