Indian businesses that run collections and supplier payments through Razorpay and RazorpayX end up doing two reconciliations by hand: matching Razorpay settlements to customer invoices, and matching RazorpayX payout debits to Purchase Invoices and expense claims. ERPNext core has no native Razorpay or RazorpayX connector on the payables side — you can wire Razorpay as a website payment gateway for the portal, but there is no automated capture of vendor payouts, no UPI/IMPS/NEFT payout initiation from a Payment Entry, and no signed-webhook pipeline that turns a Razorpay event into a submitted Payment Entry against the right party. Finance teams bridge the gap with spreadsheets and the Razorpay dashboard, and the general ledger drifts out of sync with what actually cleared the bank.

ECOSIRE builds a proper Frappe app — a namespaced module with its own DocTypes — that closes both loops inside ERPNext. On the collections side we generate Razorpay Orders and Payment Links against Sales Invoices, support UPI, cards, and netbanking, and capture the payment.captured and payment_link.paid webhook events. On the payables side we integrate RazorpayX: a RazorpayX Payout DocType (with a Payout Batch parent for bulk runs) that reads bank details from Supplier and Employee records, validates the fund account, and fires the payout via the RazorpayX API. Every inbound webhook lands on a whitelisted frappe.whitelist(allow_guest=True) endpoint that verifies the X-Razorpay-Signature HMAC before doing anything, so no unauthenticated event can create ledger entries.

Technically, the reconciliation is driven by hooks.py doc events and server scripts. When a captured or paid event verifies, the app resolves the linked invoice, creates and submits a Payment Entry with the correct party, mode of payment, and bank clearance reference, and stamps the gateway transaction id back onto both documents for audit. RazorpayX payout status transitions (processing, processed, reversed, failed) update the payout DocType and post or reverse the corresponding Payment Entry. A scheduler event polls for pending/stuck transactions so a dropped webhook self-heals on the next tick. Role profiles and permission rules restrict payout initiation and approval to finance roles, client scripts add the pay/approve actions to the invoice and payout forms, and the whole thing is exposed over the standard Frappe REST API and whitelisted methods for any headless or portal flow you need.

Because this is build-to-order, we start from your actual chart of accounts, GST setup, supplier and employee master data, and approval policy — not a generic template. After a short scoping call we confirm exact scope and payout limits, build the app against Frappe/ERPNext v15 or v16, and hand you installable source plus a git repository. Typical delivery is one working week from confirmed scope. There is no instant download: this is a bespoke integration that we install, test on your staging site, and support after go-live.