Bringing Razorpay to InsForge: Building a Production-Grade Payment Flow

Hemanth Reddy — Sun, 07 Jun 2026 17:00:32 +0000

If you're building a SaaS in India, Stripe isn't always an option. Razorpay is the standard. A few days ago I noticed that InsForge — a Y Combinator-backed open-source framework — had solid Stripe support but no Razorpay integration at all. For any developer targeting the Indian market, that's a hard blocker.
So I decided to fix it. Three pull requests, ~3,000 lines of code, one week.

Why Razorpay, and Where the Friction Actually Lives
Razorpay gives you the same core primitives as Stripe: hosted checkouts, subscription billing, webhook events. The API calls themselves are straightforward.
The friction isn't in the calls. It's in everything around them:

Environment setup — safely isolating test and live keys
Catalog management — syncing products and prices so your database matches the provider
Webhook plumbing — HMAC signature verification, retry safety, event deduplication
Fulfillment correctness — guaranteeing a user is never double-charged, even when requests drop and retry

My goal was to abstract that friction away so developers using InsForge could wire up a Razorpay flow just as easily as a Stripe one.

How I Broke It Down
PR #1382 — The Foundation
A payment provider integration isn't just a wrapper around API calls. It needs a provider abstraction layer that sits cleanly alongside Stripe without touching it, corrupting its data, or entangling its logic.
I built sync services for products, plans, customers, subscriptions, and payments. Provider-aware database migrations. A dashboard UI that adapts its credential management depending on which provider is active.
Scope expanded fast. What I thought would be a week of straightforward work turned out to be a careful architectural exercise in not breaking anything that already existed.

PR #1485 — Webhook Infrastructure
Payments don't happen in request/response cycles. A subscription renewal, a failed charge, a refund — all of it arrives asynchronously through webhooks. You have to build for that from the start or you're patching forever.
I built idempotent event handlers and a secure, native secret-management system inside InsForge for generating and validating webhook secrets locally.
Originally I designed this with automatic webhook endpoint registration via the Razorpay API. Then I actually read the API documentation carefully and found that programmatic webhook creation is restricted to Partner accounts. The whole approach had to go.
I rebuilt around guided manual setup with automated validation instead. The constraint turned out to force a cleaner design.

PR #1490 — Runtime Payment Flow
The last gap: developers couldn't actually create Razorpay orders or subscriptions through InsForge the way they could with Stripe. The sync infrastructure was there, but the runtime flow wasn't.
I built a RazorpayCheckoutService to handle checkout generation with strict idempotency guarantees:

PostgreSQL Advisory Locking — handles concurrent requests safely at the database level
Pre-flight Insertion with ON CONFLICT DO NOTHING — if a checkout request fails and retries, it returns the existing session rather than creating a duplicate charge
Row-Level Security Migrations — precise RLS policies to keep payment attempt records isolated per provider

The Part That Actually Taught Me Something
Writing the code was the easy part.
The harder part came during code review — with the maintainers and with InsForge's automated AI reviewers (cubic-dev-ai, greptile). These are strict. They caught edge cases I hadn't considered.
The one that stuck with me: if an order fails and the frontend sends an idempotent retry, should the server return a silent success or a 409 Conflict? I had it wrong. The correct behavior is 409 — so the client knows the original attempt failed and can surface that to the user, rather than silently proceeding as if everything worked.
The review questions I kept getting pushed on:

What happens when a webhook fires twice simultaneously?
Can two providers share a database without corrupting each other's data?
What does this look like under concurrent load in six months when nobody who built it is around?

I didn't have clean answers to all of these at first. Working through them was the real education.

The Integration Is Live
The Razorpay integration is merged into InsForge. If you're building a SaaS in India, you can now use InsForge's agentic workflow to wire up a production-ready Razorpay checkout — orders, subscriptions, webhooks, and all the reliability infrastructure underneath.
The core PRs if you want to dig into the implementation:

PR #1382 — Foundational Provider & Sync
PR #1485 — Webhook Infrastructure
PR #1490 — Runtime Payment Flow

Thanks to the InsForge maintainers for the patience and the detailed architecture discussions. That kind of review from people who've shipped real production systems is hard to come by.

DEV Community: Hemanth Reddy

Bringing Razorpay to InsForge: Building a Production-Grade Payment Flow