Security and Data Protection for Restaurants

At a glance

A restaurant trusts its platform with card payments, bookings, guest contact details and its staff rota. This page sets out how TableSpark protects each of them, in plain words, and what you control yourself.

Card numbers never reach usStripe takes every card on its own checkout or reader, for your own Stripe account.

Your restaurant, walled offRow-level security keeps every restaurant’s records separate in the database.

HTTPS everywhereEvery page and site is served over HTTPS, with HSTS, and custom domains get managed SSL.

Two-step sign-inTurn on two-step verification and the database itself requires it for your account.

Every till change recordedAn append-only audit log keeps voids, discounts, refunds and price changes, with who, when and why.

Your guests, your recordsExport guests and leads to CSV at any time; guests can download or erase their own data.

Payments

Online and in-person payments run on Stripe, on the restaurant’s own connected Stripe account. Money for orders, booking deposits, no-show card guarantees and gift cards goes straight to that account, and payouts go to the restaurant’s bank on Stripe’s schedule.

Card details	Entered on Stripe’s secure checkout or tapped on a Stripe Terminal card reader. Card numbers never touch TableSpark’s servers or database.
What TableSpark keeps	The payment reference, the amount and the status, so every order, deposit and gift card can be matched to its payment and refunded from the dashboard.
Payment notifications	Stripe’s webhooks are accepted only with a valid Stripe signature, so a forged “paid” message is rejected.
Commission	0% TableSpark commission on bookings and orders. Stripe’s standard card-processing fees apply to online payments.

Hosting and connections

Delivery	The platform and every restaurant site are served through Cloudflare’s network, over HTTPS only.
Database and files	The database, sign-in and media storage run on Supabase, in Supabase’s EU (Ireland) region.
Browser protections	Restaurant pages send HTTP Strict Transport Security (with preload), a no-sniff content-type header, a strict referrer policy and frame protection, so another site cannot load your pages inside a frame. The booking and ordering widgets are the one deliberate exception: they are built to be embedded on your own website.
Custom domains	Connect your own domain on Growth and Full and TableSpark manages its SSL certificate and renewals.

Every restaurant kept separate

All restaurants share one platform, so separation is enforced in the database itself, not only in the app. Every table that holds restaurant data carries the restaurant it belongs to, and row-level security policies allow a signed-in person to read or change only the restaurants they are a member of, in the role they hold there.

Server functions that do more than a simple read check the caller’s membership and role before they act, and are closed to the public by default. Automated tests check those permissions on a real database before changes go live.

Signing in and accounts

Passwords	Handled by the sign-in provider (Supabase Auth) and stored only as secure hashes. Nobody at TableSpark can see your password.
Two-step verification	Optional, switched on by the account holder in Settings, then Security, with an authenticator app. Once it is on, the database itself refuses your account’s reads and writes unless the session has passed the second step.
Bot protection	Public forms that write data, including bookings, the waitlist, enquiries, orders, deposits, gift-card purchases and guest sign-up, are checked with Cloudflare Turnstile on the server, and public endpoints are rate-limited.
Leaving	Account owners can delete their account themselves from account settings.

Your team

Four roles: owner, admin, editor and staff. What each person sees and can change follows their role, and staff see their own shifts.
Only owners and admins can moderate reviews and connect the restaurant’s Google Business Profile.
An append-only audit log records every void, discount, reopened bill, refund and price change: who made it, when, and the reason given. Entries cannot be edited or deleted from the app.
No per-seat charges, so there is never a reason to share one login between staff.

Guest data

Guest records belong to the restaurant’s TableSpark account and are visible in its Inbox and guest list.

Export	Guests and leads export to CSV at any time, on every plan.
Guests’ own rights	From the restaurant’s Guest App, a guest can download a copy of what that restaurant holds about them, or erase it. Every request is recorded.
Retention	Order contact details are anonymised automatically after 24 months. An enquiry is deleted 24 months after the restaurant marks it done, and in any case 36 months after it was sent. Menu files uploaded for scanning are deleted within about 24 hours.
Marketing consent	Campaigns go only to guests who subscribed, each email carries an unsubscribe link, and consent is recorded with its date and source.
Member cards	The QR code on a guest’s member card is a signed token that names no personal details, works only at that restaurant and refreshes every five minutes.

Email

Account and guest emails are delivered through Resend. A restaurant can send its guest email from its own domain, once the domain’s sending records are verified, so confirmations come from the restaurant’s name rather than a stranger’s address. The privacy policy lists every provider we work with, what each one does and what it handles.

Report a security concern

Email hello@tablespark.uk with “Security” in the subject, and a person will read it. Include what you found, where, and the steps to reproduce it. Please do not access other people’s data or disrupt service while testing.

For a request about your own data, see the privacy policy. To see whether TableSpark is running right now, see the system status page.