Certifying a POS integration

Before you trust a live venue to an external point-of-sale, run the certification checklist. It's a fast, safe, read-mostly sweep that catches the common setup mistakes — a missing secret, a driver that didn't resolve, an unreachable API — before a real service depends on them. Read Connect your POS first if you haven't set the venue up yet.

What it checks

The checklist runs four checks against a single venue:

1. Driver resolves. The venue's configured POS maps to a real connector. If you typed a driver name TableStack doesn't recognize, it would quietly fall back to the built-in POS-lite — this check catches that and fails loudly.
2. Webhook secret is set. Confirms the venue has a secret so inbound messages can be verified. Without one, every inbound webhook would be rejected, so this is flagged as a failure.
3. Inbound mapping is sane. The connector is handed its provider's own sample "check closed" message and must translate it into a Paid status for the expected party. This proves the adapter understands the shape of the messages your POS will actually send.
4. Outbound reachability. If you've configured an access token for opening tickets, the checklist confirms the credentials are present and that the API address answers. Point the API base at your vendor sandbox for this run. If you haven't configured outbound, this is skipped — the venue is simply inbound-only, which is fine.

At the end it prints either NOT CERTIFIED (with the failed items marked) or a pass. A pass is not the finish line: it reminds you to complete a live sandbox seat → close cycle before certifying production.

How to run it

Run the command with the venue's id:

vendor/bin/sail artisan pos:certify {venue}

For example, to certify venue 5:

vendor/bin/sail artisan pos:certify 5

The single argument is the venue id to certify. Point the venue's API base at your provider's sandbox before running the outbound check, so you're testing against the vendor's test environment rather than production.

Reading the results

Each line is prefixed so you can scan it:

• ✓ — the check passed.
• ✗ — the check failed; fix it and re-run.
• – — the check was skipped (for example, no access token, so outbound stays disabled).

A typical inbound-only venue will show a resolved driver, a set webhook secret, a passing inbound mapping, and a skipped outbound check — and that's a healthy result.

After it passes

A green checklist means the plumbing is correct, not that the integration is proven end to end. Finish with a real cycle in the sandbox: seat a test party, fire a course or two, and close the check, then confirm in TableStack that the party advanced through its service lifecycle and recorded a total. Only then move the venue to live credentials.

What this affects

• A certified connection lets the POS drive the visit lifecycle and changes what staff can tap on the kitchen display.
• See How POS integration works for who holds authority over status once a POS is live.