How deposits work inside a modern booking flow

When the deposit is captured

The deposit is captured at booking, before the slot is confirmed. Any pattern that says 'we will charge you later' is not a deposit. It is a promise, and promises do not hold slots on a Saturday afternoon.

Concretely, on a booking tool set up this way: the customer selects a time, enters details, sees the deposit amount and the policy in plain language, enters a card, and the confirmation screen appears once the charge or authorization succeeds. If the card fails, the slot is not held. Exact behavior depends on the tool and the policy you configure in it.

Authorization versus charge

Two patterns to inspect in a compatible booking tool, and they appear differently on a customer's bank statement. Charge captures the money at booking. Authorization holds the funds without settling them.

Charge is the simpler configuration. Authorization means the customer does not see a settled line item on a statement days before the visit. Which one is available, and how it behaves, depends on your booking platform and your merchant provider; confirm both before configuring.

Pick one and stay consistent. Mixing the two across services creates refund handling that has to be managed by hand.

Handle failed cards at booking time

A failed card is one friction point to design for in a booking flow with a deposit. The intended mechanics let the customer retry with a different card and finish. Abandonment at the payment step remains a possibility to measure against your own booking data.

The failure needs to be visible, specific, and immediately recoverable. Visible: the error appears next to the card field, not in a red banner at the top of the page. Specific: 'your card was declined' beats 'something went wrong.' Recoverable: the customer can retry with a different card without losing the time slot she already picked.

Where the tool supports it, reserve the slot for a short window during checkout and release it if the card is not captured. Slot-hold behavior is tool-dependent; confirm it before relying on it.

Refunds inside the window

The intended configuration is that a cancellation or reschedule inside the refund window refunds the deposit without a manual step. Whether automatic refunds are supported depends on the booking tool and processor; confirm that behavior in the written scope before promising it to customers.

The point of automating the refund is that the written policy and the configured behavior match. If a customer has to email to get her own money back, the policy and the flow are not the same thing.

Outside the window, credit or retain

When a customer cancels or reschedules outside the refund window, two behaviors work and both are defensible.

Retain the deposit and treat the slot as filled. Or credit the deposit to a rescheduled appointment within a defined period. What is not fair is silence: the customer needs to see, at cancellation time, exactly what happens to the money and when.

Receipts and reconciliation

Send a receipt with the amount, the service, the appointment time, and the refund policy in one line. A timestamped record sent at the moment of booking is the evidence you have if a dispute is filed weeks later.

For reconciliation, tag deposits by service and by appointment date in your payment tool. When you look at last month, you should be able to see deposits collected, refunded, and retained without opening a spreadsheet.