Building a parking or short-stay booking platform: payments, refunds and double-booking

A booking platform looks like an online store with a calendar. It is not. A store sells a product that sits on a shelf until somebody buys it. A booking platform sells time — two hours in a driveway, three nights in a room — and time can be sold twice, refunded in part, disputed after it has been used, and paid out to a host before anyone notices something went wrong.

We are building Parkc, a peer-to-peer marketplace for parking by the hour and spare rooms by the night. It is in development and not yet open to the public. These are the problems that took the most care, and how we solved them — useful whether you build with us or with anyone else.

The three-way money problem

Every booking involves three parties: the guest pays, the platform keeps a commission, and the host is owed the rest — later. Between payment and payout, any of these can happen: the guest cancels, the host cancels, the payment confirmation arrives late, a dispute is raised, or a refund is attempted twice. For every booking, the system has to know how much was paid, how much was refunded, how much the host is owed, and whether it has been paid out.

Double-booking: why "check, then save" is not enough

The obvious approach: when a guest books, check that no other booking overlaps, and if none does, save the new one. It fails under real traffic. Two guests pressing "Book" in the same second both pass the check before either booking is saved, and the platform confirms two bookings for one space. The two drivers find out in the same driveway.

The fix is to make overlap impossible where the data lives. In Parkc, the database itself refuses any two active bookings for the same space whose time ranges overlap — a PostgreSQL exclusion constraint on the space and the booking's time range. Cancelled and no-show bookings are excluded, so they release the slot. The application still checks first, to show a friendly message, but the guarantee no longer depends on the application winning a race.

Two details matter:

• Use half-open time ranges. A booking from 10:00 to 12:00 and another from 12:00 to 14:00 must not conflict. Ranges that include their end point make back-to-back bookings impossible.
• Model capacity. A car park with 200 bays is not one space, it is 200 that can each be booked. Parkc applies the overlap rule per bay, so a 200-bay listing is 200 non-overlapping calendars rather than one.

Holds and late payments

When a guest starts checkout, the slot is held so nobody else takes it while they pay. If they never pay, the hold must lapse and the slot return to sale. The trap is a payment that arrives after the hold has lapsed — a slow bank, a delayed confirmation.

Parkc records who called a booking off: the guest, the property, an expired hold, or a full refund. That is what lets a late payment be handled correctly. A hold that merely lapsed can be revived if the space is still free; a booking the guest or the host deliberately cancelled must never be brought back to life by a late payment.

Refunds: write the policy as numbers

"Free cancellation up to 24 hours before" is a sentence. Software needs numbers. Parkc stores a cancellation policy on each listing:

Then record refunds as amounts, not as a status. A status of "partially refunded" says nothing about how much: two partial refunds of ₹600 against a ₹1,000 booking would each look valid on their own. Parkc records the amount refunded against each payment, so the total refunded can never exceed what was paid.

Payouts: exactly once

Hosts are paid after a booking completes, usually by a scheduled job that finds completed bookings without a payout. Run that job twice at once — a second server, a deployment at the wrong moment — and both runs see the same unpaid booking and pay the host twice. Parkc's database allows only one payout per booking, so a second attempt fails instead of paying.

Payouts also need a brake: while a dispute about a booking is open, its payout is held.

Disputes

Something will go wrong eventually: the space was blocked, the guest could not get in, the listing was not as described, the guest never turned up, or overstayed. Without a dispute process, whoever shouts loudest wins and the payout goes out regardless. In Parkc either side can raise a dispute with a reason; there is one open dispute per booking; the resolution records whether money was returned and how much; and the host's payout waits until it is settled.

Payment confirmations you can trust

Payment gateways tell your server that a payment succeeded by calling a webhook. Anyone can send a request to that address, so every webhook must be verified — Razorpay signs each one, and Parkc rejects any without a valid signature. Webhooks can also arrive twice, out of order or late, so each event should be handled idempotently, logged as received, and reconciled against the gateway's own records.

Other decisions to make before building

• Instant booking or host approval? Instant converts better; approval suits rooms more than parking.
• Hourly, daily, monthly and seasonal rates — and which rule wins when several apply.
• How guests get in: access instructions released only to someone holding a booking.
• Moderation: new listings reviewed before they appear.
• Map-first search for parking; date-first search for stays.
• Receipts and invoices for guests, and statements for hosts.
• What happens on a no-show, and whether the host is still paid.

What it costs to build

A focused booking marketplace — listings, map search, time-window booking, payments, cancellation policy, payouts and an admin — typically costs ₹9,00,000 to ₹20,00,000 ($13,000 to $28,000) and takes eight to fourteen weeks, more with native apps. There is a fuller breakdown in how much it costs to build a marketplace app. Our marketplace builds start from ₹6,00,000 / $8,500 for simpler marketplaces without bookings.

Whoever builds it, start with one city and one kind of space, and spend your testing time on the edges — simultaneous bookings, late payments, partial refunds, disputes — rather than on the happy path, which almost always works.

Talk it through

Planning a booking or rental platform? Send us the idea on WhatsApp or at krishan.joshi@corestacktechnology.com. We will tell you which of these problems apply to you, and send a free design of your booking flow within 48 hours.

Frequently asked questions