Aggregator order injection
Orders from Deliveroo, Uber Eats and Just Eat normalised into a single format and injected directly into the EPOS or kitchen display system, so kitchen staff work from one queue rather than three separate tablets.
Hospitality
EPOS integration
Lightspeed, Toast, Square, Zonal and Tevalis are all capable EPOS platforms for a single site's front of house. What none of them do out of the box is give a multi-site group a single order queue that merges its own till sales with Deliveroo, Uber Eats and Just Eat orders, a menu that stays in sync across every channel and every site, or an end-of-day reconciliation that closes automatically against card settlement rather than by a duty manager checking figures by hand.
We build the integration layer that sits between a group's EPOS estate and everything around it: aggregator order injection so kitchen staff work from one queue instead of three tablets, menu and price synchronisation across sites and channels, and reconciliation that matches EPOS sales against card processor settlement and aggregator commission deductions the same night, not weeks later when a discrepancy is much harder to trace.
The workflow this replaces
The three-tablet problem, and what closes it out
Before order injection and menu sync exist, a busy kitchen and a finance team back at head office are running roughly this process.
Step 01
Three tablets sit at the pass, one per aggregator
Deliveroo, Uber Eats and Just Eat each require their own device running their own merchant app, and kitchen staff during service physically check each one, accept the order, and re-key or reprint it for the kitchen, adding both time and a manual transcription error risk during the busiest part of service.
Step 02
A menu item runs out and someone has to remember to update it three times
Marking a dish sold out on the EPOS does nothing to the aggregator listings, so a kitchen manager, if they remember, opens three separate merchant portals to pause the item, and if they do not remember, the item keeps selling on whichever platform was missed until a customer orders something the kitchen cannot make.
Step 03
A price change requires updating the EPOS and three merchant portals separately
A new menu price, or a seasonal item, has to be entered into the EPOS and then separately into Deliveroo, Uber Eats and Just Eat's merchant portals, each with different item categorisation and different rules about how quickly a change goes live, which makes a same-day price change across the whole aggregator estate unreliable.
Step 04
Aggregator commission is deducted before settlement, and nobody checks the maths
Each aggregator pays out net of its commission, delivery fee share and any promotional cost, on its own schedule, and reconciling what actually landed in the bank against what the menu prices say should have been earned is a manual, error-prone task that most sites do not do consistently, if at all.
Step 05
End of day is closed by manually comparing three or four reports
A duty manager compares the EPOS Z-read, the card processor settlement report, and the daily payout summaries from each aggregator by hand, often staying late to do it, and small discrepancies are written off as unexplained rather than traced, because tracing them manually is not worth the time on a normal night.
None of this requires replacing the EPOS. It requires a layer that receives aggregator orders in one place, keeps menu and price data consistent across every channel from a single source, and reconciles the money automatically against what actually settled, so the manual comparison a duty manager runs every night becomes a report they check rather than a spreadsheet they build.
What we build
Modules in a typical EPOS integration build
Menu synchronisation across sites and channels
A central menu with ingredient and allergen data held once, pushed out to the EPOS, online ordering and every aggregator, so a change made in one place appears consistently everywhere, including item availability toggles during service.
Price banding by location and channel
Central price configuration with markup rules per aggregator, reflecting commission structure, and per site or region, so a London site can run a different price ladder to the rest of the estate without separate menu builds.
End-of-day reconciliation
Automated matching of EPOS Z-reads, card processor settlement and aggregator payout reports, flagging discrepancies the same night rather than leaving them for a weekly bank reconciliation to surface.
Availability and outage monitoring
A group-level view of which sites are live on which aggregator, with alerting when a site drops offline on a channel — commonly caused by a device losing connectivity — so it can be brought back before it costs a full service's worth of orders.
Order and sales reporting
Sales by channel, by site and by item, including aggregator commission cost per order, so a group can see the true margin on a delivery order rather than just the gross sale value.
Integrations
Named systems and interfaces
EPOS
LightspeedToastSquareZonalTevalis
Delivery aggregators
DeliverooUber EatsJust Eat
Payments and settlement
card processor settlement filesPCI-compliant payment gateways
Stock and labour
FourthNory
Aggregator APIs and merchant portal formats change without much notice, and each of the three behaves differently on outage handling, menu item limits and image requirements. Adapters for each are built and maintained separately against a stable internal order and menu model, so a change on one platform does not require reworking the others.
Data and compliance
Requirements written into the build
- PCI DSS
- Aggregator card payments are processed by the aggregator's own payment infrastructure; our integration handles order and payment status data only, without touching raw card data at any point.
- Natasha's Law and allergen data
- Ingredient and allergen data held once in the central menu, versioned so a recipe change updates every channel it appears on, satisfying FSA labelling requirements across EPOS, online ordering and aggregator listings consistently.
- Price banding rules
- Configured per aggregator to reflect commission structure, and per site or region to reflect local pricing, with a full audit trail of when a price changed and what triggered it.
- Reconciliation records
- EPOS Z-reads, card settlement and aggregator payout data retained and linked per transaction, so a specific order can be traced from sale through to bank settlement if a discrepancy is queried.
- Licensing hours
- Alcohol items are excluded from aggregator ordering outside a site's permitted licensing hours, enforced centrally rather than relying on each aggregator's own scheduling tools.
Architecture note
How the system is put together
Order injection is built as an event-driven pipeline: each aggregator's webhook or polling result lands in a normalisation layer that converts it to a single internal order format before it reaches the EPOS adapter, so the EPOS side of the system only ever deals with one order shape regardless of source.
Menu data is held in a central catalogue, with adapters pushing the relevant subset — including price-banded variants — out to the EPOS, online ordering and each aggregator's own menu format. The catalogue, not any single channel, is the source of truth for ingredient, allergen and pricing data.
Reconciliation runs as a nightly batch process matching transaction-level EPOS, card settlement and aggregator payout data by order reference, with a same-day exceptions report rather than requiring manual comparison of separate PDF or CSV reports.
Outage monitoring polls each aggregator's own site-status endpoint alongside a synthetic order check, because an aggregator reporting a site as live does not always mean the connection to the kitdisplay is actually working.
Timeline
Build phases in weeks
Discovery
Weeks 1-3
Audit of current EPOS estate, aggregator setup and menu structures per site, and a phased integration plan.
EPOS adapter layer
Weeks 4-8
Adapters built against the specific EPOS platform or platforms in use, including menu, order and sales data access.
Aggregator order injection
Weeks 9-13
Deliveroo, Uber Eats and Just Eat integration, order normalisation, and kitchen display or EPOS injection.
Menu sync and price banding
Weeks 14-16
Central menu catalogue, price banding configuration by site and channel, and availability toggle propagation.
Reconciliation and reporting
Weeks 17-19
End-of-day reconciliation logic, exceptions reporting, and channel and site-level sales reporting.
Rollout and stabilisation
Weeks 20-22
Site-by-site rollout, kitchen staff training on the unified order queue, and a defined bug-fixing period before managed run begins.
Indicative cost
Budget bands, not quotes
- Discovery and scoping
- £12,000 to £25,000, credited against the build.
- Aggregator order injection for one EPOS platform
- £250,000 to £340,000.
- Multi-EPOS integration across a mixed estate
- £340,000 to £480,000.
- Menu sync and price banding module
- £50,000 to £90,000, often bundled with the core build.
- Reconciliation and reporting module
- £40,000 to £80,000.
Bands assume a UK group of four to fifteen sites on one or two EPOS platforms. A group running three or more distinct EPOS platforms across its estate sits at the upper end due to the additional adapter work.
Where this sits
Related pages
Questions
Frequently asked
Which EPOS platforms do you integrate with?
Most commonly Lightspeed, Toast, Square, Zonal and Tevalis, either singly or, for groups that have grown by acquisition, several of them running in different parts of the same estate. Each exposes a different API shape and a different data model for menus, orders and payments, so an integration layer normalises those differences rather than assuming every site runs the same platform.
How does order injection from Deliveroo, Uber Eats and Just Eat actually work?
Each aggregator sends new orders to a webhook endpoint or exposes a polling API; we consume whichever mechanism each platform requires, normalise the order into a single internal format, and push it into the EPOS or a kitchen display system as if it were entered at the till. Menu availability changes made in the EPOS — an item sold out mid-service — push back out to all three aggregators so a guest cannot order something the kitchen has already run out of.
What happens if an aggregator's API is down or an order fails to inject?
Failed injections are retried automatically against each aggregator's documented retry behaviour, and a failure that cannot be resolved automatically surfaces immediately to site staff and to a group-level monitoring view, rather than the order simply disappearing, which is what tends to happen with a single tablet workflow when a device loses connectivity mid-service.
How do you handle different pricing on Deliveroo, Uber Eats and Just Eat versus the in-restaurant menu?
Price banding is configured centrally — a markup percentage or fixed uplift per aggregator, per site or per item, reflecting each platform's commission structure — and pushed out to each aggregator's menu automatically, so a price change made once in the central menu produces the correct price on every channel without anyone updating three merchant portals by hand.
Can the integration handle sites with different local pricing, for example higher prices in central London?
Yes. Menus and prices are held centrally with the ability to band by site or by region, so a London site can run a different price ladder to a site elsewhere in the group without maintaining entirely separate menu structures, and a group-wide menu change still propagates to every site's correct price band.
Does this cover PCI DSS for card payments taken through the aggregators?
Card payment for aggregator orders is processed by the aggregator itself, not by the site's own payment gateway, so that transaction sits within the aggregator's own PCI DSS scope. Our integration handles the order and payment status data the aggregator reports back — confirmed, refunded, disputed — without needing to touch raw card data at any point.
Tell us what your systems are doing wrong.
Send the problem, not a brief. We will tell you whether it is a project we should be involved in.
Talk to us