Indian businesses running ERPNext usually end up straddling two systems: sales and purchases live in ERPNext, but the actual money movement happens in the Razorpay dashboard. Someone shares a payment link over WhatsApp, a customer pays, and then a person manually finds the matching Sales Invoice and records a Payment Entry — often days later, often with the wrong reference. On the payout side it is worse: vendor bank details are copy-pasted into RazorpayX, a bulk transfer is fired off, and reconciling those debits back to Purchase Invoices is a month-end spreadsheet exercise. ERPNext core has no native Razorpay collection gateway and no RazorpayX payout capability at all, so the gap is bridged by human effort and hope.

We build a proper Frappe app (ecosire_razorpay) installed into your bench that closes that gap end to end. On the collections side, whitelisted server methods call the Razorpay Orders and Payment Links APIs so a Sales Invoice or Payment Request can generate a checkout or a shareable link without leaving ERPNext. On the disbursement side, new DocTypes such as RazorpayX Payout and RazorpayX Payout Batch model contact/fund-account creation and vendor transfers against your Purchase Invoices and Payment Entries, with maker-checker workflow states so a payout is authorized before it is queued. Everything is driven by real Razorpay/RazorpayX API calls under an encrypted key/secret stored in a Settings DocType, never hardcoded.

Status never depends on polling a dashboard. We register a signed Razorpay webhook endpoint (a whitelisted method verifying the X-Razorpay-Signature HMAC) that receives payment.captured, payment.failed, payout.processed, payout.reversed, refund.processed, and settlement events. hooks.py doc events and a handler layer then post the accounting reality automatically: a captured payment creates and submits a Payment Entry reconciled against the correct invoice; a processed payout marks the vendor Payment Entry as cleared; a refund or reversal books the offsetting entry. A scheduler event reconciles Razorpay Settlement reports against your bank Journal Entries and flags mismatches, and idempotency keys plus event de-duplication guarantee a retried webhook never double-posts.

Because this is licensed and access-controlled, we add role profiles (for example a Payout Approver role), permission rules on the payout DocTypes, and client scripts that surface pay/refund/payout actions right on the Sales Invoice and Purchase Invoice forms. Everything is exposed through the standard Frappe REST API and whitelisted methods, so your other systems can trigger collections or query payout status programmatically.

Delivery is build-to-order: nothing ships until we agree the scope on a short call. We confirm which flows you need (collections only, payouts only, or both), your GST/TDS and reconciliation rules, and your Frappe/ERPNext version (v15 or v16), then build against a staging copy of your instance. You get the installable app source, UAT on staging with a rollback plan, and a post-go-live support window. Typical delivery is one working week from confirmed scope — no instant download, because we are building it for your instance, not selling a shelf plugin.