India compliance notes

This page explains how F Cartel is built with reference to Indian law, so a restaurant operator deploying it can have an informed conversation with their own advisor — it is not a legal opinion, a certification, or a substitute for review by a qualified lawyer or chartered accountant. Laws referenced here (the DPDP Act 2023, IT Rules, CGST Rules, and CCPA guidelines) are current as of this page’s last-updated date and may have changed since.

The restaurant that collects customer and staff personal data through F Cartel is the Data Fiduciary under the Digital Personal Data Protection Act, 2023 (DPDP Act) for that data — the same way a restaurant using a paper register or a spreadsheet would be. When F Cartel is run on the restaurant’s own server, that data never leaves the restaurant’s infrastructure.

On a restaurant-run server the entire stack (database, API, and web app) sits on hardware the restaurant controls, so data residency and cross-border transfer questions under the DPDP Act are largely avoided by construction — the data never leaves that server unless the restaurant chooses to move it.

The DPDP Act gives individuals (“Data Principals”) rights to access, correct, and erase their personal data, and requires Data Fiduciaries to collect only what’s needed for a stated purpose, retain it no longer than necessary, and provide a grievance-redressal channel. F Cartel’s data model and controls that a deploying restaurant can use to meet these:

• Customer records (name, phone, order/visit history, loyalty points) are editable and deletable by any staff member with the customers.manage permission — supporting correction and erasure requests.
• Only the data fields actually used by POS/CRM/loyalty features are collected — no speculative profile fields.
• Role-based access control restricts who on staff can view customer contact details and order history, supporting a purpose-limitation and least-privilege posture.
• Every table/order/session is scoped to the restaurant that created it — verified during a security audit that one restaurant's staff cannot query another restaurant's customer data, relevant if you run F Cartel for multiple outlets on shared infrastructure.

What F Cartel does not provide out of the box: a built-in consent-capture flow, an automated data-retention/deletion schedule, or a hosted grievance-officer contact form — these are organizational obligations the deploying restaurant (as Data Fiduciary) needs to put in place itself (e.g. a printed/posted privacy notice, a designated grievance contact, and a manual or scripted retention policy for old customer records).

The IT (Reasonable Security Practices and Procedures and Sensitive Personal Data or Information) Rules, 2011 expect a body corporate handling sensitive personal data (which includes financial information and, in a POS context, payment details) to implement documented, reasonable security controls. What’s implemented here, verified in a security audit rather than just claimed:

• Passwords hashed with bcrypt (cost factor 12), never stored or logged in plaintext.
• Session cookies are httpOnly and SameSite-restricted; JWT sessions verified against a live user/active-status check on every request, not just at login.
• Rate limiting on authentication endpoints to resist credential-stuffing/brute-force attempts.
• Strict tenant isolation and role-based authorization enforced server-side on every request — the frontend is never trusted as an authorization boundary.
• All money calculations (prices, tax, discounts, totals) are computed server-side, never trusted from client input, with race-condition-safe checkout and refund handling.
• Uploaded files are validated against their actual file-signature bytes, not just a client-declared filename or MIME type, and stored under randomized, non-executable filenames.
• No hardcoded secrets in source; the backend refuses to start with a placeholder or short JWT signing secret.

Transport encryption (HTTPS/TLS) for any deployment reachable beyond a trusted LAN is the deploying operator’s responsibility — typically via a reverse proxy (Caddy, nginx, or a tunnel provider) in front of the app. A LAN-only deployment behind a restaurant’s own router is not directly exposed to the public internet by default.

Receipts generated by F Cartel display the branch’s GSTIN (when configured in Settings), an itemized CGST/SGST breakup, and a per-order invoice/order number. Whether your specific invoice numbering and layout fully satisfies Rule 46 of the CGST Rules, 2017 for your registration and turnover bracket (e.g. sequential numbering per financial year, HSN/SAC code requirements at your turnover level) is something to confirm with your chartered accountant before relying on F Cartel receipts as your sole tax-invoice record — this software generates a receipt in the right shape, it does not itself certify GST compliance for your specific registration.

The Central Consumer Protection Authority’s 2023 guidelines on misleading advertisements and dark patterns explicitly name fabricated urgency, fake activity counters, and false social proof as prohibited practices. This site’s download counter is a real, server-side count of actual link click-throughs, starting from zero — never pre-seeded with an invented number. If you build on this codebase, we’d ask you to keep that practice rather than quietly seed it later.

For questions about this software’s architecture or security posture, contact F Cartel support. For questions about your own restaurant’s legal obligations as a Data Fiduciary or GST-registered business, please consult a qualified lawyer or chartered accountant — this page cannot answer those for your specific situation.