Devices

Settings → Devices.

A till, a kitchen screen and a floor handheld are shared. Nobody wants to sign in with an email and a password at the start of every shift, and leaving one person signed in all day makes every sale look like theirs.

So the terminal itself is what gets bound to your restaurant and a branch. Staff then tap in on top of it with their PIN. Pairing is a one-time setup per terminal, and it survives restarts, updates and reinstalls of the app.

#Two ways to pair

Both end in the same place — a terminal bound to one branch — so pick whichever suits who is holding the device.

Sign in on the device. Open the app, sign in with your own Restro account, and pick the restaurant and branch you want this terminal bound to. If you only belong to one restaurant with one branch, there is nothing to pick and it goes straight through. You are not left signed in afterwards: the terminal belongs to the branch, not to you.

Use a pairing code. For a terminal being set up by someone without a manager account, or one you are setting up from your desk. Generate the code here, read it out, and whoever is at the terminal types it in.

#Pairing with a code

Click Pair a device, choose the app the terminal will run and the branch it belongs to, and give it a name you would recognise on a bad day — Front counter, Kitchen pass, Driver phone 2.

The code appears with a countdown. It lasts fifteen minutes, works exactly once, and the screen confirms the moment the terminal redeems it, so you know it landed without walking over to check.

If the countdown runs out, generate another. Nothing is wasted by an unused code.

#Reading the list

Four counters sit above the list: how many terminals are paired, how many are connected right now, how many need attention, and how many orders are waiting to send across the whole fleet. On a normal service the middle two read the full count and zero.

Below them, devices are grouped by branch. Each row shows its name, which app it runs, the platform and version it is on, when it last checked in, anything it is holding, and who is on shift.

The dot on the left is the terminal's connection:

• Live — it holds an open connection right now. Orders reach it the moment they are placed.
• Idle — it checked in within the last few minutes but is not holding a connection. Usually a tablet that has gone to sleep.
• Offline — it has not checked in for a while. A till that goes offline mid-service is the one to chase.
• Never connected — it paired but the app has not opened since.

#What "needs attention" means

A row picks up a badge when its state predicts an incident. These are the ones worth a phone call:

• Update required — the app on it is too old for the current service and it has stopped trading. See Forced updates below.
• Offline — quiet through what should be a service.
• Stuck orders — orders the terminal tried to send and the server rejected. Someone has to look at them on the till.
• Queue not draining — orders have been waiting more than ten minutes. The terminal captured them fine; it cannot get them out.
• Crashing — the app has fallen over three times or more on this terminal.
• Far behind — two or more releases behind. Not urgent, but worth scheduling.

Badges are ordered worst first, so the first one you see is the one to act on.

#Looking at one terminal

Click any row to open it. That panel is what a support call is answered from — the installed version against the current and minimum supported ones, the platform, when it last checked in, how many live connections it holds, who is tapped in, how deep its offline queue is and how long the oldest item has been sitting there, its crash tally, and who paired it and when.

Nobody has to read numbers off a screen at the venue.

Request diagnostics asks the terminal for a fuller report — its network state, sync state, queue contents by reason, cached menu version, clock drift. The terminal sends it the next time it checks in, which is within a couple of minutes, and the report appears in the same panel. It carries no order contents or customer details.

Sign everyone out ends every shift on that terminal. Whoever is on it taps back in with their PIN. The terminal stays paired and keeps anything it has not sent yet — reach for this when someone left themselves signed in, not when hardware goes missing.

#Renaming and moving

Edit renames a terminal or moves it to another branch.

Moving is a bigger change than it looks. The terminal is signed out, everyone on it has to tap back in, and the orders and menu it had cached for its old branch are cleared — that is deliberate, so no branch's data rides along to another. Rename freely; move only when the hardware has genuinely moved.

#Removing a lost device

Remove device cuts a terminal off in one step. Its token stops working, anyone signed in on it is signed out, and its live connection is dropped within seconds — it does not keep receiving orders until someone notices. This is what you reach for when a tablet walks out of the building.

It disappears from the list. Orders, payments and cash movements it already sent are untouched, and the pairing and removal are both in the activity log, so the record of what happened lives there rather than in a greyed-out row. The same hardware can be paired again with a fresh code.

#Forced updates

Terminals run whatever they last installed, and a venue can go months without updating. Most of the time that is fine and we leave them alone.

When an update is simply available, the terminal shows a small dismissible strip offering it. Staff can carry on and take it later. Nothing is blocked.

When a release changes something a terminal cannot get wrong — how payments are recorded, or how orders reach the kitchen — an older version would file real money or real food incorrectly. Those versions stop trading and show a full screen saying so, what changed, and how to install the update. This is deliberately rare: if staff saw it for routine releases they would learn to ignore it.

Nothing captured is lost. Orders the terminal took offline stay on it, are held rather than retried, and send themselves once the update is installed. The blocking screen tells you how many are waiting, so you know there is work on that till before anyone wipes it or swaps the hardware. A blocked terminal keeps checking in, so this page stays accurate the whole time.

The version each terminal is on, the current release and the minimum supported one are all on that terminal's panel, so you can tell an update-required badge from a merely-old one at a glance.

#Card terminals

The card readers your tills charge on are registered on the same page, under Card terminals.

They run on the payment provider you already configured under Settings → Payments — Stripe or Adyen — so there are no separate credentials to manage. If neither is set up yet, the section says so and the point of sale takes cash only.

Click Add a terminal and we ask the provider which readers it can see. You pick one from the list rather than typing a serial number, so a typo cannot leave a till pointed at nothing. Registered readers are hidden from the list, so you never claim the same one twice.

Each reader belongs to one branch, and every till in that branch can charge on it. Give it a name the person at the counter would recognise.

Connection is how the till reaches the reader:

• Cloud — we tell the reader what to charge through the provider. Nothing to configure on your network.
• Local — the till talks to the reader over your own network, which is faster but needs both on the same network and the reader's address. Available where the provider supports it.

Disable takes a reader out of the till's list without forgetting it — useful while one is away for repair. Delete removes it for good; payments already taken on it are untouched. A reader with a payment still in progress cannot be removed until that payment finishes.

#Who can do this

Anyone with devices:read sees the list, the health badges and each terminal's panel. Pairing, renaming, moving, signing everyone out, requesting diagnostics and removing a device need devices:manage. Registering and removing card terminals needs devices:manage too. If you manage a single branch, you only see and touch that branch's terminals.

Pairing, token rotation, forced sign-outs, diagnostics requests and removals all land in the activity log, with who did it and when.

#What a paired device can do on its own

Nothing worth having. Until a member signs in with their PIN, a terminal can identify itself and read its branch's public settings — that is the lot. No orders, no customers, no menu costs. A stolen tablet with nobody signed in is a brick with your logo on it.