How Zecoa works
One order, four apps, one backend
A customer orders on your own site. Two seconds later it is on the phone at your pass with the accept countdown running. From there it goes to the kitchen screen, to the ticket printer, and out with your own rider — one order record the whole way, nothing to reconcile at close.
One order, end to end
Follow a single order through all four apps.
ZCustomer
Customer orders and pays
18:52:04Aisha opens your ordering site from her home screen — no app store, no download. She picks a chicken shawarma with extra garlic and a side of fries, adds a note about the doorbell, spends some loyalty points and pays with Apple Pay. Her phone sends the cart, not a total; your server prices every line and add-on from your own menu. The card is authorised, not taken. She lands on a live tracking screen.
ZMerchant
The pass accepts it
18:52:06 lands · 18:52:41 acceptedThe phone at your pass sounds and keeps sounding. The order sits at the top of the board as an urgent card with a live countdown and a stripe showing how much of your accept window is left. At 18:52:41 your manager reads the items, taps Accept and sets a 25-minute prep time. The alarm stops. Aisha's tracking screen updates, and the authorised payment is captured — a reject would have released it instead.
Kitchen Display
Ticket lands on the board
18:52:43 — on acceptThe ticket appears in the New column with a pulsing ring until someone acknowledges it, and the thermal printer fires a paper copy on its own. Every line shows quantity, modifiers, and the doorbell note in a highlighted row. The band down the side is green for now; it turns amber at your caution threshold and red at your late one. The All-Day rail updates: nine shawarmas outstanding, four portions of fries.
DriverVue
Your rider takes it out
19:16 — 24 minutes laterA cook taps the ticket through to Ready. Dispatch offers the drop to Marek, who is on duty in that zone, as a full-screen card with a countdown ring: his payout, the distance to the door, the deliver-by time, and a cash flag if it applies. He accepts, works through Kitchen, Collect, Ride, Hand over with turn-by-turn navigation, confirms with a handover code at 19:31, and the order closes.
One backend
Four windows onto the same order.
Not four products wired together afterwards. Every app reads and writes one order record, over a private realtime channel that belongs to your site alone.
Hand-offs
The hand-offs are the product.
One order record, not four integrations
The four apps are windows onto the same order in the same backend, not separate products wired together afterwards. When the pass accepts, the kitchen board, the customer's tracking screen and dispatch all know at once, because there is nothing to sync — they are reading the same record. Nothing has to be matched up at the end of the night, and there is no vendor pointing at another vendor when an order goes missing between two systems.
The prep time flows all the way through
A prep time set at the pass becomes the ready-by that the customer's tracking screen counts down to, the deadline the ticket on the kitchen board is judged against, and the timing dispatch uses to decide when to put the drop in front of a rider. You set it once, on the device you already have in your hand. Stitch a separate kitchen display to a separate ordering site and that number has to be re-entered, or guessed, in each of them.
Your riders are dispatched, not rented
Because delivery runs on the same backend, an order does not leave your system when it goes out of the door. Dispatch knows which of your riders is on duty and in which zone, the rider's position streams back while they ride, cash collected sits against their float, and each drop-off is confirmed with a handover code. Hand the leg to a third-party courier network and that whole stretch — the timing, the customer contact, the data — belongs to someone else.
Reliability
What happens when the network wobbles.
Ordering software is easy to demo and hard to survive a Friday with. These are the parts that earn their keep at half past eight.
- Orders push live, polling catches the rest
New orders arrive over a websocket on a private channel belonging to your site alone, so they appear without a refresh. Behind that, the apps poll on a short interval as a safety net, so an order still lands if the socket drops. A Connected / Reconnecting pill and a last-synced time sit on the screen, so staff always know whether to trust what they are looking at.
- It keeps ringing until someone answers
A new order sets off an audible alert and a pulsing ring on the ticket, and the alert re-plays on an interval for as long as anything is still unacknowledged. It stops when a person acts on the order, not when the sound finishes playing. Silence on a busy pass is a failure mode, so the software is built to treat it as one.
- The board never blanks on a dropped request
If a refresh fails, the last good board stays on screen rather than clearing — a blank screen mid-service is far worse than data a few seconds old. Refreshes also pause while a status change is in flight, so a background poll can never revert a ticket a cook has just advanced, and pause when the screen is hidden, catching up the moment it comes back.
- A jammed printer is not a lost order
Tickets can print themselves the moment an order arrives, to the printer you nominate. If a print fails it is retried, and if it still fails it goes into a print tray with a badge and a banner naming how many tickets are waiting — retry one, or all of them, with a tap. Every ticket also shows a dot for its last print attempt. Failed prints are visible instead of silent.
- The server prices every order, not the app
At checkout the app sends the contents of the cart — items, sizes, add-ons, notes — and no total. The server looks up every price from your own menu, applies discounts, points and delivery charges, and charges what it works out. There is nothing a modified browser or a fiddled request can do to change what an order costs you.
Security
Where the money and the data actually sit.
- HTTPS everywhere, a token per person
Every call between the apps and the backend runs over HTTPS. Customers and staff each sign in for their own token, sent on every request, so access is tied to a person rather than to a device that anyone can pick up.
- Prices are computed on the server
The checkout sends a cart, never a total. Every item, add-on, discount and delivery charge is priced by the server from your own menu, so the amount charged is always the amount you set — not a number the client supplied.
- Card data never touches Zecoa
Cards are tokenised by the payment gateway, which returns a reference that can be charged but is not a card number. Payments are authorised when the order is placed and captured only when you accept; reject it and the hold is released.
- One kitchen never sees another's tickets
Each site subscribes to its own private realtime channel, derived from that restaurant's own identity, and orders are delivered to that channel only. A display can only ever show tickets belonging to the restaurant it signed in to.
- Riders carry a capped float
Every rider has a cash limit. Once they reach it, dispatch stops sending them cash-on-delivery orders until they settle up, which keeps the amount of cash sitting on any one bike or in any one car bounded and accounted for.
See the whole flow on your own menu.
We import your menu, connect your gateway and run a full evening alongside whatever you use now — so you watch a real order move through all four apps, not a demo one.