Privacy Policy

Version: 2.2.0 Effective from: the date this version was first published in your environment.

This Privacy Policy describes how Agrotis Catering Service Private Limited (“we”, “our”, “the Platform”) collects, uses, shares, retains, and protects your personal data when you use the MealMatrix mess-management platform — comprising our web admin panel, our customer mobile app, our counter / point-of-sale app, and our staff mobile app. We are the data fiduciary under the Digital Personal Data Protection Act, 2023 (“DPDP”) and the data controller under the EU General Data Protection Regulation (“GDPR”) where applicable, for personal data we collect through the Platform.

This Policy is not limited to people who hold an account. If you are a walk-in guest — you ordered at a counter without registering, and gave a name, and possibly a phone number, an email address or the name of your organisation, so that your order could be prepared and handed to you — then that information is your personal data, you are a Data Principal under the DPDP Act in exactly the same way a registered member is, and every right in section 7 is yours. Section 1 says what we collect from a walk-in guest, section 6 says how long we keep it, and section 7 says how to exercise your rights when you have no account to log in to.

The mess (canteen / food-service operator) you order from — whether you are registered with it or are a walk-in guest — is a separate data fiduciary for the operational decisions it makes using the Platform. Where its operational terms differ from this Privacy Policy, this Privacy Policy governs the Platform itself; their terms govern the meal-service relationship.

1. Personal data we collect

Identity & contact: name, email, phone number, postal address, profile photo, roll/ID number, branch / department.
Authentication: hashed password, login session cookies, OTP codes (transient).
Health-related preferences: dietary restrictions, allergen flags, diabetic indicator, free-form dietary notes — only if you choose to provide them.
Biometric / access-card data: a face or fingerprint template, or an RFID card UID, where the mess uses biometric or card-based meal pickup and you have given explicit biometric consent. The biometric template is an encrypted, reversible mathematical representation of your enrolment capture — it is not a one-way hash. It is stored under envelope (key-encryption-key / data-encryption-key) encryption and decrypted only transiently, in memory, at the moment a match is computed.
Order, wallet & transaction data: what you ordered, when, the wallet balance and top-ups, refunds, rebates, and the location at which a wallet transaction took place.
Payment metadata: payment-gateway order and payment IDs and amounts. We do not store your card number, UPI handle, CVV, or banking credentials — those are processed by the payment gateway directly.
Device & technical data: device model, app version, push-notification token (Firebase Cloud Messaging), IP address, user-agent string, and crash / stability diagnostics.
Geolocation: the location associated with a wallet top-up, transaction, or (where the mess uses geofenced attendance and you have consented) attendance event, where the device permits and the feature is in use.
Audit data: timestamps and IP/user-agent values associated with significant account events (registration, policy acceptance, login, profile changes).
Walk-in guest details (no account required): if you order at a counter as a guest, we record the name you give, and — where you supply them so we can reach you about the order — a phone number, an email address and the organisation you say you are visiting from, together with the order itself and the one-time pickup code used to hand it over. The name is also copied onto the kitchen ticket and the pickup token so counter staff can call the order. These contact fields are encrypted at rest.

2. How we use your data (purposes & lawful basis)

To provide the meal service: recording orders, charging your wallet, dispatching kitchen tickets, marking attendance, processing rebates and refunds — necessary for performance of the contract you have with the mess.
To authenticate and secure your account: hashed-password login, sessions, OTPs, fraud-throttling, and anti-money-laundering velocity checks — a legitimate use necessary to operate the Platform safely under DPDP §7, and to meet our legal obligations.
To send transactional notifications: wallet credits, order confirmations, password resets, security alerts — necessary for the contract.
To meet legal obligations: tax, accounting, and financial-record retention under the Income Tax Act §44AA and GST §36 of India, and payment-data localisation under the Reserve Bank of India's directions.
For optional analytics & diagnostics: aggregated feature-usage statistics and crash/stability diagnostics — only where you have given the corresponding consent, which you may withdraw at any time. We do not track you across other websites or apps, and we do not serve advertising.
For optional biometric meal pickup: only where you have given explicit, granular biometric consent (DPDP §6). Withdrawing biometric consent stops any further enrolment or matching of your template.

3. Encryption and security safeguards

We apply technical safeguards proportionate to the sensitivity of the data:

Email, phone number, and (where configured) other identity fields are encrypted at rest using AES-256-GCM with rotating per-row nonces; equality lookups use a separately-keyed HMAC-SHA256 blind index so the encryption key never has to be loaded for a search.
Passwords are stored only as one-way hashes; we cannot recover them and will never ask for them.
Biometric templates are stored under envelope encryption (a per-tenant key-encryption-key wrapping per-record data-encryption-keys) and are decrypted only transiently in memory when a match is computed. They are not irreversible one-way hashes; we therefore protect them with key management commensurate with sensitive personal data, and we decrypt only the templates of members who have an active biometric consent.
Web traffic is served only over TLS 1.2 or 1.3 with HSTS in production environments; the customer mobile app refuses cleartext HTTP at the OS network-security layer.
Payment-gateway webhooks are verified by HMAC signature before any state change; payment intents are deduplicated against a database unique constraint to prevent replay.
Authentication cookies are HttpOnly, Secure, and SameSite-restricted; sessions expire on a sliding window.

4. Who we share your data with (third-party processors)

We share the minimum personal data necessary with the processors listed below. We do not sell your personal data, and we do not share it with advertisers. The current, authoritative list — including each processor's purpose and processing jurisdiction — is published at our Sub-processors page.

Razorpay Software Private Limited (India) — payment processing (UPI / cards / netbanking). Receives your name, email, phone, and the transaction amount.
Cashfree Payments India Private Limited (India) — alternate payment gateway and payout rail. Receives member/order identifiers and transaction amounts.
Easebuzz Private Limited (India) — alternate payment gateway. Receives member/order identifiers and transaction amounts.
Gupshup Technology India Private Limited (India) — transactional SMS / WhatsApp delivery. Receives your phone number and the message body (OTPs, order/wallet notices).
Twilio Inc. (United States) — transactional SMS delivery fallback. Receives your phone number and message body.
Meta Platforms, Inc. — WhatsApp Business (United States) — WhatsApp message delivery. Receives your phone number and templated message content.
Google LLC — Firebase Cloud Messaging (United States) — push-notification delivery. Receives a device-installation token, platform, device model, and app version.
Google LLC — Firebase Analytics / Crashlytics (United States) — app stability and aggregate usage diagnostics, where you have consented. Receives device/app diagnostic data and a pseudonymous installation id.
Google LLC — Cloud Vision API (United States) — server-side validation of profile photos you upload, where enabled. The image is sent only at the moment of validation.
Grafana Labs, Inc. — Grafana Cloud (United States) — application performance monitoring and error diagnosis. Receives OpenTelemetry traces, metrics and application log records. From traces, direct identifiers (email, phone, PAN, Aadhaar, and secrets or tokens embedded in URLs) are redacted in-process before export. Log records are not put through that same redaction step — it belongs to our tracing pipeline — so they carry whatever the individual log statement was written to include; our engineering rules require those statements to record identifiers by reference rather than by value.
Anthropic, PBC (United States) — LLM-assisted features (anomaly explanations, natural-language reporting, forecast narratives). Receives de-identified operational summaries; your direct identifiers are not sent.
SMTP relay provider (India) — outgoing transactional email. Receives your email address and the message body.
CloudPe (India) — infrastructure hosting of our servers, database, blob storage, and disaster-recovery backups. We take bare instances and self-manage the operating system, patching, database hardening, backup execution and disaster recovery; the provider supplies the facilities, hardware, power and network. All stores, including payment-classified data and its disaster-recovery copies, are held in India.

5. Cross-border transfers and India data-residency

Our primary databases, blob storage, and disaster-recovery backups — and in particular all payment-classified data — are stored within India, consistent with the Reserve Bank of India's payment-data localisation directions and our DPDP localisation posture. Disaster-recovery copies of payment data are not transferred outside India.

Some processors above (Google / Firebase / Vision, Twilio, Meta, Anthropic, Grafana Labs) operate from servers outside India. By using the corresponding optional feature (push notifications, SMS fallback, WhatsApp, photo-validation, or an LLM-assisted feature) you provide your consent to the transfer of the limited data described in section 4 to those jurisdictions, on the basis that the processors are bound by their own published data-protection commitments. You may disable these features at any time; the Platform will continue to function. Withdrawing consent does not affect the lawfulness of processing carried out before withdrawal.

One transfer in that list is not consent-based and we state it plainly rather than folding it into the sentence above: application performance monitoring (Grafana Labs) is operational telemetry we rely on to keep the Platform available and to diagnose faults, so it rests on the legitimate uses recognised by DPDP section 7 and on our service contract, not on your consent, and it is not switchable off by you. What leaves India for it is traces and metrics with direct identifiers redacted in-process before export, together with application log records — not your account record.

5A. Sensitive personal data — health & biometrics (DPDP §6 / §9)

If you choose to record nutritional goals, dietary preferences, allergens, or to enrol a biometric identifier (face / fingerprint template, NFC card binding), this constitutes sensitive personal data. We collect it only with your explicit, granular consent gathered at the moment you opt in — never bundled with the general account consent. You may withdraw that specific consent at any time through your profile; biometric enrolment and matching stop immediately, the related rows are purged on a defined schedule (see section 6), and the data is excluded from any downstream analytics surfaces.

6. Retention

Account profile: for as long as your account is active, plus a short reconciliation window after deactivation.
Wallet, payment, order, refund & rebate records: retained for at least seven (7) years from the financial year of the transaction, in compliance with the Income Tax Act §44AA and GST §36 of India.
Authentication logs & audit trail: retained for security-investigation and legal-evidence purposes and then progressively reduced per a published schedule.
Push-notification tokens: deleted when you uninstall the app or disable notifications.
Nutritional goals, dietary & allergen preferences: retained while your account is active; purged on erasure within the SLA published on the Grievance page.
Biometric templates (face / fingerprint): deleted when you exercise your right to erasure or withdraw biometric consent. Templates are encrypted, reversible representations (not one-way hashes); superseded templates and erased-account tombstones are purged on a bounded schedule.
Photo-ID images uploaded for KYC: retained for the minimum period required by the operator's KYC obligation (typically 90 days post-verification) and then purged. You may request earlier deletion subject to the operator's KYC compliance position.
Cross-border processor logs: retained only as long as the processor's own published data-retention policy permits; we do not extend the window on our side.
Walk-in guest contact details: the name, phone number, email address and organisation you gave at the counter are kept for 90 days from the order, so the order can be prepared, handed over, receipted and reconciled. After that they are erased in place automatically — including the copies on the kitchen ticket and the pickup token — and the de-identified order remains only as a sales record. You do not have to ask for this; it happens on a schedule.

7. Your rights

Subject to the DPDP Act and applicable law, you have the right to:

Access a copy of the personal data we hold about you.
Correct personal data that is inaccurate or out of date.
Erase personal data we no longer need to retain. Where law (e.g. tax records) requires us to keep a row, we will anonymise the personal-data fields on that row instead of deleting it.
Withdraw consent at any time. Withdrawal does not affect the lawfulness of processing carried out before the withdrawal.
Lodge a grievance with our Grievance Officer (see section 10) and, if unresolved, escalate to the Data Protection Board of India.
Nominate another individual to exercise these rights on your behalf in the event of your death or incapacity (DPDP §14).

To exercise any of these rights, contact the Grievance Officer using the details in section 10. We will acknowledge your request within the SLA published on the Grievance page.

If you are a walk-in guest and have no account. These rights are yours too, and you do not need to register in order to use them. Contact the Grievance Officer (section 10) or use the rights-request form, and give us the phone number or the email address you handed over at the counter — that is what we search on, and it is the only thing that ties an anonymous counter order to you. Tell us the mess and the approximate date as well; it makes the match quicker. Two things we would rather say plainly than have you discover: if you gave only a name, we have no reliable way to identify your record and may not be able to act on the request; and a guest request is worked by a person rather than served automatically, so it takes the published SLA rather than being instant. If you do nothing at all, your contact details are erased automatically after 90 days (section 6).

8. Children and DPDP §9 age gate

Under the DPDP Act §9, the Platform does not knowingly process the personal data of a child — a person under the age of 18 years — without verifiable parental or guardian consent. What that means in practice depends on how your account was created, and we set out every case below rather than describing only the strictest one.

You registered yourself, through our website or our customer app: a date of birth is required. A registration with no date of birth, with a date in the future, or with one indicating you are under 18, is rejected before any personal data is stored, and you are directed to the mess operator's parental-consent pathway.
Your account was created for you, and a date of birth was supplied — this is now the case for a bulk import, whose template carries a date-of-birth column: the same check runs. Where your operator enforces the gate, an account whose supplied date of birth indicates you are under 18, or is in the future, is refused, and the refusal is recorded in our audit log against the operator who submitted it. Once we have asked the question, we do not create the account anyway.
Your account was created for you, and no date of birth was supplied — added individually by your mess operator, or provisioned automatically the first time you signed in through your institution's single sign-on. Neither of these two routes asks for a date of birth today, so there is nothing for the age check to read. The account is created, and the fact that the check could not run is recorded in our audit log against the operator or identity provider that created it. (If an operator does supply a date on the individual-add route, the check above applies to it — the refusal is not conditional on which route asked.) We are adding date-of-birth capture to these routes; until then, the operator or institution that enrols you is responsible for confirming that you are eligible.
Operators outside the scope of DPDP §9 — for example a corporate or non-India deployment — may be configured so that a missing or under-18 date of birth is recorded and audited rather than rejected. Rejection is the default and applies unless your operator has been configured otherwise.

We do not serve targeted advertising to any user and do not engage in behavioural monitoring. We do not process biometric data of children. If you believe a child has registered, or has been enrolled by an operator, without the required parental consent, contact the Grievance Officer immediately; on verification, we will erase the account and all associated personal data in accordance with the DPDP Act.

9. Cookies and similar technologies

We use only the cookies necessary to operate authentication and session management. We do not place advertising pixels or cross-site tracking cookies, and we do not use analytics that would identify you across other websites.

10. Grievance Officer

If you have any question, concern, or complaint about how we handle your personal data, contact the Grievance Officer:

Visit our Grievance page for the current officer's name, email, postal address, and the response timeline. The page also lists, where applicable, the location-specific officer for the mess you are registered with.

11. Changes to this Policy

We will post the new version on this page and update the version number and effective date. For material changes affecting your rights, we will request your explicit acceptance the next time you log in. Your continued use of the Platform after a non-material update constitutes notice of the new version.

12. How to contact us

Agrotis Catering Service Private Limited
921, Bharadi, Taluka Sillod, Dist. Chhatrapati Sambhajinagar
Email: agrotiscaterers@gmail.com
Web: https://mealmatrix.app