Security

This page is written for a technical reader and lists what actually runs in production — no aspiration, no roadmap dressed up as the present. Where something does not exist, we say so.

Per-restaurant secrets — payment provider keys, messaging tokens — are encrypted at rest with AES-256-GCM. Key custody: the encryption key lives in the hosting platform’s environment configuration, with the operator’s copy held in a password manager.

Transport encryption is TLS, managed by Vercel for every site and dashboard the platform serves.

Every restaurant’s data is isolated from every other’s at the access-control layer of the application. This is not just policy: cross-tenant denial tests run in CI, so a change that let one restaurant read another’s data would fail the build.

Every inbound webhook is verified before the platform acts on it:

• Stripe — events verified with Stripe’s constructEvent signature check.
• Square — HMAC signature verified with a timing-safe comparison.
• PayPal — events verified via PayPal’s webhook verification API.
• Twilio — request validation on inbound SMS callbacks.
• Meta (WhatsApp) — hub challenge on subscribe plus HMAC verification on events.

Passwords are hashed with PBKDF2-SHA256. Staff and admin sessions use HTTP-only cookies with a 2-hour expiry and SameSite=Lax. Session cookies are never set for visitors or customers.

Public endpoints are rate-limited, backed by Postgres, with client IPs derived only from trusted headers so the limits cannot be spoofed away.

Card numbers never touch Dishlane. All card payments happen on the payment provider’s own hosted checkout pages (the SAQ-A posture) — we store amounts and payment references only.

Nightly encrypted database backups are written to Cloudflare R2 and retained for 14 days, with restore tooling maintained alongside them — a backup you cannot restore is not a backup.

Beyond tests, guardrail scripts run in CI and machine-enforce the platform’s riskiest invariants — for example, that money is only ever handled as server-computed integer pence and that no websocket transport sneaks into the codebase. These are hard build failures, not code-review suggestions.

We do not currently hold any formal security certification (no ISO 27001, no SOC 2). The measures on this page are what actually runs; we would rather show you the real list than rent a badge.

If you find a vulnerability, report it to join@quantumaiwebapps.com. We aim to acknowledge reports within 2 business days, and we will not pursue anyone who reports in good faith and does not access data beyond what is needed to demonstrate the issue. We do not currently run a bug bounty programme.