Shares
Split checks
Split a bill any number of ways and settle each share on its own. The receipt prints one sale with the shares under it, not three receipts that each look like a separate order.
POS
A till that does not stop
An ordinary Android tablet. Big targets, one screen for the order and one for taking the money, and a connection state that is always on screen.
Taking an order
Fast, and impossible to quietly get wrong
The same money code runs on the tablet, the server and the web, so a total is never surface-specific.
- Sized for a thumb
- Categories, items, modifiers and quantities — and removing a line while the order is still open.
- Totals from one calculation
- Money is an integer number of cents everywhere, split by allocation rather than division, so the cents cannot go missing between two screens.
- Tax snapshotted when the order is placed
- Change the rate later and this order still reads what the guest was charged.
- No edits after firing
- Once the kitchen has the ticket, adding a line to it is refused — on the tablet and again at the server, so a stale terminal cannot slip one through.
Taking the money
Every way a bill actually gets settled
Part cash, part card, part backup terminal — in any order, on a share or on the whole bill.
Tenders
Multi-tender
A partial card approval keeps the approved amount and carries on from the remainder. It is never treated as a decline.
Cash
Change without arithmetic
Quick amounts, exact change worked out for you, and a drawer count at close-out that names the variance instead of hiding it.
Degraded
When the card route is down
The Card button stays on screen, greyed, with the reason on it. A missing button leaves a cashier guessing; a labelled dead one does not.
What has been through a physical run, and what has not. Cash is certified on the tablet, offline included. Split checks and multi-tender are proven in the money core and in the system certification; neither has yet been exercised on a tablet in a physical run. Recording a payment taken on an independent terminal is built and tested; no physical backup terminal has been run end to end yet.
The unknown payment. If a card request goes out and no answer comes back, DineStack stops and says exactly that: we do not know whether this card was charged. It offers a status check rather than another tender, because the one thing worse than an unclear payment is charging a guest twice while trying to clear it up.
Offline
Not a limited fallback
The tablet holds its own event log and the full pricing engine. This is the sequence when the line drops mid-service.
Stage 1
Staff still sign in
With a PIN, offline. The authorised roster is cached and refreshed while the register runs, so switching somebody off reaches the counter.
Stage 2
Orders are priced locally
Recorded on the device and tendered in cash. Nothing waits for a server to answer.
Stage 3
The queue holds
Every write carries a key the tablet generated before it tried, which is what makes a retry safe.
Stage 4
Reconnecting syncs once
A retry after a dropped connection cannot double-charge a guest or duplicate an order.
A tablet killed mid-service comes back
The open order, the payment in progress and the signed-in staff member are all recovered from the log — not from memory, which is why a force-stop costs nothing.
The screen names its own state throughout: online, syncing, offline, degraded. It never quietly stops working.
Accountability
Who did what
Every action that matters carries the staff member who took it: the order, the void, the discount, the refund, the drawer pull, the cash count.
Because $40 has to have an answer
Not for surveillance. When a till is $40 short, “who was on the register” has to be answerable — and a void nobody can attribute is how theft goes unnoticed.
Asked twice, in two places
Voids, discounts, refunds, no-sale drawer pulls and close-out sit with a manager. The tablet and the server ask the same permission table, so hiding a button is never the only thing stopping somebody.