Booking & Calendar
How to hold a booking slot while a customer pays a deposit
Keep an appointment reserved during Stripe Checkout, release abandoned holds, and handle late payments without assigning the same time twice.
Someone picks Tuesday at 2:00, enters their details, and opens Stripe to pay the deposit. While they are paying, another customer chooses the same appointment. Both payments succeed. You now have two customers expecting the same hour.
The booking page looked finished. The problem was the gap between choosing a time and confirming payment.
A temporary slot hold connects those two steps. It gives the customer time to finish checkout while keeping the appointment out of reach of competing bookings in your app. If they leave, the hold expires and the time becomes available again.
Reserve the time before opening checkout
When a customer selects an appointment, your backend needs to check availability and save the hold together. Two requests can arrive almost simultaneously. If each request checks an open slot before either saves its reservation, both can appear to succeed.
Saving the hold inside a database transaction lets the service enforce capacity as it accepts the reservation. For a staff member who can take one appointment at a time, only one competing customer gets the hold.
The hold needs an expiration time and a connection to the customer, appointment, and checkout. Show the customer how long the reservation lasts. That makes the countdown useful: it tells them what happens to the appointment if they leave the payment page open.
Confirm the deposit with Stripe
Customers can close the tab after paying or lose their connection before the confirmation page loads. Your booking service still needs to recognize the payment.
Use server-side confirmation from Stripe to decide whether the deposit has been paid. Check that the payment belongs to the expected reservation and matches the configured amount and currency. A return to your success page can help display the result, but the booking decision needs the payment record behind it.
Once the deposit is verified, the service can confirm a reservation whose hold is still valid. A repeated payment notification should leave the same booking confirmed rather than creating another appointment.
Decide what happens when payment arrives late
A hold can expire before the service receives confirmation of payment. By then, another customer may have reserved the appointment.
Keep that late payment visible for review. Forcing it into the old slot would create the very conflict the hold was meant to prevent. The customer needs a clear next step, and the business needs enough payment and reservation history to offer another time or handle a refund.
This is also why the reservation should retain its history after cancellation or rescheduling. When someone asks what happened, you can trace the appointment and deposit instead of piecing the story together from separate screens.
Keep calendars and timezones connected
The appointment needs to mean the same moment to the customer and the business. Detect the customer's timezone, let them change it, and show the timezone alongside the appointment. Keep the business's working hours in its configured timezone so daylight-saving changes receive the right treatment.
Google Calendar adds another source of availability. Check its busy times and update its events when an appointment changes. Your app's reservation checks protect bookings made through your app; someone editing Google Calendar directly is making a separate change that also needs to be checked.
That distinction matters when testing. Two customers competing inside your app and a staff member adding an outside calendar event are different situations.
Add the booking feature with the difficult cases included
Booking & Calendar gives your coding agent the source for local slot holds, fixed-amount Stripe deposits, timezone handling, Google Calendar checks and event updates, and automated reminders through Resend. It includes the customer booking page, setup instructions, and verification tests.
Your agent connects the service to your existing app and your own provider accounts. You choose what customers can book, the appointment duration, working hours, deposit, and reminder timing. Booking runs alongside your app on Node.js and PostgreSQL; your main app supplies customer identity. You manage refunds and taxes through your Stripe tools.
Before opening bookings, try two customers choosing the same time, a checkout that is abandoned, and a payment confirmed after its hold expires. Those are useful tests of the feature your customers will actually depend on.
Your first Helpful Mod is $99, and each additional different mod is $75. You get the full source code, agent setup prompts, and automated checks, with no Helpful Mods subscription.
See Booking & Calendar and try the sample workspace.
Further reading
Keep reading