Security & data
Who handles the card, and where the money goes.
Before you connect your payment account, here is exactly who handles the card, where the money goes, and what we keep — in plain language.
This page is an explanation of how the system works. The terms of service and the privacy policy are the binding documents.
Payments
We never see a card number.
The processor's form takes the card, not ours
The card fields on the payment screen belong to your payment processor — Square or Stripe — and load in a frame that belongs to them. The number, expiry and CVV go from your guest's phone to the processor and come back to us as a one-time token. The processor is the PCI-compliant party; our servers only ever hold the token. Apple Pay and Google Pay work the same way.
Your guests pay you, not us
Each restaurant connects its own Square or Stripe account. Every payment is created against your account and your location, and settles into your bank on the processor's schedule. Money never passes through a Gilded Plate account, and processing fees are between you and the processor.
What we keep about a payment
The amount, the currency, the method, the time, and the processor's reference id for the charge. For cash: the amount tendered, the change given and which staff member took it. No card details of any kind.
Your payment connection is encrypted at rest
The tokens your processor gives us when you connect are stored encrypted with AES-256-GCM, under a key that lives only in the server's environment. They are refreshed automatically before they expire and can be revoked by disconnecting the account from Settings.
Your guests
Guests order anonymously.
No account, no profile, no email
Scanning a table's code starts a visit tied to that table, not to a person. We do not ask a guest who they are, and there is nothing to log in to.
Carts live for the visit, then go
A guest's cart is kept on our servers so it survives a dropped connection. It expires four hours after the last change, and a cart that reaches checkout is deleted the moment the order is placed. Only abandoned carts outlive a visit, and never past their expiry.
A visit ends when the table goes quiet
A table's visit closes after four hours without activity, so a code scanned at lunch does not resume someone else's order at dinner.
Your staff
Staff sign in; permissions are per restaurant.
Sign-in runs on Google Firebase Authentication
Staff passwords are held by Firebase, never by us. After sign-in the browser holds a server-issued session cookie that we can revoke; it is not a copy of the password or of any permission.
An account alone can do nothing
Anyone can create an account, and on its own it sees no restaurant. Access to yours comes only from you, when you add a person on your Staff page; the ability to set up a restaurant comes only from an invite from us. The public waitlist form creates neither.
Each person gets only what their job needs
Menu, orders, staff and settings are separate permissions granted per restaurant. A cook with access to the kitchen display cannot see your payment connection; a manager on one restaurant has nothing on another.
Your data
It is yours. Here is what happens to it.
Menu and order history belong to the restaurant
Items, prices, photos, customisation options, orders and payments are your business records. We use them to run the product for you and for nothing else.
Deletion is real deletion
When a restaurant closes, its menus, tables, orders, events and history are deleted outright once its closed and locked periods have passed, not archived, and cannot be recovered. That is a deliberate design decision: one deletion path and nothing lingering. It also means exporting first matters, which is why ending a plan points you to the export at every step.
Your data leaves with you
Settings › Export data takes a copy of everything your restaurant holds, at any time, with no need to ask us: every menu, order, payment and photograph, with a guide to every file. Ending your plan leaves you 60 days of full access to take it.
Who else touches it
A short list, each for one job.
The third parties the application sends data to. This list is kept in the code beside the integrations it describes, and whoever adds or removes a vendor updates it in the same change — a Stripe entry joins it with the Stripe integration.
- Square
- Card payments and the connection to your Square account. Sees card details and payment amounts; we see only the token and the charge id.
- Google Firebase
- Sign-in for everyone with an account — restaurant staff, and diners who create one by email, Google, Apple or phone number — and the live-update signal that tells the kitchen board and a diner's order page that something changed. The signal carries a timestamp and nothing else — no order contents.
- Neon
- The Postgres database where menus, orders, sessions and staff permissions are stored.
- Vercel
- Hosts the application and stores uploaded images (menu photos and logos).
- Resend
- Sends the emails Gilded Plate writes to you — receipts, sign-in links, invitations — and holds the address and the message to deliver it.
Last checked against the code on 2026-09-21.
Any question, answered by the person who built it.
Request early access, or bring your questions to the first conversation — we are glad to walk through any of this before you connect an account.
Request early access