Who can do what — and what happened when they did
RestioX ships the controls a restaurant group actually needs: staff roles built per action rather than per job title, a manager PIN standing in front of the money, records that stay branch-scoped whether or not a query remembered to filter, and an audit log that names the person, the action and the minute.
29
Automated tests whose only job is to reach another restaurant’s data and fail
0
Card numbers held in RestioX — your gateway or terminal keeps them
2
Scopes applied to every record by default: restaurant first, then branch
5
Money actions that can sit behind a manager PIN before the till commits them
A role for the job, not a role for the job title
Most restaurant software hands you three fixed roles and hopes your floor matches. RestioX lets you build the role you actually staff: a shift lead who can comp a dessert but not reverse a drawer, a Friday-only waiter who can push orders to the kitchen and nothing else, a bookkeeper who reads reports and never sees a table. Permissions are set per module and per action, so the line between reading something and changing it is yours to draw.
- Custom staff roles, built per venue rather than picked from a fixed list
- Per-module and per-action permissions — viewing an order and voiding a line are separate rights
- A manager PIN in front of voids, refunds, discounts, price changes and drawer reversals
- Per-device registration for the staff app, so an unregistered phone is not a signed-in phone
- Remote revoke — a lost device loses its session from the admin, not from the device
- OTP login with throttling, so repeated attempts stop being useful long before they work
Permissions are checked on the server on every request. Hiding a button is never the only thing standing between a waiter and a refund.
Six things you can switch on before your first dinner service
None of these are add-ons or a higher tier. They are configuration screens in the admin, and they are worth an hour of someone’s afternoon on day one.
Custom roles and permissions
Build roles per venue and tick permissions module by module, action by action. Change the role and every account holding it changes with it — no editing twenty staff records by hand.
Manager PIN on the money
Voids, refunds, discounts, price changes and cash drawer reversals can each require a manager PIN at the terminal before the till will commit them.
Registered devices
The staff app registers the device it runs on. When a phone leaves in someone’s pocket, revoke that device from the admin and its session goes with it — everyone else keeps working.
OTP login with throttling
One-time codes for sign-in, rate-limited so a stolen phone number does not turn into an unlimited guessing game against your account.
Restaurant and branch scoping
Every record carries the restaurant and branch it belongs to, and that scope is applied globally rather than remembered query by query by whoever wrote it.
Audit log and print log
Who cancelled, who refunded, who discounted, who reprinted a bill — recorded with a timestamp, and kept for a retention window you set yourself.
The branch filter is not optional, because nobody types it
The usual way a group leaks data between its own branches is mundane: somebody writes a report query and forgets the branch condition. RestioX applies the restaurant and branch scope globally, at the model layer, so the query that forgot is filtered anyway. And when the scope cannot be resolved at all — a background job with no session, a request that arrives without context — the answer is nothing, not everything.
- Every record carries the restaurant and the branch it was created under
- Scoping is enforced globally, not repeated in each query by each developer
- Deny by default — unresolved scope returns an empty result, never the whole table
- A dedicated isolation test suite of 29 tests that exist purely to try to cross the line
# a report query written without a branch filter
SELECT * FROM orders WHERE status = 'completed'
# what runs, once the global scope is applied
SELECT * FROM orders WHERE status = 'completed'
AND restaurant_id = 12
AND branch_id = 4
# background job, no session, scope unresolved
SELECT * FROM orders WHERE 0 = 1 -- deny by defaultThose 29 tests run against the scoping rules themselves. They are the difference between believing branch separation still holds and checking that it does after every change.
The morning-after question, answered from one screen
Every service produces a handful of exceptions: a comped starter, a main voided after it was fired, a card refunded at the door, a price typed over for a regular. Each one is written to the action audit log with the person, the action and the timestamp, so the conversation the next morning starts from a record instead of four people’s memories.
Printing is logged too — every bill and kitchen ticket that left a printer and who asked for it, which is usually how a duplicate KOT gets explained. Retention is configurable, so you keep the history your own bookkeeping and local rules require, and no longer.
- Cancellations
- Refunds
- Voided items
- Discounts
- Price changes
- Reprints
The unglamorous measures, actually switched on
-
A vault for other people’s keys
Marketplace and payment gateway credentials are stored encrypted rather than sitting in a settings table in clear text. The manager who connects an integration does not have to be able to read the secret in order to use it, and a database export does not hand over your gateway.
-
Signed inbound webhooks
Delivery marketplace and payment callbacks are checked against their signature before anything is written. A payload that arrives unsigned, or signed with the wrong key, is refused.
-
Payment hooks fail closed
If a payment callback cannot be verified, RestioX refuses it rather than marking the order paid on a maybe. An unverifiable payment is a payment that did not happen.
-
Hardened session cookies
Sessions are HttpOnly, SameSite and Secure — not readable from page scripts, and not carried along by a request that came from somewhere else.
-
CSRF protection
State-changing requests carry a token, so a page on another site cannot quietly make one of your signed-in managers act on its behalf.
From the first tap at the till to the backup — and out again
-
At the till
It is written with its owner
The record is created carrying the restaurant and branch it belongs to. That stamp is what every later read gets filtered against, for the whole life of the row.
-
Immediately
Sensitive changes are logged
Cancellations, refunds, voids, discounts and price changes are appended to the audit log with the person who made them and the minute they did it.
-
On your schedule
The database is backed up
Scheduled backups run on the interval you set, to the storage location you configure. Backup and storage are both admin settings, not a support request.
-
When you need it
A backup is restored
Restore runs from the same module that made the backup, so recovery is a screen you have already seen rather than a ticket and a hopeful wait.
-
Whenever you want
You take it with you
Reports export to Excel or PDF, and the same REST API the till and kitchen screen use will read your records programmatically. Nothing here depends on your data being hard to remove.
-
Eventually
Old entries age out
Audit-log retention is a setting rather than a default you inherit, so the history you keep is the history you decided to keep.
A health check reports on the database, the queue and whether storage is writable — so a backup that quietly stopped running is something you can see, rather than something you find out about later.
Want it endpoint by endpoint?
The developer page documents how a token inherits the restaurant, branch and permissions of the staff account behind it, and how inbound webhook signatures are verified.
What we hold, and what your payment provider holds
RestioX does not process card payments itself. The gateway or card terminal you configure does that, and the card data stays with them. What RestioX keeps is the commercial record: what was paid, in which currency, against which order, through which provider — the things a sales report needs, and nothing you would rather not be storing.
| Data | Held in RestioX | Held by your gateway or terminal |
|---|---|---|
| Full card number | No | Yes |
| Card security code | No | Yes |
| Authorising and settling the card | No | Yes |
| Amount, currency and payment status on the order | Yes | Yes |
| Which gateway or terminal took the payment | Yes | Yes |
| A refund raised at the POS and executed by the provider | Yes | Yes |
RestioX does not hold a SOC 2 report, an ISO 27001 certificate or a PCI DSS attestation, and we are not going to imply otherwise. What the platform gives you are the controls those programmes ask about — scoped access, role-based permissions, an audit trail with retention, encrypted storage of third-party credentials, signed webhooks and scheduled backups — so that meeting your own obligations is a matter of configuring the software rather than working around it. Where card data is in scope, it is handled by the payment provider you choose.
Three situations where these controls earn their keep
Multi-branch groups
A branch manager sees their own floor, an area manager sees the branches they run, and the group sees all of it — from one installation and one set of roles, instead of three databases and a spreadsheet that reconciles them.
Franchise and partner estates
A franchisee runs their venue without ever reaching into anyone else’s numbers, while the brand keeps a reporting view across the estate. The separation is enforced by the platform, not by an agreement everyone promises to honour.
Venues with heavy staff turnover
Seasonal and part-time staff get a narrow role and a registered device on their first shift, and lose both on their last — without anyone sharing a manager login to get through a busy Saturday.
The questions a cautious buyer actually asks
The people you give a role to, inside the branch you give it for. Every record carries its restaurant and branch, and that scope is applied globally rather than added query by query, so a staff account cannot reach another venue’s orders by changing a number in a URL. When the scope cannot be resolved at all, the result is empty rather than complete — the platform denies rather than guesses. A dedicated suite of 29 automated tests exists purely to keep that true as the software changes.
You open the admin and revoke it. The staff app registers each device it runs on, so revoking cuts that one device off without disturbing anyone else’s session and without needing the phone in your hand. If you also want the account itself out of service, narrow or remove its role — permissions are checked on the server on every request, so the change takes effect on the next tap rather than the next reinstall.
Yes. Reports export to Excel or PDF, the backup module produces a full database backup you can restore from, and the same REST API the till and kitchen screen use will read your records programmatically. Nothing about the platform depends on your data being difficult to take with you.
As often as you schedule them. Backups run on the interval you configure, to the storage location you configure, and restoring is done from the same module in the admin. There is also a built-in health check covering the database, the queue and storage, so a backup that has quietly stopped running is visible rather than assumed.
No. Card payments are processed by the gateway or card terminal provider you configure, and the card data is handled by them. RestioX keeps the commercial record — the amount, the currency, the order it belongs to and which provider took it — plus your gateway credentials, which are stored encrypted rather than in clear text.
No, and we would rather say so plainly than dress it up. RestioX does not hold a SOC 2 report, an ISO 27001 certificate or a PCI DSS attestation. What it does give you are the controls those programmes ask about — role-based access, tenant scoping, an audit trail with configurable retention, encrypted storage of third-party credentials, signature-verified webhooks and scheduled backups — which is what your own obligations are usually built on.
Configure the controls before the first shift
Create your account, build the roles your floor actually needs, put a manager PIN in front of the money and turn the backup schedule on. It is an afternoon of work now, and it is far easier than retrofitting all of it during a busy December.
Start Free Trial