Function room booking & pricing
A public booking page for a venue’s function room. The customer picks a date, fills in the event details and pays by card, at a price set by the date. The date is held for five minutes while they pay, and the booking only exists once the payment provider confirms the money arrived.
How a booking happens
- The page asks for availability and gets back the deposit, the booking window and the dates that can’t be booked — nothing else.
- Submitting places a five-minute hold on the date and opens a card checkout for the deposit.
- The booking is not confirmed when the customer clicks pay. It’s confirmed when the payment provider’s signed webhook says the money arrived.
Why it’s built that way
Two failure modes matter for a function room: two families paying for the same Saturday, and a booking that exists without a deposit behind it. The hold closes the first; confirming only on the signed webhook closes the second, because a browser redirect can be faked and a closed tab never arrives.
Moved to dynamic pricing
- Moved from a flat deposit to full payment up front, priced by the date: one price Sunday to Thursday, a higher one on Friday and Saturday, and a peak price from a peak-dates table (December weekends, Christmas Eve, bank holiday weekends). There’s a 14-day full-refund cancellation window.
- Prices were set after researching comparable social clubs in the area. The calendar doesn’t show prices; they appear once a date is picked, and the server, not the page, works out the amount charged.
- New database functions for pricing and the full-payment hold, a rewritten booking function, and an end-to-end test booking before going live.
What went wrong
The payment provider warned that the booking webhook was failing every delivery with “Bad signature”. The timing pointed to the cause: setting up the ticketing system’s webhooks had overwritten the booking function’s signing secret.