Order flows — Pay-First vs Pay-Later

Fooodo supports two distinct order flows. They differ in when the kitchen sees the order and when payment happens. The choice depends on the service style, not the restaurant — a single restaurant can run different flows on different tables.

Pay-First

takeaway · quick service

1. 1Guest scans QR, builds cart
2. 2Guest pays
3. 3Order is exported to R-Keeper
4. 4Kitchen prepares
5. 5Guest receives or collects

Pay-Later

dine-in · table service

1. 1Guest scans QR, builds cart
2. 2Items go to R-Keeper kitchen immediately
3. 3Guest adds more rounds (each one syncs)
4. 4Guest asks to pay
5. 5Order locked → marked paid in R-Keeper

Fooodo's order flows talk to your POS through a connector contract. R-Keeper is the live reference connector today — the mechanics below describe what every connector implementation has to satisfy.

Pay-First

Use Pay-First when guests should pay before service starts: takeaway, quick service, food courts. The kitchen never sees an unpaid order; the POS sees one order export per cart; if a guest abandons the cart, nothing reaches the line.

Pay-Later

Use Pay-Later for dine-in and multi-round service. The first round goes to the POS the moment it's submitted; later rounds are added to the same POS order one at a time. The order stays open in the POS from the first round until payment closes it. Internally, Fooodo tracks which items have already been sent so each round only syncs once.

Why the flows differ

The mechanical difference is small — Pay-First makes one POS export, Pay-Later makes many. The operational difference matters more:

• In Pay-First, the kitchen does no extra work if a guest abandons the cart. But the guest experience is wrong for dine-in: people expect to pay at the end; asking upfront feels transactional, not hospitable.
• In Pay-Later, the guest experience matches a normal restaurant. The operator accepts a small risk that an order might not be paid (a guest walks out, a card fails) — the same risk that exists with any paper-bill service today.

Many chains start with Pay-First on takeaway counters, then layer Pay-Later onto dine-in tables once staff are familiar with the admin.

Configuring the flow

Flow is set per-table or as a restaurant default in the admin panel. A restaurant can mix flows — for example, dine-in tables on Pay-Later, takeaway counter on Pay-First, both running through the same Fooodo install.

States, in practice

Orders move through a state machine. The names below are exactly what appears in the admin panel — useful both for operators reading their own orders and for integrators consuming order events.

The states most operators care about:

The failure-adjacent states:

Most Locked states resolve in seconds. Persistent Locked usually means a waiter has the order open in the POS and forgot to close it.

Error is the only state that needs human attention. The connector failure logs record what went wrong; the typical resolution is to recreate the order at the POS terminal.

What runs in the background

A small set of scheduled jobs keeps the order layer in sync — operators don't need to memorise these, but integrators consuming Fooodo data should know the cadences:

If the POS is unreachable, jobs retry with exponential backoff; orders queue in their current state and reconcile when the connector recovers.