Multi-region ERPNext merchants hit a wall quickly with payments. ERPNext ships a generic Payment Gateway framework and a few first-party integrations, but PayU is not one of them — and PayU itself is really three different acquiring stacks (PayU India, PayU LATAM/EBANX-adjacent flows, and PayU EMEA) with distinct API hosts, credential formats, hashing schemes and supported instruments. Bolting one region's flow onto a Payment Request with a custom server script gets a demo working, but it breaks the moment you need UPI intent alongside saved cards, EMI tenures, netbanking bank lists, or a webhook that reconciles an asynchronous UPI collect request hours later. Reconciliation, refunds, idempotency and multi-currency settlement are exactly where the native path runs out of road.

We build a proper Frappe app (for example payu_erpnext) with its own module, not a pile of loose server scripts. It registers as a first-class ERPNext Payment Gateway so Payment Request, the web checkout, and Sales Invoice payment entries all route through it. A PayU Settings (Single) DocType holds per-region credentials (merchant key, salt/secret, client credentials) with the salt stored as a Password field, plus a sandbox/live toggle and a chosen instrument set. Region and instrument routing is data-driven through child tables, so one install can serve an India entity on UPI/netbanking/EMI and an EMEA entity on cards from the same codebase.

Technically, the checkout server flow is a whitelisted method (@frappe.whitelist()) that builds and signs the PayU request hash server-side, so the salt never reaches the browser, and returns either a hosted-checkout redirect or a Server SDK payload for an embedded flow. Return and webhook handlers are whitelisted, allow_guest endpoints that re-verify the response hash before trusting any status, then update the linked Payment Request/Payment Entry and create the payment against the invoice. hooks.py wires doc_events on Sales Invoice and Payment Request for state transitions, and scheduler_events run a reconciliation job that polls PayU for pending/async transactions (UPI collect, delayed netbanking) and closes them out — so a customer who completes payment after the browser closes still gets reconciled. Tokenization and recurring are modeled as their own DocTypes storing the PayU token reference (never raw PAN), enabling one-click and saved-card charges and subscription debits. Client Scripts drive the checkout UX on the web form, a dedicated Role Profile and permission rules gate the settings and transaction logs, and every request/response is written to an auditable log DocType. The whole thing targets Frappe/ERPNext v15 and v16 and is delivered against your bench, respecting your existing site_config.json and app structure.

Because this is build-to-order, nothing ships until we agree on scope. We start with a short scoping call to confirm your PayU regions and MID setup, the instruments you actually need, your ERPNext version, and how checkout should behave (hosted redirect vs. embedded, guest vs. logged-in). From there ECOSIRE builds the app against a staging copy of your site, runs UAT with real sandbox transactions, then installs on production with a rollback plan and hands over the git repository. Typical delivery is one working week from confirmed scope, followed by a post-go-live support window. No instant download, no shortcuts, no fabricated benchmarks — a maintained Frappe app built for your acquiring setup.