This Part applies to the Onetap Midday Meal Mess system: the counter installed in an institution's mess hall, the mess section of the Onetap Dashboard, and the personal top-up page each student is given. Where it differs from Part A or Part B, this Part controls for that system.
D.1 What the system does
A student is placed on the institution's mess roster. Their existing college ID card is linked to their roster entry. Meals are paid for a week at a time, and the student taps that card at the counter to take a meal. The counter decides, from its own local copy of the roster and the week's balances, whether the student is enrolled, whether they have already eaten in the current service, and whether they have credit.
D.2 Roles
The Institution is the Data Fiduciary and Onetap is the Data Processor, as in section A.3.1. The Institution supplies the roster, sets the meal price, provides the meals, and decides which students pay for their own meals and which are exempt from paying.
D.3 Personal data processed
| Category | What it is |
|---|---|
| Roster entry | Name, roll number, class or hostel grouping, and whether the student is exempt from paying |
| Card identifier | The serial number the ID card already broadcasts, stored as an identifier only |
| Meal records | Which card tapped, at which service, at what time, and the outcome — served, already served, unknown card, blocked, or no credit |
| Payment records | Amount, the week bought, and the payment gateway's reference |
Nothing is written to the card. The card is read, never modified, and holds no balance, no name, and no meal history.
The system holds no photographs, no biometric data, no contact details, and no bank, card or UPI credentials. It records that a student ate, not what they ate.
D.4 Payments
Payments are processed by Razorpay Software Private Limited, a payment aggregator authorised by the Reserve Bank of India. Card numbers, UPI identifiers, and banking credentials are entered on Razorpay's own checkout and are never received, seen, or stored by Onetap or by the Institution. What returns to us is confirmation that a payment succeeded, its amount, and its reference.
D.5 The rules a student is agreeing to
These are stated on the payment page before payment and enforced by the system, not by the person at the counter.
- A meal costs the price set by the Institution. A full serving week is Monday to Friday.
- One payment per student per serving week. A student chooses the number of meals when they pay and cannot add to the same week afterwards.
- A student buying fewer meals than a full week names the days they are coming. Those days are recorded with the payment, the card is accepted only on them, and they cannot be changed afterwards. A payment for a full week covers every serving day, so no days are named. The days chosen are shown back to the student before payment and named again in the consent they tick.
- The deadline is Saturday midnight (IST). A payment made from Monday to Saturday buys the week that follows. A payment made on Sunday has missed that deadline and buys the week after it; it is not refused.
- Credit becomes spendable on the Monday of the week it was bought for.
- Unused credit expires at the end of that week's Friday. It does not carry over and, as set out in D.6, is not refunded.
- Credit can be spent only on meals at that institution's mess. It cannot be withdrawn, converted to cash, or transferred to another student.
- Where the Institution exempts a student from paying, a full week is credited automatically and that student is never asked to pay. Nothing is charged to the student and nothing is invoiced to the Institution for it.
D.6 Refunds
Unused credit is not refunded. Mess credit is a weekly meal allowance, priced and provided by the Institution, and the expiry in D.5.6 is disclosed on the payment page, in the consent a student ticks before paying, and on the receipt shown afterwards.
Money is returned in these cases:
- A payment that did not result in credit. If a payment succeeds at the gateway but no credit appears — for example a duplicate payment, or one that would exceed the weekly maximum — it is refunded in full to the original payment method.
- A payment made in error against the wrong student. Raise it with the mess office with the payment reference.
- Where the Institution directs it. The Institution can adjust or reverse credit from its dashboard, and does so as the provider of the meals.
A student who believes a payment has gone wrong should take their payment reference, shown on screen after paying, to the mess office. Refunds are made to the original payment method and typically settle within the gateway's standard period.
D.7 Who can see what
Staff accounts at an institution can see only that institution's students, meals, and payments. The counter holds a local copy of its own institution's roster and the current week's balances so it can work without a network; that copy contains the roster fields in D.3 and nothing else.
D.8 Offline operation
The counter is built to work without a network and treats one as a convenience. Meal records are written to the counter's own storage first and sent onward when a connection is available, so a record may reach the Institution's dashboard later than the meal it describes. No meal record is discarded because the network was unavailable. A counter that cannot verify credit serves the student and records the tap, rather than refusing someone who has paid.
D.9 Retention
As set out in the table in section A.9.
D.10 Contact
Questions about a payment, a card, or a meal record should go to the institution's mess office in the first instance, as the Institution is the Data Fiduciary. Onetap can be reached at support@onetaplabs.com, and the rights in section A.11 apply to data processed under this Part.