Troubleshooting

The website address on the key does not match the address the site is really served from. PosiTack only sends a paying customer back to an address the venue itself registered — a safety rule, because that is where someone lands seconds after paying.

Everything else keeps working, which is why this one hides: the menu shows, the order is accepted, the kitchen prints. Only the site name counts (www. and no www. are treated as the same site), so the usual causes are a key made while the site was on a staging address, a different subdomain, or a typo in the saved address. The plugin's settings screen warns about a mismatch.

The fix: the venue opens Settings → Websites, presses Edit on the website and corrects the address. The key stays the same. Then press Connect in the plugin once, so live menu updates are registered at the corrected address.

The ordering page is calling PosiTack straight from the diner's browser. PosiTack does not accept calls from pages on other domains, so the browser blocks them before they arrive — the table, menu and order calls all fail the same way.

The plugin never does this. A site built without it has to send those calls through its own server; see Build your own ordering page.

The call went to positack.co.za (or another address) instead of the venue's own PosiTack address, {venue}.positack.co.za. Sign-up and sign-in answer with this message; on the same wrong address, signed-in diners also get 401 as if they had been signed out, and forgotten-password emails never arrive. Table and order calls happen to work without it, which is why ordering can look fine while accounts fail. The address is the tenantHost returned by GET /api/integration/site.

Usually not a fault. The website shows what the venue publishes to its online / QR menu, and a venue that has hidden its categories from that channel has published nothing. The plugin says so rather than showing an error. Ask the venue to check which categories are visible online.

Exactly that: the plugin needs API access for the menu as well as ordering, and the venue's plan does not have it. The venue needs to upgrade their plan with PosiTack; nothing needs to change on the website afterwards — press Connect again once it is done.

The key was mistyped, has been rotated, or was revoked. PosiTack gives the same answer for all three on purpose, so that nobody can probe for keys. Ask the venue to rotate it in Settings → Websites and send you the new one — it is only shown once. If it was revoked by mistake, the venue can press Reinstate instead and the old key works again.

The key works but was created without the permission the call needs — almost always Ordering (tables and QR codes) left off. The venue opens Settings → Websites, presses Edit on the website and ticks the missing box. The key stays the same and nothing needs to change on the website.

PosiTack notifies the site the moment the menu changes. If the notification cannot get through, a scheduled sync still corrects the site, just more slowly. Things that block the notification:

• a security plugin or firewall rule refusing unauthenticated POST requests to the WordPress REST API;
• password protection on a staging site;
• a Cloudflare rule challenging requests that do not come from a browser.

Allow POST requests to /wp-json/positack/v1/webhook (or ?rest_route=/positack/v1/webhook on plain permalinks). They are signed and checked by the plugin, and they carry no menu data — only “come and look”. The venue can check the Menu updates line on the key in Settings → Websites.

The scheduled sync relies on WP-Cron. On a site with DISABLE_WP_CRON set, make sure a real cron job calls wp-cron.php.

The plugin limits how many requests one address can make per minute, to protect the venue from floods. Every phone on a restaurant's WiFi shares one public address, so a very busy venue can reach it. The defaults are sized for a full restaurant; raise them with the positack_rate_limit filter if needed. Versions before 1.2.1 had a bug that made this far more likely — update if the site is older.

add_filter( 'positack_rate_limit', function ( int $per_minute, string $bucket ) {
    return 'read' === $bucket ? 1200 : $per_minute;
}, 10, 2 );

The plugin discovers the venue's own PosiTack address when it connects. If sign-in fails while ordering works, reconnect from the Positack screen in WordPress so it discovers it again. On a site pointed at a staging copy of PosiTack, see the positack_guest_base filter.

Uninstalling the plugin deletes the key from the website, but only the venue can switch it off in PosiTack. Ask them to revoke it in Settings → Websites as well.

Email support@positack.co.za with the site address, the plugin version, and what the plugin's settings screen says. Never send the site key.