What's New

Some customers see "Waiting for this message. This may take a while." on WhatsApp instead of their delivery code. That is WhatsApp catching up on the sender's keys, not the message itself, so the customer needs another way to get the code.

🔑 The code on the Rider Hub. The Proofs tab of Options → Rider now lists every delivery order out or delivered today with the customer's number and the standing delivery code in clear while the order is out. A customer who calls can be read the code after the manager confirms the order number. The delivery grid's Delivery Proofs modal does not show it; only the rider's manager sees it.

📨 Send / Resend code. One button sends the same code again over WhatsApp, SMS or e-mail, with the same one-minute hold the rider has. Verified or delivered orders show neither the code nor the button.

🗺️ Live map, redesigned. Each rider is a bike marker in their own colour. Tiles above the map count who is on duty, out delivering, at the counter and without GPS or data. A card beside the map shows every rider's mobile number, deliveries today, the orders out with them and when they last reported; click a card to zoom to that rider.

📡 No GPS or data warning. A rider who is out with orders but has not reported a position for three minutes gets a red pulsing marker and a warning on their card, so the manager knows the phone's GPS or mobile data is off before the customer calls.

🔄 Always in view. The map refreshes every 20 seconds and fits itself around the riders at street level. Pan or zoom by hand and it stops following; the Follow riders switch puts it back. A Refresh map button reloads the positions in place.

🔁 Refresh stays on the tab. Refreshing the browser on any Rider Hub tab used to send you to the dashboard. It now reopens the same tab.

On restaurants that track riders through the ERP (no Firebase project of their own) the customer's tracking page and the Riders Now list trailed the rider by about a minute: the server accepted one position per rider every 60 seconds, so the phone reported once a minute.

📍 Now: the server accepts a position every 20 seconds and the customer's page checks every 10 seconds while the order is on its way, so the map moves within 20 to 30 seconds of the rider. Together with rider app v1.0.13, which sends its first position the moment an order is picked up, the rider appears on the map right after the pick-up rather than one interval later.

Between 8 and 17 September, about 180 customers received an alert meant for the owners, such as a cancelled order, because a trailing comma in a branch's owner number list was read as no number at all.

📣 Now: Owner and branch numbers are read fresh each time, with blanks and duplicates dropped • An alert with no owner number is not sent to the customer; it is skipped and noted in the log • Each notification template has two WhatsApp switches: one for the owner and branch numbers, one for the customer

🧭 Defaults: Internal alerts such as void-order notices go to the owners and not the customer • Customer messages keep their own switch and do not reach the owners • The void-order alert sits on its own Internal Team Notifications card on the templates page

Result: Owner alerts stay with the owners, and each switch does one job.

When a customer paid an ordering platform with loyalty points or platform wallet money, the books came out short by that amount, and the gap landed on Rounding Loss.

📒 Now: Loyalty points are posted as a sales discount • Wallet money is posted to the platform's receivable, the same account as the bill itself • A one-time repair rebuilds the past orders whose gap sat on Rounding Loss; in one restaurant the gap ran past Rs 100,000

💵 Also: A payment no longer fails at the till when the whole-rupee round-off leaves a fraction of a paisa

Result: The books match the bill, and nothing lands on Rounding Loss.

A restaurant that does not track its riders saw a red No GPS or data warning on every rider out on the live map, though nothing was wrong with any signal.

🗺️ Now: The warning appears only when rider tracking is switched on and no fresh position has arrived • A restaurant without tracking sees its riders out with their orders and no red warning

Result: A red warning now means a real signal problem.

An order the rider recorded as paid by JazzCash, card or another wallet at the door used to fall between the cracks: it was not cash, so it never entered a hand-in, the counter never billed it, and the app kept showing it as CASH.

💳 In the app: the Cash screen now shows the cash the rider actually hands over, with each other tender listed beneath it (JazzCash Rs 1,299 · 1 order). The hand-in request carries every unsettled order, split by tender, and the order card shows JAZZCASH or CARD instead of CASH until the counter bills it.

🧾 At the counter: the Rider Hand-ins modal and the Rider page show the split under the amount and one Settle button per tender — Settle · Cash, Settle · JazzCash — each opening the usual bulk payment on that group's orders so the cashier picks the matching payment method. Requests with cash only look exactly as before.

Four fixes from the rider app review.

⭐ Points: the Rider Points tab said OFF while Business Settings showed the switch on — the checkbox value was read too strictly. Fixed.

📍 Address edits: riders could rewrite a customer's address with no restaurant-level control. A new role permission rider_edit_address (off by default) now gates it, and every change is logged on the order as a rider remark — who, when, from what, to what.

🔒 Settled prices: without the hand-in history permission, delivered orders the counter has already settled show no amounts in the app, so a rider can no longer add up the day's collection.

🏁 Rider entry: a hand-in request or a check-out from the app now marks the rider's deliveries as entered, so the Delivery grid and the speed reports stop saying "Not entered".

Every order template under Options → Notification Templates now lists {tracking_link}, {delivery_code}, {delivery_address}, {rider_name} and {rider_mobile} — Order Placed, Order Handover, Order Delivered and the rest, Meta templates included.

🔑 One code per order: • The delivery code is made the first time any template asks for it and stays the same until the rider verifies it at the door • The rider's Send code sends that same code • A template that never mentions the code makes none.

🗺️ Tracking link: • Filled only for delivery orders while the restaurant's Customer tracking link switch is on; empty otherwise.

Result: Put the code and the link straight into the Order Placed message — no rider action needed.

The rider app's customer tracking link used to stay readable for three hours after delivery. It now closes the moment the order is delivered: the page says Delivered, shows no map, no rider and no position, and stops refreshing.

🔒 Security tightened: • An expired or cancelled link no longer reveals the customer's pin • The link never reaches the map tile server or a search engine • Both tracking routes are rate-limited.

Result: A forwarded link shows the trip while it is on its way, and nothing once it is over.

With Hide print button to rider switched on in Business Settings, the Rider App still showed Print invoice on every order — the switch was checked only when the rider tapped it, and the tap ended in an error.

🖨️ Now: • The switch is part of what the app is told the rider may do • The Print button disappears from the order card and the order screen • Flip the switch and the app follows on its next refresh, no sign-out needed

Result: A restaurant that hides printing from riders hides it in the app too.

The tracking link sent to a customer in a delivery message went to an address the customer could not open.

📍 Now: The link carries the full restaurant address the customer can open • A link that already uses a full custom domain is left as it is

🔐 Delivery code: When the messaging service refuses a code message, no code is left behind • The customer's next check then reports that the code was not sent, not that it was wrong

Result: The customer can open the tracking page from the message.