Every business ends up handling a cancelled appointment eventually, but "cancel" and "refund" aren't the same action, and treating them as one leads to either unnecessary payouts or client disputes that didn't need to happen. Separating the two clearly is worth doing before you're dealing with an actual case, not during one.
Cancelling is a status change -- refunding is a separate decision
Cancelling an appointment just marks it cancelled and frees the slot back up; it says nothing on its own about whether money moves. Whether a refund happens is its own decision, made on top of that, based on your payment policy and the specific circumstances -- a client cancelling with plenty of notice is a different case from a client cancelling an hour before, even though both end with the same "cancelled" status.
In ScheduloApp, this separation is literal: cancelling an appointment without a refund still notifies the client by email automatically, but no money moves. If a refund is actually owed, that's the separate Refund action on the appointment -- it reverses the original Stripe charge and sends its own confirmation, independent of the cancellation itself. Doing both in the right order (cancel first if the refund logic depends on status, or refund directly if your policy says a specific cancellation always gets money back) matters less than understanding they're two decisions, not one action.
Who gets to cancel matters as much as whether they can
A client cancelling their own booking and a business cancelling on a client's behalf are different flows with different defaults, and conflating them is a common setup mistake. Your payment policy controls whether clients can cancel or reschedule themselves at all, and -- just as importantly -- how close to the appointment time that self-service window still applies. A policy that's too permissive here (cancellations allowed right up to the appointment) undermines everything a deposit or full-payment requirement was meant to protect against in the first place; a policy that's too restrictive just pushes clients to not show up instead of cancelling properly, which is worse for you either way.
What actually happens on a refund, and how fast
A refund reverses the original Stripe charge, not a separate manual payment -- so the money genuinely goes back the way it came, not as a new unrelated transaction. It's worth setting the right expectation with clients here: refunds typically take 5-10 business days to actually land back in their account, which is a Stripe/banking timeline, not something either of you can speed up once it's initiated. Saying this upfront in your cancellation policy avoids a client assuming something's gone wrong three days later when their refund hasn't appeared yet.
A sensible default policy, if you don't already have one
- Client-initiated cancellation with reasonable notice (24-48 hours is a common cutoff): full refund, no friction -- this is what keeps a deposit requirement from feeling punitive rather than protective.
- Client-initiated cancellation with little or no notice: policy-dependent, but this is exactly the case a deposit exists to cover -- keeping it isn't unreasonable given the lost slot.
- Business-initiated cancellation (you can't make it, double-booked, closing unexpectedly): full refund essentially always -- the client did nothing wrong here, and a disputed charge from a business-caused cancellation is a bad outcome either way.
None of this needs to be complicated to communicate -- a short, clear cancellation policy stated once avoids almost every awkward conversation that would otherwise happen case-by-case.