Online fee collection sounds simple until a school actually tries to set it up — and then two questions come up almost immediately: whose payment gateway account should the money go through, and what happens if a payment fails halfway. Both have concrete, correct answers.
Why each school needs its own Razorpay account
It's tempting for an ERP vendor to run every school's payments through one central Razorpay account and settle the funds out afterward. It's simpler to build. It's also a regulatory problem.
When a platform pools payments from many separate merchants (schools, in this case) through one account and then transfers the money onward, that pattern falls under the Reserve Bank of India's Payment Aggregator regulations — a licensing category with its own capital, compliance, and reporting requirements. A software vendor is not automatically a licensed payment aggregator just because it built the fee-payment screen.
The correct model: each school connects its own Razorpay account, with its own KYC and settlement. The ERP platform stores that school's API keys (encrypted) and initiates payments on the school's behalf, but the money settles directly into the school's own account — never pooled through the vendor's.
Beyond the regulatory reason, this also means schools aren't waiting on a third party to release their own fee collections, and there's no dependency on the vendor's financial stability to get paid.
What this looks like in practice
- The school signs up for Razorpay directly and completes its own KYC.
- The school's API Key ID and Key Secret are entered once into the ERP's settings and encrypted at rest — the plaintext key should never be visible again after saving, only re-enterable.
- A webhook, verified with an HMAC signature, confirms each payment back to the ERP so the fee ledger updates automatically without manual reconciliation.
- A receipt is generated the moment payment is confirmed — not manually, and not based on a running count that could collide if two payments land at the same second.
A note on receipt numbering
A surprising number of fee systems generate receipt numbers by counting existing receipts and adding one — which works fine until two parents pay within the same second and both get assigned the same receipt number. The more robust approach ties the receipt number to the payment record's own database ID, which is unique by construction, rather than a count that can race.
Handling failed and pending payments
Online payments fail for reasons that have nothing to do with the school or the ERP — a declined card, a timeout, a closed banking app mid-transaction. A properly built system should:
- Never mark a fee as paid until the payment gateway explicitly confirms success via a verified webhook — not just because the browser redirected back to a "success" page, which can be spoofed or interrupted.
- Keep a clear "pending" state for payments that were initiated but not yet confirmed, so parents and accounts staff aren't left guessing.
- Log the failure reason where the gateway provides one, so accounts teams aren't fielding "I paid but it's not showing" calls with no information to act on.
Fee collection is the one module where a bug doesn't just look bad — it costs a school real money or causes a real parent dispute. It's worth asking any ERP vendor directly how they handle each of the points above before you commit.
See Fee Collection Set Up on Your Own Razorpay Account
We'll walk through the exact setup during your demo — no generic slides.
🚀 Book a Free Demo