Four payment rails. Four different settlement finalities. Four different return code structures. Four different failure modes. If your UAT plan treats NEFT, RTGS, IMPS, and UPI as interchangeable — varying only in speed and limit — you have not tested your payments system. You have tested your assumption of what it does.
Why the Differences Are Not Cosmetic
NEFT — Deferred batch settlement, reversals are manual
NEFT settles in half-hourly batches during operating hours. A transaction initiated at 14:45 does not settle immediately — it enters the next batch. If the beneficiary account is invalid, the return arrives in the next cycle, not in real time. Your system must track batch membership, handle returns from RBI's NEFT clearing, and update status correctly when a return arrives hours after the original transaction. Most test plans test the successful NEFT. Almost none test the return flow — return reason codes, timeline, accounting reversal, and customer notification.
NEFT batch processing, outward remittance, return processing (invalid account, closed account), return reason codes, accounting reversal, and customer notification on return.
RTGS — Real-time gross settlement, minimum ₹2 lakh
RTGS is irrevocable once settled. There is no return in the NEFT sense — if funds reach the beneficiary bank and the account is found invalid, the beneficiary bank is responsible for returning funds through a separate RTGS transaction. Your system must handle the minimum amount threshold (₹2 lakh), the cut-off time enforcement (RTGS has strict operating hours), and the RTGS-specific rejection codes from RBI. The irrevocability is the critical test — your system must not allow a reversal of a settled RTGS transaction at the originating bank end.
Systems that allow a "reverse" button on settled RTGS transactions have a serious defect. RTGS settlement is final and irrevocable at the RBI level. Any reversal must go through a fresh RTGS credit to the original remitter — it cannot be a system-level reversal of the original entry.
IMPS — 24x7, instant, but return handling is different
IMPS operates 24x7 including holidays. Transactions are confirmed instantly. But IMPS failures — invalid MMID, account mismatch, beneficiary bank unavailable — return with specific NPCI error codes that are different from NEFT return codes. Your test plan needs IMPS-specific failure scenarios, not generic payment failure scenarios. The codes, the timelines, and the customer communication are all different.
UPI — P2P and P2M, collect requests, mandates
UPI introduced transaction patterns that have no equivalent in the older rails — collect requests (the beneficiary initiates), recurring mandates, and QR code payments. A system that handles UPI pay correctly but fails on UPI collect has a half-tested UPI implementation. Mandate creation, modification, revocation, and auto-debit execution are all distinct flows that require separate test scenarios.
UPI pay flow, UPI collect request, mandate creation and auto-debit, QR payment, UPI return and failure handling, NPCI error codes, transaction limit enforcement.
The Four-Column Test Plan
Structure your payments UAT with four explicit columns — one per rail. For each scenario, ask: does this apply to NEFT, RTGS, IMPS, UPI, or some combination? A failed payment scenario has four different expected outcomes depending on the rail. A return scenario has four different return mechanisms. Testing one and assuming the others are equivalent is the gap that produces production incidents.
India's payments infrastructure is among the most sophisticated in the world. NEFT, RTGS, IMPS, and UPI are not variations of the same thing. They are four different systems that happen to move money.