Privacy & data

Name, WhatsApp number, delivery building/unit (or table for dine-in), the GPS pin link if shared, any note, the items and the money. No payment credentials exist anywhere — payment happens physically at the door or table.

Never. There are no online payments in the system: customers pay cash or by card machine on delivery. No card form exists, so there is nothing to steal.

No. A returning customer's details are stored by their own browser on their own phone, per restaurant, and offered back to them there. The platform deliberately provides no way to type a phone number and retrieve a person — that would let anyone look up anyone.

Content with no long-term business need is blanked on a 120-day schedule: WhatsApp message bodies, delivery pins, customer notes — and visit analytics lose their IP addresses, full referrer addresses and page-by-page history on the same clock, keeping only anonymous totals. What who ordered and what they paid — the accounting truth — is retained. The privacy policy states this in plain language.

Yes — via the support contacts. Erasure anonymises the person across their orders and message history: financial records stay (they must, legally), but the name and number are gone from them. It covers the message archive too, not just the customer record.

No. Every row of data is tagged to one restaurant and every query is fenced to that restaurant at the database layer — isolation is structural, verified repeatedly by security review, not a setting someone could forget.

Owners and managers see order data in the panel, and your WhatsApp groups receive tickets containing it — keep those groups staff-only. Rider links carry only their one order and die after use or expiry.

No — the pass carries stamps and branding, not the customer's name or number, and the pass-update path is engineered so wallet infrastructure never receives your customer list.

The platform's stance: ordering from a restaurant establishes the relationship that marketing rides on, and every marketing send obeys caps, windows and failure-exclusions to keep it respectful. A customer who asks you to stop should be honoured — contact support for suppressing a number platform-wide.

First-party only — no third-party ad trackers, no cross-site profiles, nothing follows anyone to other websites, nothing is sold. The platform records its own visit measurement: pages viewed (page address only, never the codes a link may carry), the referring site, IP address, browser type and a visit count via a random first-party cookie. The identifying parts are erased automatically after 120 days, and the privacy policy states all of it in plain language.

Visit measurement exists platform-wide (pages viewed, where visitors came from, browser type, visit counts) and is read by the platform operator today; a visitor is linked to a customer record only when they actually place an order. There is no restaurant-facing analytics screen yet — when there is, it will appear in your panel and in these docs.

No. The measurement is a background signal sent after a page has already loaded — nothing in the ordering flow waits for it, and if it fails for any reason the page and the checkout carry on exactly as normal, by construction.

On managed cloud infrastructure with the application served from a Middle-East region for speed in the UAE. Access to production data is limited to the platform operator with audited access.

Sensitive actions: who changed WhatsApp group IDs, who exported customer data, operator support access, status overrides — the who/what/when of anything that matters in a dispute. It exists to protect you as much as the platform.

Hashed by the authentication provider — never in plain text, never visible to anyone including the platform team. Login attempts are throttled; captcha guards the doors.

From your own panel you can export monthly statements (PDF and Excel) and per-order invoices — every statement download is audit-logged because it is a month of your trading leaving the system. A customer-list export exists only as an operator action, also audit-logged; ask support if you genuinely need one.

When an expired trial's grace window passes, the account and its data are removed as documented in the trial terms — staff logins first, then the restaurant record. A subscribed restaurant's data is never auto-deleted.

Straight to the support email, marked security. It reaches the operator directly; the platform runs recurring internal security reviews and treats external reports with priority.

Deleted outright after three days — the whole row, not just its contents — and deleted immediately if that phone number does place an order. It is the shortest retention on the platform and the only place where purging means deletion rather than blanking, because it is the one table that can hold the identity of somebody who never bought anything.

It anonymises rather than deletes: orders survive with their money and invoice numbers intact while the name, phone, unit, map link and notes are stripped; the customer record is deleted; message bodies and recipients are blanked; queued marketing loses its content and recipient; and a group order's per-person breakdown keeps the amounts but loses the names.

No — erasure is run by the platform operator; email support with the mobile number the person ordered with. It is scoped to ONE restaurant on purpose (the same number at a different restaurant is a different relationship), and the audit record proves it happened without re-recording what was erased — a masked number and counts only.

Yes — a statement puts a whole month of your trading in one file, so every download records who took it, which month, which format and when. The same rule applies to customer exports on the operator's side.

The per-person breakdown — who ordered which items and what each share was — is removed after 120 days; the mode and pot total stay, because those are the money-shaped facts. The order's own subtotal and total are never touched.