How to Build a Booking Form With Payment

It takes about 5 minutes to set this up, but trust us, it changes everything downstream for you. A booking form that doesn't take payment is just a reservation request. Someone fills it in, you hope they show up, and if they don't, you've lost that slot to nobody. A booking form with payment changes that math. Your customer's already committed before they arrive, and you've got a record of exactly what they paid and how, down to the rupee.

We'll cover the 2 real ways to collect payment on your booking form, how the price actually gets calculated so nobody can quietly knock ₹200 off it, and what you need to know about the at-venue cash and UPI option before you flip it on for your business.

The two payment paths

You've got 2 ways your customer can pay when they book with you, and honestly, they behave very differently once you look closely.

The first is online checkout through Razorpay. Your customer pays by card, UPI, netbanking, or wallet right at the moment of booking, and the slot confirms the instant the payment clears, usually within 2 to 3 seconds. This is about as close to "money in the bank" as your booking form gets. Nobody shows up to a slot they haven't paid for, and you don't need a person watching your dashboard at 11pm on a Tuesday for this to work.

The second is payment at the venue, in cash or UPI. The customer picks this option on the form and tells you which method they intend to use. Their booking still gets created, but it sits in "pending payment" status until your staff physically confirm, when the customer walks in, that the money actually showed up. Let's be blunt about this part: it's not automatic reconciliation. Nothing checks whether all ₹500, or all ₹5,000, of cash actually changed hands. It's a structured way to capture intent, basically a checklist for your front desk, and the real confirmation is a human marking it verified.

Most businesses running both options use online as the default and keep at-venue as the fallback, for customers who'd rather pay on arrival, or walk-in traffic that just wants to hand over cash.

How the price actually gets calculated

Whichever of the 2 paths a customer takes, here's the part that matters most: the price is never trusted from the browser. Not once.

When your customer makes their picks, say which package, which of 3 possible add-ons, how many seats, or which coupon code, their browser sends you that selection, not a total. The server looks up current prices, packages, add-ons, and any pricing rules in your database and calculates the number itself. That same calculation runs a second time, at the exact moment of charge, using one shared pricing engine, so the figure a customer sees on screen and the figure they're actually charged can't ever drift apart.

Here's why that matters in plain terms: a customer can't open their browser's dev tools at 2am on a Sunday and edit the page to pay ₹50 instead of ₹500. What's on screen is a preview. What gets charged is computed server-side, independently, every single time, 100% of the time, with zero exceptions.

Pricing rules stack too. A package price, 1 add-on, a 10% weekend surcharge, and a 5% coupon can all land on the same booking at once, and tax gets computed per line, so a package can carry 18% GST while an add-on carries a different rate if it needs to. The server runs that arithmetic once, the same way, every single time, so you're never reconciling 2 different totals later.

Setting up Razorpay checkout

Turning on online payment takes about 60 seconds. Go to your form's Booking Settings tab and enable the Razorpay method. Here's what happens next: your customer confirms their selection, a Razorpay order gets created for the server-calculated total (never whatever number the client sends), and Razorpay handles the card, UPI, or wallet transaction itself. When payment succeeds, your server verifies the signature on the response before marking the booking paid, and it also checks that the order genuinely belongs to that specific booking, not just any valid signature floating around your Razorpay account from some other order. If someone double-taps "Pay" twice in 1 second, or a confirmation and a webhook both land within the same second, both paths resolve to exactly 1 paid booking. You won't end up charging anyone twice or logging 2 records for 1 payment.

Setting up at-venue payment

This one takes under 2 minutes to turn on. Want to take cash or UPI in person too, say for walk-in customers a gym or salon sees on a busy Saturday? Flip on the at-venue option on that same settings tab. The customer selects it during booking, along with which method they plan to use, and their booking gets created in "pending payment" status instead of "confirmed."

From there, it's on your team. When your customer walks in, whoever's at your desk opens that booking in your dashboard and marks it verified once the money's actually in hand. Until someone does that, the booking just sits pending, even 3 days later. You get an audit trail of who verified what and when, which you'll genuinely appreciate at month-end on the 1st, but it only works if someone on your team is actually checking at the point of service. Skip that step, and the booking stays unpaid forever, whether or not the customer actually handed over cash.

QR walk-in: payment without a counter queue

No paper. No pens. Just a phone.

Is your business heavy on walk-in traffic rather than scheduled bookings? Pair your booking form with QR walk-in registration instead. A visitor scans a printed QR code at your entrance, fills out a 5-field registration form on their own phone in under 90 seconds, records their intended payment the same way a booking form does, and gets a confirmation pass immediately. Your staff then check people in and out at the door using that pass, instead of making every single visitor queue at a counter to fill out paperwork first. Underneath, the payment logic is identical to a booking form: an intended method gets captured, and someone verifies it separately.

A worked example: a gym charging for a trial class

Picture a gym selling a 6pm drop-in trial class for ₹299, with an optional ₹99 add-on for a protein shake afterward. They switch on both payment options.

One customer books online at 5:45pm, sees ₹398 total, pays by UPI through Razorpay, and their slot confirms within 3 seconds, no staff involved at all. A second customer walks in at 5:58pm without having pre-paid anything, books the same class on a tablet at the front desk, picks "pay at venue" plus "cash" as the intended method, and their booking shows as pending. When they hand the receptionist ₹398 in cash, she marks the booking verified, and it flips from pending straight to confirmed in 1 tap.

Both customers end up with a confirmed booking and the same ₹398 on record. The gym's dashboard shows which bookings came in online and which got verified by hand, so nothing slips through the cracks when the owner reconciles the till on the 1st of the month.

Try it

Start with the Bookings service page to see the full booking-and-payment feature set, including how slots, packages, and pricing rules all fit together. It takes under 10 minutes to set up your first payment-enabled booking form from scratch. If your business leans walk-in heavy, check out QR walk-in registration for the no-queue version of the same payment flow.

Ready to stop chasing no-shows and start taking paid bookings? Create your free SurveyKar account and set up your first booking form with payment in the next 10 minutes.