There's a category of code where "mostly works" is a disaster, and money is at the top of it. A button can be slightly off. A color can be a little wrong. A rupee cannot be a little wrong. If my math is off by even a small amount, multiplied across every booking, I'm either quietly stealing from hosts or quietly losing my own money — and both of those end the same way: nobody trusts the platform again.
So today I wired up real payments through Razorpay, and I went slow on purpose.
The flow itself follows the lesson I bled for yesterday: payment first, booking confirmed second. A guest goes to pay, Razorpay handles the actual transaction, and only once that payment is genuinely captured does the booking become real. No more phantom bookings. The horse pulls the cart now.
But the harder part isn't moving the money — it's the math of what the money even is. And here I leaned hard on the PHP version, because the money model is the one thing I'm carrying forward almost intact. We figured this out the expensive way already, on real customers. It goes like this:
There's the service price — what the host charges. On top of that, a small platform fee — currently 10 — which is how Book A Sloth makes money on each booking. And on that fee, 18% GST, because tax is not optional and pretending it is just creates a worse problem later. So the guest pays service price + platform fee + GST on the fee. Clean, predictable, and — crucially — honest at checkout. No surprise charges.
Then there's commission. On the free tier, the platform takes a small percentage of the service price; on paid plans, that drops to zero. (The business logic behind that is a whole post of its own, coming soon.) The point for today is: every booking has several numbers flying around — what the guest paid, what the host earns, the platform's cut, the tax, the actual fee Razorpay itself charges. Get the relationships between them wrong and the whole ledger rots.
Here's the decision I'm proudest of, and it also came from PHP scars: I snapshot every number onto the booking, permanently, the moment it's created. What the guest paid, the fee, the commission, the tax, the host's earning — all frozen onto that booking row forever. I do not recalculate them later.
Why does that matter so much? Because I, the admin, can change the platform fee tomorrow. I might raise it, lower it, run a promo. If I calculated a six-month-old booking's breakdown using today's fee, every historical number would shift under my feet, and my accounting would become fiction. A booking has to remember exactly what it charged on the day it happened, the way a paper receipt doesn't change just because prices went up. Snapshot it, freeze it, never touch it. Recalculating money after the fact is one of the great silent disasters, and I'm not walking into it.
One more honest detail: Razorpay charges its own fee on each transaction, and rather than estimate it, I record the actual fee from Razorpay's response. Real number, not a guess. Because when a host asks "why did I earn this exact amount," the answer should be a precise truth, not "roughly."
I tested it with a worked example — a 100 service — and watched every rupee land where it should: what the guest pays, what the host nets, what the platform keeps, what tax is owed, what Razorpay took. It balanced. Every paisa accounted for.
That's a quiet kind of win. No fireworks. Just numbers that add up exactly, every time, which in a payments system is the whole job.
Tomorrow: I spend two full days on a screen nobody will ever thank me for — the availability editor — and learn something about where products actually live.