What this page is
This page describes, factually, how Quantum AI WebApps Digital LLC ("Dishlane") processes personal data on behalf of the restaurants that use the platform. It is written to do the job of a data processing addendum under UK GDPR while counsel completes the final contractual text; the draft banner above is doing real work here.
The roles, described factually
Each restaurant decides what customer data it collects through its own website: which modules are switched on, what its customers are asked for, and how those customer relationships are used. That is a controller-like role.
Dishlane stores and processes that data to run the platform on the restaurant’s behalf and under its instructions: a processor-like role.
Our legal counsel is confirming the formal categorisation of these roles; this page describes what factually happens rather than pre-empting that wording.
Scope and nature of processing
The categories of data subjects (restaurant customers and staff), the categories of personal data (order, booking, loyalty, gift-card, catering, messaging and account data), and the purposes of processing are exactly the flow-by-flow inventory published in the Privacy Policy at /legal/privacy; this page deliberately does not maintain a second, driftable copy.
Processing lasts for as long as the restaurant uses the platform, subject to the retention periods stated in the Privacy Policy.
Sub-processors
The complete list of sub-processors is the same table the Privacy Policy publishes, one source of truth, shown here in full: what each third party receives and why. There are no others.
| Who | What they receive | Why |
|---|---|---|
| Stripe | Order amounts, currency and payment references. Card details are entered on Stripe's own hosted checkout page and never touch Dishlane. A restaurant that onboards its own Stripe account (Stripe Connect) routes its charges and refunds through that account instead of the platform's; Dishlane still never holds a card number either way. | Card payments (when the restaurant uses Stripe, the default provider), and Stripe Connect for a restaurant that onboards its own account |
| Square | Order amounts, currency and payment references, via the restaurant's own Square account. Card details are entered on Square's hosted checkout page and never touch Dishlane. | Card payments (when the restaurant uses Square) |
| PayPal | Order amounts, currency and payment references, via the restaurant's own PayPal account. Payment credentials are entered on PayPal's hosted pages and never touch Dishlane. | Payments (when the restaurant uses PayPal) |
| Postmark | The recipient email address and the contents of the receipt, confirmation or platform email being sent. | Transactional email: order receipts, booking confirmations, platform notices, and any restaurant that has not configured its own provider below |
| Resend | The recipient email address and the contents of the email being sent. | Transactional email, when a restaurant configures its own Resend account instead of the platform's Postmark default |
| Twilio | The customer phone number and the message text, sent through the restaurant's own Twilio account (not a shared Dishlane account). | SMS notifications |
| Meta (WhatsApp Cloud API) | The customer phone number and the parameters of the approved message template. | WhatsApp notifications |
| Anthropic | The customer's chat messages to the menu assistant plus the restaurant's menu and opening-hours context. Conversations are not stored on Dishlane's servers; only usage counters are kept. | The AI menu assistant |
| Apple Wallet | Pass contents: loyalty points, name and phone, or a gift-card code and balance. | Wallet passes the customer chooses to add |
| Google Wallet | Pass contents: loyalty points, name and phone, or a gift-card code and balance. | Wallet passes the customer chooses to add |
| Sentry | Application error reports: stack traces, the request path, and tags. Scrubbed of PII (`lib/observability/scrub.ts`) before it leaves the process, so names, emails, phone numbers and payment fields are stripped, not merely masked in the UI. | Error monitoring |
| Cloudflare R2 | An encrypted nightly database backup (14-day retention) and a mirror of uploaded media, for disaster recovery only. | Off-site backups |
| OpenStreetMap tile provider | The rough delivery area being viewed (map tile coordinates), never the customer’s name, address or order contents. | The live delivery map on the tracking page |
| postcodes.io | A UK postcode, to resolve its approximate coordinates for the delivery map and ETA. | Free, keyless UK postcode geocoding (ONS open data) |
| Listmonk (self-hosted, optional) | Opted-in marketing email lists. | Marketing email, ONLY when the platform operator sets LISTMONK_URL. Every restaurant's marketing sends otherwise go through this platform's own native engine and the email providers already listed above, and Listmonk has never been deployed in production (AUDIT-ENTERPRISE-READINESS-2026-09-15.md §7) |
| Routing provider (ROUTING_URL) | The driver's live coordinates and the customer's delivery address, while an order is out for delivery, to compute a route and an estimated arrival. | Routed delivery estimates, ONLY when the platform operator sets ROUTING_URL. Unset today, so nothing is sent. |
Changes to sub-processors
If we add or replace a sub-processor, this page (and the Privacy Policy table it shares) is updated first, and the "Last updated" date changes. Restaurants that object to a new sub-processor can raise it with us and, ultimately, leave; there is no lock-in.
Security measures
The technical measures actually running today, stated without embellishment:
- Per-restaurant secrets (payment keys, messaging tokens) encrypted at rest with AES-256-GCM.
- Strict per-tenant data isolation at the access-control layer: every restaurant’s data is walled off from every other’s.
- All payment and messaging webhooks are signature-verified before we act on them.
- Passwords hashed with PBKDF2-SHA256; card numbers never stored.
- Rate limiting on public endpoints.
- Nightly encrypted database backups retained for 14 days.
Assistance with data subject requests and erasure
We assist restaurants with access, correction and erasure requests from their customers. For erasure, platform operators run a purpose-built tool that anonymises orders (keeping the money records per statutory bookkeeping retention), deletes loyalty profiles, unsubscribes from all marketing, deletes review-request tokens, and anonymises bookings and catering enquiries.
Two honest gaps in that tool today, stated here exactly as in the Privacy Policy: gift card purchaser and recipient details, and wallet passes, are not yet covered by the automated tool; we handle those manually on request.
Where data is processed
The application runs on Vercel, the database on Railway, and media plus encrypted backups in Cloudflare R2 (bucket region: Western Europe). We do not currently publish the specific compute regions, so we will not claim more precision than we have; the definitive region list is available on request.
International transfers
Our infrastructure providers and sub-processors may process data in regions covered by UK adequacy decisions or equivalent safeguards. Counsel is finalising the standard-contractual-clauses wording for any transfer that needs it; until that text is final we state the practice rather than paste boilerplate we have not verified.
Contact
Data processing questions, sub-processor objections, or requests for the region list: join@quantumaiwebapps.com.