Mess counter handbook

The counter keeps working when the internet does not.

How a student pays, how the counter decides who eats, and exactly what happens when the connection drops in the middle of lunch. Written for the mess office.

A meal, start to finish

Five steps. Only one of them needs the internet, and it is not the one at the counter.

01
The student opens their own link
Every student has a personal top-up page. It never expires, so it is worth bookmarking.
02
They pay once, for next week
They choose how many meals they want — ₹10 each, up to ₹50 for a full week — and pay by UPI or card.
03
The counter collects the week's credit
Before Monday's service it downloads everyone's balance for that week and keeps it in its own memory.
04
The student taps their ID card
Answered in well under a second, from that local copy — enrolled, has not eaten yet, has credit.
05
The record catches up with the office
Every tap is written to the counter's storage first, then sent onward when there is a connection.

The money rules

Enforced by the system, not by the person at the counter. Nobody has to remember them or apply them by hand.

Oncea week: A student decides how many meals they want and pays for them in one go. They cannot come back on Thursday and add another ₹20 — the page will not let them, and neither will the payment system behind it.
₹10a meal: Five serving days, Monday to Friday. ₹50 buys the full week of 5 meals; less buys fewer.
Mondayis when it starts: Money paid at any point from Monday to Sunday night buys the following Monday to Friday. Students can pay over the weekend and it still counts for the week ahead.
Expiresafter Friday: Unused credit does not roll into the next week and is not refunded. It is a weekly allowance, not a stored balance.
Mealsand nothing else: Credit cannot be withdrawn, converted to cash, or moved to another student. Paying on somebody else's link puts the credit on their card.
The officecan still correct things: Cash entries, adjustments and refunds are always available to staff. The one-payment rule applies to students paying online, never to the office fixing a mistake.

If the internet goes down

Lunch carries on. The counter was built to be offline and treats the network as a convenience, not a dependency. Everything it needs to decide whether a student eats is stored on the device itself.

What stops is the reporting, not the serving. Precisely what holds and what does not:

Function	Offline	What actually happens
Serving students	Holds	Decided entirely on the device. No network is involved in the decision.
Stopping second helpings	Holds	The record of who has eaten is kept on the counter and survives a power cut mid-service.
Deducting credit	Holds	The week's balances are held on the device and written to its storage as they are spent.
Recording every tap	Holds	Written to the counter's own storage first, every time, before anything is sent anywhere.
Enrolling a card	Late	Works immediately at the counter. The office sees it when the connection returns.
The dashboard	Late	Goes quiet. Nothing is lost — the counter holds the records and sends all of them when it reconnects.
New payments reaching the counter	Late	Cannot affect the week already running: money paid this week is always for next week.
Adding students to the roster	Waits	A student added at the office is not known at the counter until it reconnects.

One weekis the offline limit: The counter can serve a full week on a single download of credit. It needs a connection before the next week starts — not every day.
~85,000taps of headroom: Roughly six months of full service can queue up on the device before its storage becomes a concern.
15 minbetween check-ins: How often it syncs when the network is healthy, retrying every two minutes after a failure.

The weekly boundary is the one to watch. Each week’s credit is stamped with the week it belongs to, so a counter that reaches Monday without having connected knows its figures are out of date. It does not guess and it does not turn people away — it serves everyone and records every tap. Free meals are recoverable; a queue of students wrongly refused is not.

Questions the office gets asked

A student paid but the counter says they have no credit.: Almost always it is not Monday yet. Money paid this week buys next week, so credit paid for on Wednesday is not spendable until the following Monday. If it is the correct week and still missing, take their payment reference and check it in the dashboard — do not ask them to pay again, and the page will refuse a second payment anyway.
Can a student add more money later in the week?: No. One payment per student per week. They choose the number of meals when they pay and that is settled. This is enforced in the payment system itself, so it holds even if somebody opens the link twice or tries on two phones at once.
A student's card is not recognised.: Their card has not been linked to their name yet. The counter handles this in the queue: when an unknown card taps, the operator's phone offers to assign it — search by name or roll number, tap their entry, and the student taps again to be served. An unenrolled card is refused whatever else is configured, so it is the first thing to check.
Can somebody eat twice on one card?: No. The counter records who has eaten in the service currently open and refuses a second tap. That record lives on the device and survives a power cut, so an outage cannot be used to get around it. Starting a new service is the only thing that clears it, which is what keeps lunch and dinner separate.
What if the counter loses power mid-service?: It comes back to where it was. The open service, who has already eaten, everyone's remaining credit and every tap so far are written to storage as they happen. One thing needs attention on restart: the counter has no clock of its own and takes the time from the operator's phone when it connects — which happens as part of opening a service.
Does it have to be online every day?: No. It needs a connection once before each new week, to collect that week's credit. Within a week it can run entirely offline and still serve, deduct and record correctly. A daily connection is a comfortable margin rather than a requirement.
If it cannot check credit, does it refuse everyone?: The opposite — it serves everyone and records every tap. A counter that cannot verify credit should give away meals rather than turn away students who have paid, and the records are all there to reconcile afterwards.
Are card details stored anywhere in the college's systems?: No. Payments are handled entirely by Razorpay. Card and UPI details go to them and never pass through the mess system, the counter, or the college. What comes back is confirmation that a payment succeeded and how much it was for.
What does the counter know about a student?: Name, roll number, and which card is theirs — the same information already on the roster. No photographs, no contact details, no payment information. The card is only an identifier; nothing is stored on the card itself.
How do we know the numbers are right before charging anyone?: The counter has a watching mode. It downloads balances and works out what it would have charged for every tap, without refusing anyone or deducting anything. Run a service that way, compare it against the dashboard, and switch to charging once the two agree.

Before the first charged service

A card that has not been linked to a student is refused whatever else is set. Until enrolment is well ahead of the students turning up, a counter set to charge turns away everyone not yet enrolled — and at the counter that is indistinguishable from a fault.

Two conditions are worth meeting before switching from watching to charging: most of the students who eat are enrolled, and most of them have paid for the week about to start. Until both are true, watching mode serves everyone and still produces the full record of what would have been charged.

Students looking for their own top-up link should start at onetaplabs.com/topup. Payments are handled by Razorpay. Onetap Labs never sees card details.