Indian ERPNext merchants routinely lose sales at the last step: a customer approves the Sales Order or opens the Sales Invoice, then has to pay through a separate Paytm dashboard, a shared UPI QR, or an offline bank transfer that someone reconciles by hand days later. ERPNext ships a generic Payment Gateway framework and integrations for the likes of Razorpay and Stripe, but there is no first-class Paytm connector for UPI, Paytm Wallet, or Paytm Postpaid. That gap means no in-context "Pay Now" on the invoice, no automatic Payment Entry against the right party and account, and no reliable settlement matching when Paytm's callback and the T+1 settlement report disagree.

We build a proper Frappe app (ecosire_paytm) that registers Paytm as a native ERPNext Payment Gateway so it appears in the standard Payment Gateway Account, Payment Request, and web-form checkout flows. Configuration lives in a dedicated Paytm Settings single DocType — merchant ID, key stored via Frappe's encrypted password field, website/industry type, and a staging/production toggle. The integration supports both models Paytm offers: the hosted Payment Page (checkout.js) for a hosted, PCI-lighter flow, and the Server-to-Server API when you need a fully embedded transaction. Every initiation writes a Paytm Transaction DocType linked back to the source Payment Request/Sales Invoice, so finance always has an audit trail keyed by Paytm's orderId and txnId.

Technically, payment initiation is exposed as whitelisted methods (@frappe.whitelist()) callable from the ERPNext desk, the portal, and the Frappe REST API. Redirect returns and asynchronous webhooks land on a public endpoint that verifies Paytm's checksum with the merchant key before trusting any status — no client-reported amount or status is ever accepted at face value. On a verified success, a hooks.py doc-event handler creates and submits the Payment Entry against the correct party, mode of payment, and bank/clearing account, then updates the linked invoice. Failed and pending transactions are handled by a scheduler event (scheduler_events) that polls Paytm's Transaction Status API to close the loop on dropped callbacks, and a daily reconciliation job that matches captured transactions to Paytm's settlement file. We also cover Paytm Postpaid (BNPL) as a tender, subscriptions and auto-debit mandates where your Paytm plan enables them, and refunds initiated from ERPNext that write back a reversing entry. A client script adds the in-form "Pay with Paytm" action, and access is governed through a dedicated role and permission set so only authorized users can trigger or refund payments.

Because this is build-to-order, nothing is shipped blind. We start with a short scoping call to confirm your Paytm product mix (UPI/wallet/cards/Postpaid/subscriptions), ERPNext version (v15 or v16), single vs. multi-company, and which documents should trigger payment. We then build against a staging bench, run UAT with your team using Paytm's sandbox credentials, and only cut over to production keys after sign-off — with a documented rollback. Typical delivery is 2–4 weeks from confirmed scope, and you receive the full source in a git repository you own, so you are never locked to us.