The gap between the click and the confirmed booking, explained

Someone messages you twenty seconds after picking a time. I think I booked but nothing has come through, did it work? You check the dashboard and there is no order yet. Ninety seconds later the order appears, the calendar event exists, the confirmation has gone out, and the panic was about nothing. That short gap is not a fault. It is the rule that keeps two people from turning up to the same call.

What actually happens in those few seconds

When someone picks a time on your storefront they are sent to checkout. Their card details go to Stripe, not to store.fan. Stripe asks the issuing bank whether the payment can proceed. Depending on the bank, the country and the amount, that can be instant or it can involve a second step: a push notification, a code, a fingerprint on a phone that is in another room.

Only when Stripe confirms the payment does store.fan write the booking. That is when the slot is removed from your public availability, the order lands in your dashboard, the buyer gets their private order page, and on a paid plan the event and its Google Meet link appear in your calendar. Nothing is written before that point, which is why there is no record to look at during the wait.

The genuinely hard part is that this is invisible to your customer. They clicked, so in their head it is done. If their bank throws up an extra verification screen and their phone is charging in the kitchen, the wait can stretch to a couple of minutes and it feels like something has broken. It has not, but you cannot see inside their bank and neither can we. All you can do is set expectations on the page before they get there.

Holding first versus paying first

Most booking tools were built for calendars, not for shops. They reserve the time the moment a form is submitted and treat payment as an afterthought, or as a step that happens later, or in person. That is a reasonable design for a dentist and a poor one for a creator selling a fixed number of hours a week. The comparison below is between that generic status quo and how a paid booking works here.

Setting it up so the wait feels normal

None of this needs configuring, because payments and availability are already wired together. What you can control is how much explaining the page does before someone reaches checkout, and how much of the brief you collect while they are already committed. Work through the steps below in your dashboard.

1. 1Create a coaching call or booking product and set its length, price and the days and hours you are willing to be booked.
2. 2Connect Google Calendar on a paid plan so your existing commitments are respected and a Google Meet link is generated for each confirmed booking.
3. 3Add order-form questions — short answer, long answer or multiple choice — for the things you always end up asking by email afterwards.
4. 4Write one line in the product description telling people the time is confirmed once payment goes through, and that a confirmation follows within a minute.
5. 5Buy your own slot as a test, on a phone, on mobile data, and watch how long the whole thing takes on a real network.
6. 6Check the order appears in your dashboard with the answers attached, then refund yourself and note how the customer record behaves.

What it looks like across a month

Say you open eight slots a week at £60 and roughly a third of the people who reach checkout do not complete. Under a hold-first system those abandoned attempts sit on your calendar until you notice them, and the slots they blocked were unavailable to everyone else in the meantime. You do not lose money you had; you lose the sales that could not get through the door. That loss is quiet, which is why it goes unmeasured for months.

With payment-first the same abandonment happens and leaves no trace. The eight slots stay eight slots. Your per-product analytics then tell you something useful rather than something confusing: views on the booking product, buyers, revenue, and where the traffic came from. If views are healthy and buyers are not, the problem is the price or the description, not a calendar clogged with reservations that were never real. Numbers like these are illustrative, not a forecast.

The mistake most people make

The mistake is apologising for the wait by adding a manual escape hatch: a message that says if it does not go through, just DM me and I will pencil you in. Within a fortnight you are running two systems, one of which lives in your head, and the calendar is no longer the source of truth. If someone's payment genuinely fails, send them back to the same product page rather than opening a private channel. One route in means one place to look when something goes wrong, and it keeps every booking inside the customer list and the revenue figures instead of scattered across your inbox.

A booking system earns its keep by being boring. Times that exist are real, times that are gone are paid for, and the only thing standing between a click and a confirmation is a bank doing its job. Once you stop treating the gap as a bug, you can write one sentence on the product page that removes almost every anxious message about it.