How POS integration works

TableStack tracks every party's meal from seated to paid to departed. It can run that entirely on its own, or hand the course-and-payment part of that job to your point-of-sale system. This article explains both modes and how they share control safely.

The built-in POS-lite vs. an external POS

Out of the box, TableStack is the POS for service tracking. Your team advances each party through their meal from the floor or the kitchen display, and the app is the single source of truth. This is the default (the "internal" driver) and needs no setup.

Alternatively, you can connect an external POS so your existing till drives the meal status instead. Supported connectors today:

• Square
• Toast
• Squirrel
• Oracle MICROS Simphony
• Lightspeed

Each venue chooses its own connector. One venue in your group can run on Square while another stays on the built-in POS-lite — the setting lives per venue.

How an external POS drives status

When a POS is connected, it tells TableStack about a party's progress by sending inbound webhooks — small messages like "check closed" or "course fired". TableStack translates each provider's message into a status change and moves the visit forward: a fired course advances the party to First or Second Course, and a closed check marks them Paid. When the POS reports a check total, TableStack records the party's real spend alongside it.

Every inbound message runs through the same status-change machinery as a manual tap — the same validation, the same audit log, the same live broadcast to the floor — so a POS-driven change looks identical to a staff-driven one on every screen.

Webhooks are verified per venue

Each venue has its own webhook secret. Every inbound message is signed with that secret, and TableStack rejects anything whose signature doesn't match — so a forged or misdirected call can't move your tables. A venue with no secret configured simply has no webhook to hit (the endpoint returns "not found"). See Connect your POS for setup.

Outbound: opening a ticket when a party is seated

Some connectors also work the other way. When your host seats a party, Square, Toast, and Lightspeed can automatically open a matching order/ticket on the POS so the two systems share one reference. This only happens if you've provided the outbound credentials (an access token plus, e.g., a Square location or Toast restaurant id); without them the connector runs inbound-only. A POS hiccup here never blocks seating — the party is seated regardless and the failure is logged.

Who has authority over status

When an external POS is connected, it becomes the source of truth for the course and payment states. Two states are always owned by your staff no matter what: Seated (your host physically sits the party) and Departed (your busser clears the table) — the POS has no way to know either happened.

For the states the POS owns, a conflict policy decides what happens when staff also tap them:

• POS is authoritative (the default) — staff taps on course/payment states are refused; the POS controls them. Staff can still seat and clear.
• Advisory — staff can still advance those states manually, but the POS may overwrite them. A manual-override lane for venues that want it.

What this affects

• The service lifecycle — a connected POS advances the visit status course by course and to Paid.
• The kitchen display — under the authoritative policy, the manual "advance" button on a ticket disappears for POS-owned steps.
• The floor — POS-driven changes broadcast to the floor view live, and a Departed party still sets its tables to Needs cleaning.
• Guest spend — a reported check total is stored on the visit, feeding visit history in the guest book.

What affects this

• Your per-venue connector choice and webhook secret (see Connect your POS).
• The conflict policy you pick for the venue.
• Before going live, run the certification checklist.