One Restaurant, Three Delivery Platforms: How Do GrabFood, foodpanda and ShopeeFood Orders Enter One Backend?

A note before we begin: My previous article explored how restaurant SaaS companies can avoid turning localisation into customer customisation. One category of localisation deserves early priority: the order channels that restaurants in a market already depend on. I also touched on this in Four Judgements on Hong Kong’s POS Market—where I argued that delivery integration is redrawing the POS landscape—and in my article on restaurant digital marketing, where order aggregation was central to preventing missed orders. Those articles focused on market observations. This one goes down to the operating level: when a restaurant uses GrabFood, foodpanda and ShopeeFood at the same time, is the real job to connect three interfaces, or to integrate the restaurant’s entire operation?

Three devices do not mean three times the business

It is 5:30 p.m., and a restaurant in Singapore is preparing for the dinner rush. The GrabFood, foodpanda and ShopeeFood devices on the counter begin sounding one after another. A staff member accepts each order, enters it again into the POS, then confirms the set meals, add-ons and notes with the kitchen.

Miss one notification during the rush and the result is usually a chain of follow-up calls, refunds and poor reviews.

This is not unique to one restaurant. As the number of order channels grows, many restaurants face the same operational pressure.

If staff still have to watch three order sources and enter the same information again, digitisation has merely replaced paper tickets with more screens.

That is why I have become increasingly convinced of one thing:

True delivery-platform integration is not about moving three order notifications onto one screen. It is about giving menus, orders, the kitchen, refunds and reconciliation one shared source of truth.

The worst approach: hand all the complexity to frontline staff

Keeping one device for each platform and asking staff to accept, copy and reconcile orders manually can work. In fact, it is often the quickest way for a restaurant to start offering delivery.

But “it works” does not mean “it scales.”

As order volume grows, the problems appear quickly:

Missed orders: a notification goes unnoticed during peak hours and is discovered only after the customer complains;
Entry errors: set meals, modifiers and notes are entered incorrectly when copied into the POS;
Unsynchronised availability: an item sells out in the restaurant but remains available on one platform;
Conflicting states: the platform has cancelled an order, but the kitchen has already started preparing it;
Reconciliation problems: promotions, fees, refunds and settlements from different platforms are mixed together.

The biggest problem is not the number of devices. It is that every difference between the platforms is being handed to the busiest and most error-prone part of the operation: frontline staff.

Getting the order into the backend is only the first step

The most common delivery-integration demo looks like this:

An order arrives from GrabFood and automatically appears in the POS. Another arrives from foodpanda and appears there too.

That is certainly better than manual entry, but it completes only the first step.

Orders from the three platforms are not identical:

products, set meals, modifiers, notes and discounts use different data structures;
“accepted,” “preparing,” “picked up” and “completed” may be defined differently;
responsibility differs across customer cancellations, platform cancellations and restaurant rejections;
event delivery, retry logic and failure recovery may work differently.

The goal, therefore, is not to display three platforms on one page. It is to translate three channels into one internal order model—aligning fields, states and the entire order lifecycle. Only then has the backend truly absorbed delivery operations instead of merely opening three windows.

These may sound like technical details, but the underlying issue is managerial:

Interfaces can differ, but there can be only one version of the truth for an order.

A restaurant SaaS platform can begin by defining its own standard order model:

Created → Accepted → Preparing → Ready for Pickup → Picked Up → Completed
                    ↘ Cancelled / Refunded

Each platform’s states can then be mapped to this model while the original platform state, event source and timestamp are preserved. The platforms may speak different languages, but the restaurant only needs to understand one workflow.

Otherwise, when a customer asks, “Where is this order now?”, operations, the kitchen, customer service and finance may give four different answers.

True integration has six layers

I usually break multi-platform order integration into six layers:

Layer	What it must solve	What teams often overlook
1. Channel connectivity	Bring orders from different platforms into the system reliably	Latency, duplicate events, interface failures and backfilling missed orders
2. Order standardisation	Convert products, quantities, notes, prices and states into one format	Different platforms define the same event differently
3. Menu synchronisation	Map products, set meals, modifiers, prices and availability	Broken item mappings and sold-out items that remain online
4. Kitchen execution	Route orders to the right outlet, station, printer or KDS	Dine-in and delivery competing for capacity and disrupting production
5. Cancellations and exceptions	Handle rejections, cancellations, refunds, outages and state conflicts	The platform has cancelled an order after the kitchen has prepared it
6. Settlement and finance	Reconcile sales, promotions, fees, refunds, receivables and actual payouts	The order total is not the same as the amount received in the bank

The first two layers determine whether orders can enter the system. The middle two determine whether the restaurant can execute them accurately. The final two determine whether the integration can support ongoing operations.

Miss any one of them and you have merely “received an order.” You have not completed the integration.

Order synchronisation is only the entry point. A closed operational loop is the real integration.

An order is a one-off event. A menu changes every day.

The same dish may use different names, images and prices on GrabFood, foodpanda and ShopeeFood. One platform may have an exclusive bundle while another structures modifiers differently. Even outlets under the same brand may have different opening hours and item availability.

Every delivery integration must therefore answer one question first:

Which system is the single source of truth for the menu?

My preference is for the restaurant SaaS backend to manage standard products, variants, outlet menus and availability. Each platform can retain channel-specific prices, images, descriptions and promotions, connected to the internal menu through explicit mappings.

This does not mean every platform must display exactly the same content. It means the business must know which data is controlled centrally and which differences belong to the channel.

Sold-out synchronisation is especially important. A restaurant should not have to disable the same item in three separate apps. If synchronisation fails, it must not fail silently—the system should tell staff which platform has not been updated.

Without a single source of truth for the menu, three platforms will quickly create three different versions of reality.

The front end can have many channels; the kitchen needs one operating rhythm

The restaurant needs to know where an order came from. The kitchen should not have to learn three production workflows.

Once a platform order enters the backend, it should be routed automatically to the correct outlet, production station, printer or KDS. Dine-in and delivery orders can retain their channel labels, but production priority, modifier display and completion rules should follow one operating model.

At peak times, the system must address another problem: do the preparation times promised by the platform reflect the kitchen’s actual capacity?

If orders keep arriving, the restaurant should be able to pause one channel, disable selected items or adjust preparation times. It should not have to wait until the kitchen is overwhelmed and then apologise to customers one by one.

The front end can have many channels; the backend needs one production rhythm.

An order reaching the kitchen does not mean the transaction is complete

The most underestimated part of delivery integration is not order intake. It is refunds and reconciliation.

An order for which the customer pays 100 may include product sales, tax, platform-funded promotions, merchant-funded discounts, platform fees, full or partial refunds, customer-service compensation, the amount receivable and the amount ultimately paid into the bank.

If the backend records only an “order total of 100,” operations sees one sales figure while finance sees another.

Every platform order should therefore distinguish at least:

how much the customer paid;
the actual value of products sold;
who funded each discount;
how much the platform deducted;
the amount refunded or compensated;
the final receivable and actual payout.

This reflects a point I made in my article on overseas payment integration: a transaction is not complete simply because the screen says “Payment Successful.” Refunds, settlement and reconciliation still have to work.

Sending an order to the kitchen does not complete the transaction. The integration is complete only when the money reconciles.

Three integration paths solve the problem at different depths

Restaurants broadly have three ways to consolidate orders from multiple platforms.

Path 1: Hardware aggregation

Orders from different platforms are sent to one printer or received by a single order device.

This approach is quick to deploy and simple to learn. It suits restaurants whose immediate goal is to reduce missed orders. But it often solves only the problem of seeing an order; it may not support menu synchronisation, inventory, two-way status updates or financial reconciliation.

Path 2: Direct platform API integration

The restaurant SaaS provider, POS vendor or restaurant group connects directly to each platform.

This provides the greatest control and makes deeper integration across orders, menus and kitchen operations possible. But each platform introduces its own partnership requirements, interface differences, version changes, monitoring needs and long-term maintenance burden.

Path 3: Third-party aggregation

An aggregator connects to the delivery platforms first, standardises their orders, then passes them to the restaurant SaaS platform or POS.

This is useful for entering a new market quickly or covering long-tail platforms. The trade-off is another layer of cost and dependency. Some platform capabilities may not be fully available, and responsibility becomes harder to trace when something goes wrong.

There is no universally superior path. The real question is whether you only need to reduce missed orders, or whether you need to connect menus, inventory, the kitchen and reconciliation as well.

Build or aggregate? Do not compare monthly fees alone

Teams that compare only subscription prices tend to underestimate the true cost.

I would evaluate four things:

Compatibility with the current system: Which platforms does the existing POS support? Is it one-way order intake or two-way synchronisation?
Order volume and distribution: Are orders concentrated on one core platform, or are several platforms too important to ignore?
Required integration depth: Do you only need order intake, or must menus, inventory, kitchen execution, refunds and finance form a closed loop?
Total cost of ownership: Beyond monthly fees, include implementation, training, maintenance, incident handling and the cost of errors.

If 90% of a restaurant’s delivery orders come from one platform, it may make sense to integrate that core platform deeply while using a lighter temporary approach for the others.

But if all three platforms generate meaningful volume and missed orders, availability errors and reconciliation have become daily operating costs, the restaurant should not buy a tool that offers only a “unified view.”

For restaurant SaaS teams, my view is:

Scenario	Recommended approach
Core market, high order volume and a stable platform	Consider direct integration with the major platform
New market with unvalidated order volume	Use an aggregator first to validate demand
Niche or long-tail platform	Connect through a local partner or middleware layer
Platform without a stable interface	Keep a manual or semi-automated fallback
Capability shared across several markets	Build one order model first, then add platform adapters

The logic is the same as in localisation versus customer customisation: standardise the core and let interfaces and the ecosystem absorb market differences.

Integrate core platforms directly and leave the long tail to the ecosystem. Do not turn every interface into a long-term liability simply to prove your technical ability.

Going live is not the same as working well in the restaurant

Many integration projects have only one acceptance criterion: “The API is connected.”

Restaurants care about different questions:

What percentage of orders enter the backend automatically?
How many orders still require manual re-entry?
Are orders being missed or duplicated?
How quickly do menu and sold-out updates synchronise?
Does the system remain reliable during peak hours?
Do refunds and platform settlements reconcile?

If the interface is live but staff still watch three devices, disable the same item three times and reconcile the month in a spreadsheet, the project is technically complete but commercially unfinished.

Going live is a technical milestone. Removing one step from the restaurant’s workload is the business outcome.

Conclusion

Connecting more delivery platforms should not mean adding more operating workflows inside the restaurant.

The channels may be GrabFood, foodpanda and ShopeeFood today, and another local platform tomorrow. Once orders enter the restaurant, however, they should all speak the same language across products, orders, the kitchen, refunds and reconciliation.

For many restaurants, the first step does not need to be a perfect integration of every feature on every platform. Achieving three outcomes already creates substantial value:

No missed orders. No availability chaos. No guesswork in reconciliation.

The restaurant can then add deeper menu synchronisation, kitchen-capacity controls and cross-platform analysis as order volume and business needs grow.

Restaurant SaaS should not be a “unified inbox” decorated with three platform logos. It should be an operating backend that protects the truth of the order, the menu and the money.

Restaurants do not simply need access to more platforms.

They need one workflow, regardless of where the order originates.

Good delivery integration is not three platform logos in the backend. It is fewer screens for staff to watch during the dinner rush.

If you are building delivery-platform integration for restaurant SaaS, take one real order and follow it through the entire chain: menu mapping, acceptance, production, cancellation, refund and bank settlement. Any point that still requires duplicate work or a spreadsheet workaround is a point where the integration remains unfinished.