Integrating Online Ordering With Your POS: What It Takes and What It Saves

Two Systems, One Kitchen

A restaurant with online ordering and a POS that do not talk to each other has a very specific look. There is a tablet on the counter that beeps. Someone reads the order off it and types it into the till. A printer produces a ticket. Somewhere in that sequence, on a busy Friday, a customer's no-onions instruction disappears.

Every operator we have worked with recognises this. The tablet is not the problem. The re-keying is. It costs staff time on every single order, it introduces errors at the worst possible moment, and it means the reporting in the POS and the reporting in the ordering platform never quite agree.

Integrating online ordering with the POS removes the re-keying. This is what that actually involves, what it costs, and where it goes wrong.

What Integration Actually Buys You

It is worth being precise about the benefits, because they are not evenly valuable.

• Orders arrive directly on the POS and print to the kitchen without anyone typing. This is the main event and it is worth roughly 60 to 90 seconds per order in staff time, plus the errors avoided.
• One menu, maintained in one place. Change a price in the POS and it reaches the website and the app. Restaurants without this maintain their menu two or three times and their prices drift apart.
• Live stock and availability. When the kitchen marks a dish as sold out, it disappears online immediately instead of being sold for another hour.
• Unified reporting. Sales by channel, product mix, and daily takings come from one source, which makes the accountant's job simpler and the operator's numbers trustworthy.
• Loyalty and customer records that span channels, so a regular is recognised whether they order in person or online.

Not all of these need to arrive at once, and the sequencing matters. Order injection first, then menu synchronisation, then stock, then reporting. Operators who try to do everything in one project usually stall on the hardest piece and get none of the benefit.

How Integration Actually Works

Broadly there are three technical patterns, and which one is available depends entirely on the POS vendor.

Cloud API integration. Modern cloud POS platforms expose an HTTP API. Your ordering system authenticates, pushes orders, pulls the menu, and receives status updates by webhook. This is the clean case and the one to prefer.

Local integration. Older POS systems run on a machine in the restaurant with no external interface. Integration requires a small local agent, usually on the same network, that receives orders from the cloud and injects them into the POS through a local API, a database write, or a file drop that the POS watches. This works but adds a physical dependency: if that machine is off, orders do not arrive.

Middleware. A third-party integration platform sits between the ordering system and the POS and speaks both protocols. This costs a monthly fee per site and saves considerable development effort. For a small group using a well-supported POS, it is often the correct commercial decision even though it is less elegant.

If your POS offers none of these, the honest answer is that integration is not viable and the choice is between changing POS or accepting the tablet. We say this to clients regularly, and it is better said early than after three months of trying.

The Menu Mapping Problem

The single hardest part of POS integration is not orders. It is menus.

A POS menu is built for staff taking orders at speed. Products have short codes, modifiers are structured around till workflow, and the same physical dish may exist as several buttons for different contexts. An online menu is built for customers browsing. It has descriptions, photographs, dietary flags, an ordering logic that guides choices, and a structure organised around how a customer thinks.

These two structures do not map cleanly onto each other, and pretending they do is why so many integrations produce a nonsensical online menu.

What works:

• Keep the POS as the source of truth for products, prices, and tax treatment. These must match or your reporting and your accounts will not reconcile.
• Keep the online platform as the source of truth for presentation — descriptions, images, ordering of categories, promotional badges.
• Maintain an explicit mapping table linking POS product identifiers to online items, editable by a human. Automatic matching by name works for perhaps 80% of a menu and produces confident errors for the rest.
• Handle modifiers carefully. This is where the real complexity lives. A pizza with a size, a base, three toppings, and a half-and-half option can be one POS product with modifier groups, or several products, depending entirely on how that POS models it. Get this wrong and the kitchen ticket is wrong, which is worse than no integration at all.
• Support items that exist in one system only. Online exclusives and in-store-only specials both exist, and the mapping needs to allow for them without breaking sync.

Budget more time for menu mapping than for anything else in the project. On multi-site groups, expect the mapping to differ per branch, because branch menus always diverge in practice regardless of what head office believes.

Order Injection Details That Matter

Pushing an order into the POS is more than sending a list of items. What has to be handled:

• Order type. Delivery, collection, and table service are different in the POS, often with different tax treatment and different kitchen routing.
• Timing. An order for 7:30pm must not print in the kitchen at 6:15pm. The POS needs to hold it or the integration needs to delay injection.
• Customer notes and allergy information. These must appear prominently on the kitchen ticket. An allergy note lost in transit is a serious incident, not an inconvenience.
• Payment status. The POS needs to know the order is already paid so it is not charged again at the till and so the cash-up reconciles.
• Discounts and promotions. If a code was applied online, the POS needs the discount represented in a way its reporting understands.
• Delivery charges and service fees as their own lines, with correct tax treatment.
• The channel identifier, so reporting can distinguish web, app, and aggregator orders.

Two operational rules save a great deal of pain. Make injection idempotent, keyed on your order identifier, so a retry after a timeout does not produce a duplicate order and a duplicate meal. And never let a failed injection silently swallow an order — if the POS cannot be reached, the order must still surface loudly on the tablet with an alert, because the customer has already paid and is expecting food.

Stock, Availability and Rejections

Real-time availability is the feature customers notice most, because being sold something the kitchen cannot make is a memorably bad experience.

Practical implementation:

• Give the kitchen a fast way to mark an item unavailable, and propagate that online within seconds. A one-tap toggle on the POS or a tablet is enough.
• Support scheduled availability for items only offered at certain times, so the lunch menu disappears at 3pm without anyone remembering.
• Provide a way to pause online ordering entirely or extend quoted times when the kitchen is overwhelmed. This single control prevents more damage on a busy night than any other feature.
• Handle rejection gracefully. If an order cannot be fulfilled, the refund, the customer notification, and the POS state all need to move together.

Full ingredient-level stock control integration is technically possible with some POS systems and is rarely worth it for restaurants. Item-level availability captures nearly all the benefit for a fraction of the complexity.

Multi-Site Complications

Everything above gets harder with more than one branch.

• Menus and prices diverge by branch, always, no matter what the group's policy says.
• Each site may have its own POS terminal, its own local agent, and its own network reliability.
• Head office wants consolidated reporting while each branch wants control of its own availability.
• Rolling out a change means rolling it out to sites that are open at different hours, which effectively means it must be safe to deploy mid-service.

The architecture that handles this cleanly is a central platform holding the group menu with per-branch overrides, plus a per-branch integration channel that can be independently paused. Attempting to enforce one identical menu across all branches will fail, and the software should accommodate reality rather than fight it.

We built exactly this shape for multi-branch ordering operations, and the override model is the part operators consistently say they could not manage without.

Monitoring, Because It Will Break

An integration that is not monitored is an integration that fails silently at the worst moment. The alerts that matter:

• A local agent that has not checked in within a few minutes.
• Any order that has not been acknowledged by the POS within a short window.
• A menu sync failure.
• An unusual gap in orders during trading hours, which is often the first sign that something upstream has broken.

Alerts must go to someone who can act — the branch, not only a developer's inbox. And there must be a documented manual fallback, which in practice means the tablet stays on the counter as a backup even after integration is live. Operators who throw the tablet away on go-live day regret it the first time an internet connection drops mid-service.

Aggregator Orders Belong in the Same Pipeline

Restaurants integrating their own ordering platform frequently overlook the other tablets on the counter. Aggregator orders from the major delivery platforms arrive on their own devices and get re-keyed exactly like web orders used to be.

Most aggregators offer order-injection APIs or partner integrations, and routing them through the same pipeline as your direct orders produces two benefits beyond the obvious time saving. The kitchen sees one queue rather than three, sequenced correctly, which is a genuine operational improvement on a busy service. And reporting finally covers every channel in one place, which is the only way to see the real picture of what each channel costs and contributes.

The complication is menu mapping again, since aggregator menus have their own structures and often their own inflated pricing to absorb commission. That mapping is worth maintaining rather than avoiding: an operator who cannot compare true margin per channel cannot make an informed decision about which channels to keep.

What It Costs

Rough guidance from projects we have delivered.

A cloud POS with a well-documented API, one site, order injection and menu sync: typically four to eight weeks and a mid-four-figure to low-five-figure sum. A local agent integration with an older POS: add several weeks, mostly spent on vendor cooperation and on-site testing rather than code. Multi-site rollouts add per-site configuration and testing rather than fresh development, so the marginal cost per branch falls quickly after the first two.

Middleware alternatives typically cost a monthly fee per site. For a single restaurant, that is often cheaper over three years than a custom integration. For a group of ten sites, custom usually wins.

The comparison that actually matters is against the cost of not integrating: staff time re-keying every order, the error rate, and the reporting mismatch. At even modest volume, that number is larger than operators expect once they measure it honestly.

Before You Commit

Questions to put to your POS vendor before scoping anything:

• Do you have a documented API, and can we have access to the documentation now rather than after signing?
• Can orders be injected with modifiers, notes, order type, and paid status intact?
• Can we read the menu, including modifier groups, programmatically?
• Can we receive order status updates, or must we poll?
• Is there a sandbox environment?
• What are the rate limits, and what does the API cost?

A vendor who cannot answer these quickly is telling you something important about how the project will go. Choosing a POS with a real API is the single decision that makes everything downstream easier, and it is worth weighing heavily when a restaurant is selecting a system in the first place — a subject we covered in our guide to choosing a POS for multi-location restaurants.

We build ordering platforms and the integrations that connect them to the till. If you are weighing up whether your POS can support it, or you want a realistic scope for a multi-branch rollout, our contact page is the fastest route to an answer.