Terminal hardware

The POS runs as a desktop app on macOS and Windows so it can drive the hardware on the counter: a receipt printer plugged into the till, the cash drawer hanging off it, a barcode scanner, and a second screen facing the customer.

Everything on this page is set up on the terminal itself, under Account → Hardware. It is per-terminal on purpose — the printer under one till is not the printer under the next one. Printers shared across a branch over the network stay in the dashboard under Settings → Printing.

#Connecting a printer

Pick how the printer is attached:

Then set the paper width and code page to match the printer, and use Test print to confirm it. Use cp1256 for Arabic receipts.

Check paper asks the printer how it is doing without printing anything — useful before a rush, and the fastest way to tell an empty roll from an open cover or a dead cable.

#The cash drawer

On virtually all hardware the drawer opens on a pulse sent through the printer, so it needs the drawer cable plugged into the printer rather than into the computer. Turn on Open the drawer on a cash receipt and it opens as the receipt prints — on cash sales only, so a card sale never pops the drawer. Open drawer in hardware settings tests it, and a no sale in the cash drawer screen opens it for a manager-approved reason with a record in the shift report.

#When printing fails

A silent failure means a customer walks off without a receipt and nobody knows, so the terminal checks the printer before it sends a job and tells the cashier what is actually wrong: out of paper, cover open, not answering, or not set up at all. Fix it and print again from Orders.

#Barcode scanners

Any scanner that behaves like a keyboard works — no driver, no pairing. Put the barcode on the item in the dashboard under Menu → the item → Barcode, and a scan on the order screen adds that item to the ticket.

Scans are captured by the app itself, so a scan never lands in a search box or a notes field by accident. Scanning something with no matching item says so rather than doing nothing.

Scanning a printed receipt recalls the order it belongs to: the terminal reads the order number off the code and opens Orders on that sale, ready to reprint, void or refund. A scan does one of those two things and nothing else.

#Screens

A terminal lists every display attached to it; tap one to move the app there. That is how a kitchen screen picks its monitor and how a till drives a customer-facing second display.

Kiosk mode fills the screen and blocks the way out to the desktop, which is what you want on a machine a customer can see. Leaving kiosk mode needs a manager — it is gated on devices:manage. So does quitting: Leave the terminal in hardware settings asks for a manager's PIN before it closes the app, which is the only way back to the desktop while kiosk mode is on.

#The customer-facing display

A counter with a second screen can show the customer their order as it is rung up. Choose which screen faces the customer under Hardware → Customer display; a terminal with one screen leaves it off and nothing changes.

The customer screen has no controls of its own beyond two prompts. It shows branch branding while the till is idle, then the lines as they are added with the running total and the amount due. At payment it asks for a tip, and the choice the customer makes lands on the till. After payment it shows the total, any change owed, and asks whether they want a receipt printed.

Keep the screen awake stops the display sleeping in the middle of service, and Start when the machine boots brings the terminal back on its own after a power cut. If the app ever crashes it restarts and returns to the screen it was on, with the order in progress still on the ticket.

#Updates

Terminals update themselves. A new version downloads in the background and installs only once the till has been idle for a while, or when a manager taps Install and restart. Nothing restarts during a dinner rush, and a manager can defer an update they do not want yet.