The queue
Twenty minutes of break, and a good part of it spent counting change for a fifteen-rupee samosa.
Built for students. Designed for every merchant.
A student taps their school ID card at the counter, or their phone, or shows a code. It clears in about a second — and it still clears when the wifi is down, which at lunchtime it often is.
One balance, spendable at every counter the school approves.
What a cash canteen costs
Twenty minutes of break, and a good part of it spent counting change for a fifteen-rupee samosa.
Money sent from home does not always reach the counter. Nobody can say where it went, because nothing wrote it down.
An accountant counts a tin at the end of the day and hopes it matches what was sold. Usually it nearly does.
Four ways to pay
All four end at the same wallet and the same ledger. A school does not choose one — a student who forgot their card still eats.
01 — Card tap
The chip in the school ID card, held against the counter phone. No app, no phone, no PIN — holding the card at the reader is the proof, the way a contactless bank card works under a floor limit. Nothing new to issue or carry.
Fastest at a busy counter02 — Card scan
For a card whose chip will not read, or a phone without NFC. The printed code can be photographed from across a room, so this one asks for the student’s PIN before anything is charged.
PIN required03 — Phone to phone
An Android phone holds the wallet and taps the counter directly. The code it presents is fresh every time and worthless a minute later, so possessing it is already proof — no PIN needed. Or the counter shows a QR and the student scans it in their own app and confirms there.
Rotating code04 — Offline
The phone collects a handful of one-use codes while it has a connection and spends them later with none. The counter, which does have wifi, carries each to us. A PIN is asked for every time, because a code that waited a day is not proof on its own.
PIN requiredThe part nobody else does
Most wallets ask a server for permission at the moment of payment, so a dropped connection is a student who cannot eat. We move that question earlier: the phone collects what it needs in advance.
The wallet balance is checked when the code reaches us, so an offline tap cannot spend money that is not there. Android only — Apple does not let a third-party app emulate a card, so an iPhone student scans the counter’s QR instead.
Where the money comes from
An accountant records what they took against a receipt number and their own name. The school’s books gain a real double-entry line, the wallet is credited, and the amount joins what the school settles with us monthly. The same receipt entered twice credits once.
eSewa or Khalti, confirmed with the provider server-to-server before a rupee appears in the wallet — never on the strength of a browser redirect coming back.
Everything it does
Where this is going
Split by what is actually running today, what is next, and what is still an intention. Nothing below the first column is a promise with a date on it.
Listed as intentions, not commitments. None of it is switched on.
Who it is for
Taps and eats. Sees the balance and every purchase, and can stop the card the moment it goes missing.
Sends money once instead of coins every morning, sees where it went, and can block a lost card from their own phone.
Takes cash at the office as it always has, but with a receipt, a ledger entry and a monthly statement instead of a tin.
Where this actually is
We are taking a small number of schools alongside Radheshyam. If you run a canteen and count a tin at the end of the day, we would like to hear from you.
A real conversation, not a mailing list.