Payment continuity
Payment continuity, and the unknown payment
When the card route is unavailable, the Card button stays on screen, greyed, with the reason on it — and cash and your backup terminal are offered instead.
If a card request goes out and no answer comes back, DineStack stops. It says plainly that we do not know whether the card was charged, and it offers a status check rather than another tender. It will not guess. Charging a guest twice while trying to tidy up an unclear payment is worse than the unclear payment, and a system that silently assumed “probably declined” would do exactly that.
Where cards stand. Card payments run through Stripe Terminal. The server side is live-verified; the reader itself has not yet been certified on our hardware. Recording a payment taken on an independent terminal is built and tested; no physical backup terminal has been run end to end yet.
A backup terminal payment is recorded as somebody’s confirmation that a charge was approved, labelled as exactly that, and counted separately in reconciliation until the terminal’s own batch confirms it.
The same rule runs through the product. A labour cost with no pay rate behind it reads “not known”, not zero. An order whose history cannot be read is quarantined and named rather than counted as a free meal. Where DineStack does not know something, it says so.