Why your menu prices on the delivery app differ from the ones you set

The price a customer pays is held by a different system on every delivery app, and restaurant operators are often editing a copy rather than the original. DoorDash warns that Merchant Portal edits on an integrated store “are not permanent”. Careem quotes seven working days and holds an amended item in “Pending approval”. Wolt writes the menu for you and blocks direct edits once a point of sale is linked. Deliveroo changes nothing at all until somebody presses Publish. Four different owners, four different answers to one question.

Where does the price a delivery app customer sees actually live?

Not, on most platforms, in the field the operator just typed into. The authoritative copy sits somewhere further along, and the merchant tool is a request form pointed at it.

Two rows in that table describe a restaurant that cannot change its own price at all. Careem states that “Changes to the catalog cannot be made because this is a POS integrated outlet.” Wolt states that “If your Wolt menu is linked to a POS system, direct edits through the menu editor aren’t possible”, having already said that “Your menu will be created for you by our experienced menu specialists during the onboarding process”. On both platforms the person who typed the wrong price and the person who can correct it work for different companies.

The menu prices on the delivery app are different from the ones we set. Which price wins?

The price a customer pays is the one held in the platform’s own system, not the one in your point of sale or your printed menu, and that is true even when the two disagree because of something the platform did. Some platforms state this in the contract in as many words, and at least one adds that the restaurant carries any cost difference. So the answer to which price wins is always the platform’s, and the useful question is why the two diverged.

Why does a saved price never reach the customer?

Because saving and publishing are two actions on at least four of these platforms, and only one of them is visible to a customer. Deliveroo’s own help article says it directly: “Don’t forget to ‘Publish’ your menu if you want your saved changes to go-live for your customers to see”. Pyszne.pl instructs partners to save with “Zapisz” and then publish, adding that the updated menu is active immediately once they do. Bolt Food raises a banner reading “Your menu was changed! To have these changes visible to your customers, please, don’t forget to publish the menu.”

The portal keeps showing the new price to whoever saved it, which is why this failure survives internal checks. Someone at head office opens the tool, sees the corrected number and closes the tab. Nothing in that sequence touches the storefront.

Just Eat publishes the most candid version of this problem in the industry. Its menu ingest API states that “our platform only checks if the menu structure is valid. However, a valid menu may still fail to publish on the corresponding delivery partner platform. Currently, this endpoint does not indicate whether the publish operation was successful.” Source: uk.api.just-eat.io. A push can be structurally perfect, accepted, and never arrive, with no error raised anywhere in the chain.

Talabat behaves the same way for a different reason. Its Partner API accepts a price update asynchronously, returns a job identifier, and reports failures item by item afterwards rather than rejecting the request, so success at submission says nothing about the shelf.

How long can a wrong price on a delivery app stay live?

Anywhere from minutes to a week, and the range is the story. Uber Eats applies an edit immediately. HungerStation quotes up to fifteen minutes for a catalog change. DoorDash routes an integrated store’s change through the till and quotes roughly a day. Jahez does not move until its overnight sync, which Foodics documents as “an enabled auto sync everyday at 3 AM, If a manual sync is required please contact your Jahez Account Manager”. Careem quotes seven working days.

Two of those numbers change what a promotional calendar can promise. A price corrected at four in the afternoon is live on Uber Eats for dinner service, on Jahez the next morning, and on Careem the following week. One price change across a Gulf estate therefore produces days in which the same dish costs different amounts on different apps in the same street, and no merchant portal reports that as a discrepancy, because each one is reporting the change it received.

HungerStation adds a second clock inside itself. Assortment changes sync in up to fifteen minutes while a promotion takes up to fifty, so a base price and its discount land at different moments and the app shows a combination nobody configured in the gap between them.

Which delivery apps require your app price to match your restaurant price?

Four publish a rule, and the penalties are not comparable. Glovo binds the partner to a “Parity Model”, warranting that products “will not be offered to GLOVO users at higher prices than those offered by the PARTNER on its own platform”, and states that on breach “GLOVO shall be entitled to charge the PARTNER an additional 10% based on the total amount of gross sales”. Source: glovoapp.com. That is a revenue penalty rather than a warning.

Bolt Food widens the comparison beyond the restaurant’s own channels. Its restaurant terms state that meal prices “may not be more expensive than the same Meal would cost on the Restaurant Operator’s internal channels or any Bolt Food Platform’s competitor platform”. Read literally, a chain’s price on Bolt is constrained by its price on a rival app, which makes cross platform price consistency a compliance question rather than a merchandising preference.

Careem states a consequence rather than a formula: prices “found to be higher than your own menu or other delivery platforms could lead to removal from the Careem platform”. Uber Eats turns it into a score instead, storing an in_store_price beside the delivery price and running a menu markup metric against it.

Why does one menu item carry several different prices?

Because several of these platforms model the item, not the number. Keeta stores three prices on every item, documented as price, pickPrice and canteenPrice, for delivery, pickup and dine in. Uber Eats stores four on the same object: price, core_price, in_store_price and in_store_discounted_price, and all of them are integers “because the price is set in the percent of local currency denomination”, which is how a price occasionally lands at a hundredth of the intended value. Deliveroo runs separate delivery and pickup prices as well.

So “the price is wrong” is an incomplete report until somebody says which price, on which fulfilment method. A branch that is right on delivery and wrong on pickup passes any check that opens only one of the two.

How would anyone find out that a price is wrong?

Not from the portal, which shows the number submitted rather than the number on sale, and not from the order feed, which shows only what people still bought. The mismatch is visible from one place, the storefront a customer opens, on that platform, at that moment, with the store open enough to be showing prices at all. Because the authoritative copy sits with a different owner on every app in the table above, the only comparison that settles an argument is a dated shelf price against the intended one, which is what Kitchain (kitchain.co) captures item by item. The wider practice is set out at menu price monitoring across platforms.