Why the kitchen never sees an order that was not paid

Most QR ordering systems treat payment as the last step of a form. The guest taps pay, the app shows a spinner, the order is created, and a message goes off to the card provider. If the card is declined, the order is cancelled. If the guest closes the browser, who knows.

We built it the other way round. On Tradeinit the order does not exist in the kitchen until our server has heard from the payment provider that the money is taken. The ticket prints after the payment, never before it. The kitchen display shows it after the payment, never before it.

What that changes on the floor

The chef never cooks a dish that nobody paid for. The waiter never has to walk to a table and ask whether they meant to order. There is no end-of-night list of orders that were started and abandoned, because an abandoned order was never an order.

It also means the refund rate stays honest. A refund on Tradeinit is a deliberate act by a manager with a PIN, logged with a reason, not a clean-up for a payment that half happened.

The guest who closes the browser

Phones lock. Signal drops in a basement. Someone taps pay and puts the phone in a pocket. The payment goes through on the provider's side, but the page that would have told our server never finishes loading.

So a job runs every minute and asks the provider about any payment we have not heard back on. If the money was taken, the order is recorded and printed as if the page had finished. If the guest tries again on a fresh page, the second attempt is matched to the first and nothing is charged twice. The guest sees one order. The kitchen sees one ticket.

Why we do not hide this

It is unglamorous. It is also the part of the system that a venue owner cares about most once they have been burned by a tool that printed tickets for orders that were never paid. We would rather explain it on a web page than have you find out on a Saturday.