Our client operates white-label ATMs in what the industry calls SURU — semi-urban and rural. Tier-4 and tier-5 towns, and villages. Their machines sit in most of India's 7,900 towns and within reach of a large share of its 6.64 lakh villages, serving around 45 lakh customers.
That footprint sets the engineering problem. An ATM in a metro branch has a technician nearby, a fixed line, and mains power. An ATM four hours from the nearest town has none of those. It still has to authorise a withdrawal in seconds, settle correctly, and never dispense money it has not accounted for.
Meanwhile the same customers are moving onto UPI. A business built on dispensing cash has to become one that also moves money digitally — without the cash business skipping a beat while it happens.
What makes this hard
Payments engineering is unusual in that almost none of the difficulty is in the happy path. A withdrawal that works is a few hundred milliseconds of message passing. The work is in everything else.
- The network is the unreliable part. Links to rural machines drop mid-transaction. The switch cannot know whether the customer received cash, and it has to resolve that correctly, every time, without a human.
- Nothing can be replayed naively. A retried debit that lands twice is somebody's money. Every interface has to be idempotent by construction, not by convention.
- The regulator sets the deadlines, not the backlog. Certification rounds, circulars and dispute-resolution timelines are fixed dates. Release planning works backwards from them.
- Reconciliation is the real system. Matching switch records against settlement files, cash positions and the core banking ledger — and explaining every break — is where correctness is actually proved.
A payments platform is judged on how it behaves when things fail, because that is the only part customers ever notice.
A payment is two conversations
The detail that shapes everything else: the scheme does not answer on the connection you called in on. You raise a request, you get an acknowledgement, and some time later the scheme calls your endpoint back with the actual outcome. Every verb is two independent exchanges in opposite directions.
That asymmetry is why the codebase pairs every verb, and why address validation and account-provider lookup sit alongside them as first-class modules rather than helper calls. The package structure is the protocol.
Certified against the scheme, not just tested internally
In retail payments the meaningful quality signal is not a test suite — it is passing the scheme operator's own certification. The IMPS stack went through review rounds across 19 distinct transaction flows.
Remittance
Person-to-person and person-to-account, in both remitter and beneficiary roles, including prepaid-instrument and credit-card variants.Dispute resolution
The paths that run when a transaction fails, on both sides of the transfer.Validation
Remitter and beneficiary validation ahead of value transfer.That the dispute flows account for nearly half the certified surface is the point worth noticing. It is a fair description of payments work generally: the exception handling is most of the system.
Four decisions that shaped the platform
Scheme switches time out and retry. Idempotency keys on every request mean a retry is provably safe rather than hopefully safe.
The platform was built to be sold on to other operators, not only to run one estate — so tenancy is in the data model rather than bolted on later.
Banking customers have data-residency positions that differ. The same build runs in a client's data centre or on cloud infrastructure.
Each sponsor bank's core banking, mobile and ATM switch differ. Adapters keep integration churn at the edge instead of in the transaction path.
Designed for headroom
The platform is engineered to 10 billion transactions a year — around 10 TPS average against a 300 TPS peak. Today's ATM and digital load runs at roughly 50 TPS, so the design carries substantial headroom by intent rather than by accident.
Security follows RBI guidelines and ISO 27001, with static analysis in the build pipeline and key material held in hardware security modules validated under FIPS 140-2.
Cardless cash withdrawal
The piece that ties the two halves together is ICCW — interoperable cardless cash withdrawal. A customer scans a QR code on the ATM screen, authorises in any UPI app, and takes cash without a card ever being issued or read.
It is a good illustration of why the estate and the digital stack belong on one platform. ICCW is a UPI transaction that terminates in an ISO 8583 dispense, reconciled through settlement. Building it needs the card world and the UPI world to be the same system, held by the same team.