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, via the restaurant's own Stripe account. Card details are entered on Stripe's hosted checkout page and never touch Dishlane. | Card payments (when the restaurant uses Stripe) |
| 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 or confirmation being sent. | Transactional email — order receipts, booking confirmations |
| Twilio | The customer phone number and the message text, sent through each 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 |
| Listmonk (self-hosted) | Opted-in marketing email lists. Listmonk runs on Dishlane infrastructure — it is self-hosted software, not a third-party network. | Marketing email to people who opted in |
| Anthropic Claude API | The customer's chat messages to the menu assistant plus the restaurant's menu and opening-hours context. Conversations are not stored on our 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 |
| Odoo POS | Menu item names and prices flow out to the POS; sales totals and the staff member name flow back in. | Point-of-sale integration (when the restaurant connects Odoo) |
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.