Deposits, card protection and cancellation requests: what the booking status actually tells you
Understand the difference between a deposit, card protection, a cancellation request and a completed payment in OpenChair.
On this page
A deposit is a payment made before the appointment. Card protection is a separate payment arrangement; it is not a paid deposit. A cancellation request is a booking decision to review. None of those states should be mistaken for a completed charge merely because a request has been sent.
OpenChair supports booking-protection workflows, including secure requests for existing operator-created appointments. The venue decides its policy, and authorised staff need to follow the actual booking and payment result.
This guide explains the operational distinctions. It does not recommend cancellation terms or determine when a business is entitled to retain money or make a charge.
Decide which commitment the appointment needs#
A salon may handle a long colour booking differently from a short service. A lash and brow studio may want a defined commitment for a longer appointment. A day spa may be reserving both a therapist and a treatment room.
Those are reasons to review a policy, not evidence that one particular deposit or fee is appropriate for every business.
Before configuring the software, be clear about what the client is being asked to do. Paying a deposit and completing a card-protection step are different requests, with different implications for the record.
The wording the client sees should agree with the policy the venue has reviewed and the workflow it actually uses. Software settings do not, by themselves, establish authority to charge.
Keep four separate questions in view#
| Question | What staff need to establish |
|---|---|
| What happened to the appointment? | Whether it is still booked, awaiting a decision, changed or cancelled |
| What was the client asked to complete? | A deposit request or the relevant card-protection step |
| What has actually completed? | The recorded request outcome and, where applicable, the payment result |
| What should happen next? | The authorised booking or payment action under the reviewed venue policy |
These are related records, but they do not become the same record because they concern one appointment.
A client may have received a request without completing it. A booking may have been cancelled while its payment situation still needs attention. A card arrangement may exist without any deposit having been paid.
The useful workflow makes those differences visible to the next person handling the appointment.
Send a protection request for an existing booking#
Not every appointment starts in the online booking flow. Staff may create a booking while speaking with a client, then need the client to complete the required protection step.
OpenChair supports a secure deposit or card-protection request for an existing operator-created appointment. The team does not need to treat “booking created” as evidence that the payment requirement has already been satisfied.
Consider an illustrative colour appointment arranged over the phone. Staff enter the agreed booking and send the appropriate request. The client then has a separate step to complete.
The person reviewing the booking needs to check that outcome, not just see that a message was sent. Until the required step has completed, the record should not be described as though the deposit has been collected.
Follow pending, completed and failed outcomes honestly#
A request waiting for the client is unfinished work. A completed protection step needs to be interpreted according to what the request was for. A failed payment attempt is not collected money.
The same principle applies when the outcome is uncertain. Do not replace uncertainty with a confident assumption or immediately repeat a charge without checking what the payment record shows.
Use the recorded status and the supported review workflow. Where a result needs investigation, keep the booking context available so the next authorised person can understand what was requested and what is known.
A receipt or confirmation also needs to be read in context. It should not be used to imply that a different payment, refund or fee has occurred.
Handle a cancellation as a booking decision first#
A client asking to cancel has raised a decision about the appointment. The team needs to establish the appropriate booking action and separately consider any payment implications.
For an illustrative day-spa appointment, the cancellation may release therapist time and a room once the booking change is completed. That does not tell you what should happen to a deposit.
Nor does a cancellation automatically mean a late-cancellation charge should be attempted. The venue's policy, what was communicated and the applicable payment requirements still need to be considered by someone authorised to act.
OpenChair's cancellation controls are tools for handling the decision. They are not an automatic judgement about entitlement to money.
Check the final record at checkout or close-out#
When the visit proceeds, review any recorded deposit or applicable payment arrangement alongside the checkout result. The useful question is what has been paid and what the recorded balance requires, not what somebody remembers sending earlier.
If the appointment changes or does not proceed, keep the booking outcome and the payment outcome clear enough to review later.
This matters when several people share the work. A receptionist may send the request, a therapist may review the appointment and an authorised manager may handle a payment issue. The record should not depend on all three remembering the same conversation.
Explain the next step clearly to the client#
A useful message tells the client what action is needed and how to complete it. It should not describe an unpaid request as a payment received, or a proposed booking change as an already completed cancellation.
For replies involving booking changes, human review remains important. OpenChair's client messaging guide explains the distinction between an eligible routine reply and an authorised booking action.
Test one booking from request to final outcome#
Use one representative operator-created appointment. Review the configured requirement, the message the client receives, the completion state and the final booking and payment record.
Test a request that remains unfinished as well as one that completes. Then check how the team would handle a cancellation or a failed payment without confusing the states.
The objective is a record everyone can interpret accurately. Booking protection supports a deliberate workflow; it does not guarantee attendance, successful collection or a particular cancellation outcome.
