Point of Sale

The restaurant point of sale that never stops selling

Touch-optimized order entry with PIN login, floor maps, coursing, split checks and tips — offline-first, in the browser or on our native Android terminal app.

The POS is where every service starts, so it has to be fast and it has to stay up. Novaryq gives your team touch-optimized order entry with floor maps, coursing and split checks, and keeps ringing cash orders through an internet outage — card payments resume automatically the moment you reconnect.

Novaryq POS terminal showing a restaurant order screen

  • Built for service speed

    Quick-tap menus, modifiers, coursing and split checks tuned for a busy floor.

  • Offline-first

    Cash orders keep ringing through outages via an encrypted on-device queue; card payments resume on reconnect.

  • Floor maps & coursing

    Seat guests, fire courses on pace and move checks between tables without friction.

  • PIN login & roles

    Fast staff switching with role-based permissions on every sensitive action.

Browser or native Android — same engine

Run Novaryq on hospitality-grade touchscreens in the browser, or on our native Android terminal app with kiosk lockdown and over-the-air updates. Every surface shares one menu, one order queue and one reporting engine, so nothing lives in a silo.

Every order lands in the kitchen instantly

Tickets route straight to the kitchen display by station, with age timers and tap-to-bump. Online, QR and kiosk orders flow into the same queue as counter orders — one prioritized flow for the whole line.

A ticket, end to end

What actually happens between the tap and the pass

Most POS pages describe screens. This is the path a single order takes through the system, because that path is what breaks on a busy Friday.

  1. Rung in

    Item, modifiers and seat land on the check. Course and seat stay attached, so the kitchen and the server see the same structure.

  2. Routed

    Each line goes to the station that makes it — grill, fry, cold, bar — with its own age timer, rather than one shared ticket printer everyone crowds around.

  3. Fired by course

    Appetisers fire now, mains fire on the server’s call. A table of eight stops arriving in the wrong order.

  4. Split or moved

    Checks split by seat, item or amount, and a check moves to another table without re-ringing anything.

  5. Tendered

    Cash, card, gift card or a split across them. Cash is bound to the open drawer session that took it, so the count at close is a fact and not a reconstruction.

  6. Settled and counted

    The sale hits reporting, inventory depletes against the recipe, and the shift’s cash and tips land in the close.

When the internet goes

Offline is a first-class mode, not an error screen

A restaurant does not stop when its uplink does. Terminals keep taking orders and cash while offline, hold the work in a local queue, and reconcile when the connection returns.

  • Every queued mutation carries an idempotency key, so a replay after reconnect cannot create the same order or the same payment twice.
  • Cash tendering stays available offline; card capture does not, because approving a card the processor never saw would be inventing money.
  • Replay is ordered per device and gaps are detected rather than skipped — an out-of-order or missing batch is surfaced, not silently accepted.
Novaryq POS terminal on a restaurant counter

Claims on this page, and how to check them

Novaryq has no published customer list, so this page offers no customer quotes. What it can offer is the basis for each claim.

Orders survive a network outage
The offline queue is part of the client, not an add-on: mutations are persisted locally with an Idempotency-Key and replayed in order. Ask for the offline walkthrough in a demo and pull the network cable yourself.
Cash counts are attributable
Every captured cash payment is bound to an open drawer session inside the same transaction that captures it. A close that happens mid-payment cannot miss the cash, because there is no window where the payment exists un-attributed.
Integrations are labelled by proof
The public capability registry at /v1/capabilities carries an explicit proof level per integration — catalog, simulator, partner-approved, certified, or observed in production. A capability that is not certified is not presented as one.

See the POS in action

Book a 20-minute demo and run a mock service on Novaryq.