HOST151: Cache shared replay
What this means
Your host's cache can replay one person's store data to another.
Nothing on this device is lost. Ask your host to stop caching the store's API (both /wp-json/ and ?rest_route= addresses). If WCPOS didn't connect, reconnect afterwards.
A caching layer is serving stored REST API responses without checking who is asking: the app sent two differently-authenticated probes and received the first probe's answer both times. On a live store this means one cashier could see another's data. This is a hosting-layer problem — WordPress itself always answers per-user.
When this happens the app retries with a unique cache key on every request. If that proves the key gets past the cache, WCPOS connects and keeps sending the key — this entry is then a warning that the cache still needs fixing. If it can't prove a safe connection, WCPOS doesn't connect until the cache is fixed.
Your data
Nothing on this device is lost. If WCPOS couldn't prove a safe connection, it doesn't connect rather than risk showing one person's data to another; anything already on this device stays there and sends once it connects.
Troubleshoot
For your host or site admin — the cache has to be fixed on the host, even if WCPOS connected by working around it:
- Exclude the store's REST API paths (/wp-json/ and /?rest_route=) from page caching — on LiteSpeed disable REST caching or add a no-cache rule; on WP Engine extend the WooCommerce exclusion to /wp-json/wcpos and the ?rest_route= form; on Sucuri set the caching level to honor Cache-Control.
- The store's API already sends Cache-Control: no-store and Vary: Authorization — the cache layer is ignoring them; point the host at those headers.
- After changing cache settings, purge the cache. If WCPOS didn't connect, reconnect.