The order lands in the POS and nothing prints at the station

The order is in the POS. It appears in the order list, it will appear in tonight's sales report, and the kitchen has never heard of it. That gap is not a payload problem and it is very rarely an API problem: the POS accepted the order and then made a separate decision about which physical devices should see it, using configuration the restaurant owns and your integration cannot set.

That distinction is the whole diagnosis. Acceptance is an answer about validity. Routing is an answer about which prep station, which printer, which screen — and it is computed from the check the POS created, not from the JSON you sent. What the accepted order becomes is described in the check: what an online order turns into.

Three columns for one order, filled in during a live service

Do this with a single real order rather than a spreadsheet of complaints, and do it while someone is standing at the pass. It takes about 10 minutes and it removes 4 of the 5 candidate causes.

1. Column 1, accepted. Record the POS check id and check number returned in the API response, plus the exact dining option, revenue centre and service-area values you sent.
2. Column 2, visible. Find that check number on the terminal's own order list. Note what the terminal shows for its order type and revenue centre — not what you sent, what it stored.
3. Column 3, queued. Ask the manager to open the kitchen routing view for each prep station and look for the check. If your POS has a printed-tickets or send log, read that too.
4. Compare. A check present in column 2 and absent from every station in column 3 is a routing gap, and the rest of this page applies. A check absent from column 2 was never accepted, whatever your response said, and that is a payload question answered in building an order payload the POS will accept.
5. Repeat once with an order placed by staff on the terminal itself, with the same items. If the staff order prints and yours does not, the difference is in the fields only your channel sets.

The dining option is a routing key you did not know you were setting

Most POS platforms use the dining option — takeaway, delivery, dine-in, curbside, whatever the restaurant has configured — as an input to routing, not merely as a label for reporting. A takeaway order may be configured to print at the expo printer and a delivery order at a packing station, and an option nobody has mapped routes to nothing.

Two failure shapes come out of this. The first is a value that does not exist at that location, so the POS falls back to a default that has no station attached. The second is a value that exists everywhere and has been mapped at 1 site only, which is how this symptom appears at 4 restaurants out of 5 in the same group. Both are cheap to see once you compare what you sent against what the terminal stored, and the reporting consequences of these fields are worked through in order source and dining option.

The revenue centre or service area nobody set on the new location

Revenue centre, service area and floor plan section are the same idea under different names: a subdivision of the restaurant that owns its own devices and its own reporting. Table-service sites usually have several — bar, terrace, main floor — and online orders need one assigned explicitly, because they did not arrive at a table.

When a group adds a location, the revenue centres are often created and the routing rules for the online-ordering centre are not. The check is created against an empty or default centre and there is no device group behind it. Table service adds a second version of the same trap: a check attached to a table inherits that table's service area, and tables are messier objects than they look — two parties at one table covers why.

Items in a category that no station has claimed

This is the partial version of the symptom, and it is the one that arrives as a complaint rather than a ticket: the mains printed and the desserts did not. Station routing is usually driven by the item's category or its printer group, so a new category created for an online-only item — a bundle, a meal deal, a channel-exclusive — has no station until someone assigns it.

• Check the item, not the order. Ask which categories exist and which have a station assignment, then look up your unprinted items in that list.
• Watch for modifier-only lines. Some platforms route a modifier with its parent item and some treat certain modifiers as their own printable line, which is how a single ticket ends up split across 2 stations.
• Expect new items to inherit nothing. A category created last week is the commonest culprit, and mapping items to stations is a standing job rather than a one-off — items to stations.
• Confirm your ids resolve to the items you think they do. A stale mapping row sends a real order for the wrong product, which is the failure described in the mapping table between your ids and the POS.

A device that is offline, unmapped, or quietly out of paper

The mapping can be perfect and the hardware still not deliver. A network printer with a stale address, a screen that lost its pairing after a firmware update, a device group that lists a printer somebody unplugged in April — each produces an order that the POS considers sent and the kitchen never sees. If your POS reports the ticket as printed and no paper appeared, that is a different investigation entirely: the order says printed and no chit came out.

Scheduled orders route when they fire, not when they arrive

An order placed at 11:00 for collection at 19:30 is supposed to sit. Most platforms hold it and release it to the kitchen a configured lead time before the promised moment, which means every mid-morning check of the kitchen screen finds it missing and every investigation into it wastes an afternoon.

Two things make this manageable. Ask the restaurant what the fire lead time is per location, because it is set per location and is frequently different from what head office believes. And make your own order status reflect it: a state of "scheduled, fires at 19:05" answers the guest and the manager without anyone opening the POS.

Acceptance is the POS agreeing your order is valid. Printing is the restaurant's configuration agreeing it belongs to a device. Only 1 of those 2 is anything you control.

Ask for the routing matrix, in writing, before go-live

The artefact that prevents all of this is unglamorous: a grid, per location, of dining option against revenue centre, showing which device group receives it, plus a list of item categories and their station assignments. Most restaurants have never written it down, and asking for it is how the gaps surface before a Friday service rather than during one.

Take it as an export or a screenshot from the POS rather than as a description, hold it per location, and re-check it whenever a menu category or a location is added. It belongs in the same pre-launch pack as your credential inventory — which matters because the identical rules are configured independently per site, the pattern behind it works at the first location and fails at the rest and behind the full menu sync that never finishes.

What we do not supply: printers, screens and the kitchen around them

We integrate with the POS and the kitchen display the restaurant already runs. We do not select, sell or support printers and KDS hardware, and a build that depends on new hardware needs the reseller in the room from week 1. Where the workflow itself is the problem — pacing, batching, what the line can absorb — that is kitchen throughput and fulfilment, a different piece of work from order injection.

What we do own is the part your channel can be held to: a payload that carries defensible values, a status model that distinguishes accepted from fired, and reconciliation that catches a check whose totals moved — your total and the POS total never quite agree. That is ordinary product build work, and the rest of this silo sits under integrating with the POS on the counter, inside our restaurants and food service practice.

• pos
• order injection
• kitchen routing
• diagnostics