Guides, glossaries and calculators to help you scope, cost and run an ERPNext implementation — from GST and e-invoicing setup to module-by-module walkthroughs.
Quick definitions of key terms
Expert insights and updates
Simple step-by-step resources
Easy explanations through videos.
Complete IRN flow in ERPNext (2026)
ERPNext HRMS for India's Labour Codes
ERPNext for Indian hospitals (NABH, ABDM, DPDP)
DPDP Act 2023 Compliance in ERPNext
Collections that reconcile themselves. Most businesses that take online payments have the same quiet problem: money lands in the bank, the invoice stays open, and someone matches the two by hand a week later. The gateway is not the issue. The gap between the payment and the ledger is.
ERPNext supports several gateways natively through the Payments app, and payment requests can be raised against any invoice or order.
ERPNext supports Razorpay, PayU, Stripe, PayPal and Braintree natively through the Payments app, with others connectable by API. A payment request against an invoice generates a link the customer can pay through, and the successful payment creates a payment entry against that invoice automatically.
None of these are gateway failures. They are all failures of the join between the gateway and the ledger.
A customer pays through a generic link or a UPI handle with no reference, so the credit reaches the bank unattached. Someone then works backwards from the amount, which works until two customers pay the same figure on the same day.
The gateway deducts its fee before settling, so the amount received is less than the invoice. Booked as a short receipt or netted against sales, the true cost of collection is never visible and gateway pricing never gets renegotiated.
Several payments settle as one bank credit, days later. Matching that credit back to the individual invoices inside it is manual, and it is the reason the bank reconciliation always has a queue.
A customer who tried and failed, and one who never tried, both show as unpaid. Without status coming back from the gateway, collections chases the wrong people and misses the ones who need a fresh link.
The test is whether an invoice closes itself when the customer pays, and whether you can say what collection cost this month.
A payment request raised from an invoice, sales order or quotation generates a link carrying the reference, so every payment arrives already attached to something.
The link can be emailed or sent over WhatsApp, and the reference travels with it, which is what removes the matching problem at source.
A successful payment creates the payment entry against the correct invoice and closes it, without anyone opening the ledger.
Status flows back from the gateway, so pending, failed and successful are distinguishable rather than all showing as unpaid.
The fee deducted by the gateway posts to its own expense account rather than reducing the receipt, so the invoice settles in full and the cost of collection is visible.
Over a year this single configuration decision is what makes gateway pricing a negotiable number instead of an invisible one.
Where the gateway settles in batches, the payout is matched against the individual payments inside it, so the bank credit reconciles against many invoices in one action.
This is the difference between a reconciliation queue that clears daily and one that grows all month.
Refunds initiated at the gateway flow back as entries against the original payment, and chargebacks are recorded rather than appearing as an unexplained debit.
Handled properly, a refunded order reverses cleanly in both revenue and receivables instead of needing a manual journal.
Requests go out, status and settlement come back. Card and account details never touch ERPNext.
| Trigger or event | ERPNext record | Direction | Notes |
|---|---|---|---|
| Invoice or order | Payment Request + payment link | ERPNext → Gateway | Reference embedded so the payment arrives attached |
| Successful payment | Payment Entry against the invoice | Gateway → ERPNext | Webhook driven; invoice closes automatically |
| Failed or pending payment | Payment Request status | Gateway → ERPNext | Keeps collections chasing the right customers |
| Gateway fee | Expense account | Gateway → ERPNext | Posted separately, never netted against revenue |
| Settlement payout | Bank entry matched to many payments | Gateway → ERPNext | Batch matching clears the reconciliation queue |
| Refund | Entry against the original payment | Gateway → ERPNext | Reverses receivable and revenue cleanly |
| Chargeback | Recorded adjustment | Gateway → ERPNext | Visible rather than an unexplained bank debit |
| Recurring mandate | Subscription payment schedule | Either | Where the gateway supports mandates and you use them |
| Card or account details | Not stored | Never | Handled entirely by the gateway; ERPNext holds only a token reference |
Sandbox first, always. Payment integrations are the one place where testing in production is genuinely irresponsible.
Settlement cycle, fee structure by instrument, refund handling and supported currencies matter more than the integration itself. Where you already have a gateway contracted, this stage confirms what it actually does.
Your own gateway credentials are configured against the sandbox environment and a full cycle is run: request, success, failure, refund and settlement.
Which account receives the collection, which takes the gateway fee, and how settlement in transit is held between payment and bank credit. This is agreed with your finance team, not assumed.
Status callbacks are configured with signature verification, so ERPNext trusts only genuine notifications from the gateway and a spoofed callback cannot close an invoice.
Live with one customer segment or document type first, reconciled against the gateway dashboard for a full settlement cycle before it is opened up.
Timeline shown is indicative. Gateway onboarding and merchant approval sit with the provider and can take longer than the integration.
Payment integrations attract more assumptions than most, so these are worth reading properly.
Where a gateway cannot confirm payment status by webhook, automatic reconciliation is not achievable regardless of effort. Better to know that before choosing it.
Razorpay, PayU, Stripe, PayPal and Braintree are supported through the Payments app. Others can be connected by API provided they expose payment status callbacks, which is the requirement that actually determines whether automatic reconciliation is possible.
Yes, where the payment came through a payment request carrying the invoice reference. The gateway's success webhook creates the payment entry against that invoice and settles it. Payments made outside that flow still need matching, which is why the link matters.
The fee posts to its own expense account and the invoice settles at full value, rather than the fee being netted into a short receipt. That keeps receivables clean and makes your total cost of collection a figure you can look at monthly.
No. Card and account data is handled entirely by the gateway; ERPNext holds only a transaction reference or token. This is intentional — keeping card data out of your ERP removes an entire category of obligation and risk.
Yes. The payment request generates a link that can be delivered by email or through a WhatsApp Business message, which is a common pattern for collections. The reference travels with the link either way.
Status is also polled as a fallback, so a missed callback delays reconciliation rather than losing it. Anything still unmatched sits in a queue for review — the same exception-queue pattern used for statutory integrations, and for the same reason.
A short call about how customers pay you today and how long an invoice stays open after the money has arrived.
Razorpay, PayU, Stripe, PayPal and Braintree are trademarks of their respective owners. ERPNext and Frappe are trademarks of Frappe Technologies Pvt. Ltd. These names are used here only to identify the services described. Finstein is not affiliated with or endorsed by any of these providers, and merchant accounts are contracted directly in your own name.
