There's a version of this post that exists as a Reddit rant. Someone asks "what booking software works with Razorpay?" and gets a wall of replies suggesting Calendly, Cal.com, or Acuity — tools that support Stripe and PayPal and nothing else. The original poster clarifies they're in India and need Razorpay. The thread goes quiet.
I've watched this happen enough times that I want to write it up properly.
The actual problem
Scheduling and booking software is dominated by tools built for the US and European markets. Calendly, Acuity, Cal.com, HubSpot Meetings — all excellent products for their target markets. All built around the assumption that "payment processing" means Stripe or PayPal.
For professionals in India, this assumption creates a concrete UX problem. Your clients pay via UPI. Your bank account is in India. Razorpay is the standard infrastructure — instant INR settlements, UPI support, net banking, all the local payment methods that make transactions frictionless for Indian users.
When a tutor or coach in India sets up Calendly and tries to enable paid bookings, they hit Stripe. Their clients — who pay their electricity bill, their Netflix subscription, and their grocery deliveries via UPI — are now asked to enter international card details. Many don't complete it. The booking gets abandoned.
The workaround most people land on is decoupled payment: book via Calendly, then collect payment separately via a UPI link or bank transfer. This works but reintroduces the problems that booking software was supposed to solve — payment chasing, no confirmation-gating, no record of who has paid.
Why this gap exists
Razorpay launched in 2014 and is now the dominant payment gateway in India. But most scheduling tools are built by US-based teams, funded by US-based investors, for a market where Stripe is the obvious integration choice.
The India market isn't small — there are millions of independent tutors, coaches, consultants, and service professionals. But the TAM calculations in SF or NYC don't make Indian payment infrastructure the default priority. Stripe gets built first because it serves the investors' reference customers. Razorpay is a future consideration.
The result: Indian professionals end up using tools that technically work but create payment friction that costs them real bookings.
What native Razorpay integration actually means
There's a difference worth drawing out between "supports Razorpay via Zapier" and native Razorpay integration.
A Zapier or webhook integration might notify Razorpay of a booking, or create a payment link after the fact. That's not the same as Razorpay checkout appearing inline in the booking flow — where the slot is only confirmed after payment.captured fires.
For the use case that matters most — requiring payment as a condition of booking confirmation — you need Razorpay checkout embedded in the booking flow at the confirmation step. Anything less means the booking and the payment are still two separate events, and you're back to chasing.
Building for India vs adapting for India
There's a broader pattern here worth naming. A lot of Western SaaS tools "support India" by accepting Indian credit cards on their billing page. That's not the same as being built for Indian users.
Being built for Indian users means:
- Razorpay (not just Stripe) for payments, because that's what clients use
- INR denomination, not USD conversion
- SMS to +91 numbers without routing configuration
- Pricing that reflects purchasing power parity, or at minimum flat pricing that doesn't penalise growth
- Most tools tick none of these. The few that tick some are usually Indian-built products with smaller feature sets or consumer-facing tools (BookMyShow, etc.) that aren't aimed at independent professionals.
The gap in the scheduling/booking category specifically is real and still largely unaddressed.
Why this matters beyond the tooling
The no-show problem in service businesses is well understood. Require payment upfront and no-shows drop dramatically. This is established.
But if your booking tool doesn't support the payment method your clients actually use, requiring upfront payment creates friction that costs you bookings. You're trading one problem (no-shows) for another (abandoned checkouts).
The solution requires both: booking software that enforces payment at confirmation and supports Razorpay natively so the checkout doesn't lose Indian clients.
That combination is rarer than it should be. It's a solvable problem — Razorpay has excellent APIs, good documentation, and a straightforward integration — but it requires someone to prioritise Indian professionals as a first-class use case rather than an afterthought.
The tooling situation right now
If you're a developer building in this space, or advising someone who is: the Razorpay gap in scheduling software is real and not yet well-served. The professionals who need it are a large, underserved segment who are currently working around the limitation with decoupled payment flows — which is a worse experience for everyone.
If you're an Indian professional looking for a solution today: Onbookr currently has native Razorpay integration with booking-confirmation gating. It's what we built after running into this problem directly. The rest of the tools in the category — Calendly, Cal.com, Acuity — don't have it at the time of writing.
The market will catch up eventually. It usually does. But "eventually" isn't helpful when you're a tutor trying to stop losing sessions to no-shows today.
Thoughts? Have you found other tools that handle this well? Curious whether others have run into the same gap.
Top comments (0)