Bot type
Sell direct in Telegram instead of renting your customers back
A Telegram ordering bot takes a full order — menu, modifiers, address, payment — inside the chat and prints a ticket to your kitchen. It exists to move repeat customers off aggregator platforms that charge 20 to 30 per cent per order. It will not win you new customers on its own.
Restaurant ordering bots: price, timeline and limits
- Fixed price
- $4,600 USD
- Delivery
- 21 calendar days from kickoff
- Payment model
- Telegram Payments hands off to your own merchant provider
- Telegram Stars
- Digital goods only — cannot sell physical food
- Mini App auth
- initData HMAC-SHA256 validated server-side against the bot token
- Location data
- Coordinates only, not a validated street address
As of 2025-10-01, Telegram Bot API 13.4
The problem this solves
The arithmetic that drives this build is brutal and well understood by every operator in Dubai. An aggregator takes somewhere between twenty and thirty per cent of the order value, and on a business running eight per cent net margin that is not a marketing cost, it is the entire profit and then some. Operators tolerate it because the aggregator brings customers they would not otherwise reach.
The part that is worth attacking is the repeat order. A customer who has eaten your food four times does not need discovering again — they already know what they want, and they are being routed through a twenty-five per cent toll to get it. Moving that specific segment direct is where the money is, and it is a much smaller problem than building a delivery business.
Telegram works for this because there is nothing to install. A QR code on the packaging opens a chat, the previous order is already there, and reordering is two taps. Compare that to persuading someone to download a single-restaurant app, which almost nobody does twice. The bot is not competing with the aggregator on discovery. It is competing on the second, fifth and twentieth order, where discovery is already paid for.
How the build runs
A QR code on the packaging opens the bot
Printed on the bag, the receipt or a card in the box. The deep link identifies which outlet the customer ordered from, so a multi-branch operation routes the next order to the right kitchen without asking.
deep-linkThe menu renders as a Mini App, not a wall of buttons
A menu with forty items and modifiers is unusable as inline keyboards. It opens as a Telegram Mini App — a real interface with images and a basket — that still lives inside the chat and needs no install.
mini-appAddress capture checks the delivery zone before taking money
The customer shares a location or types an address, the bot checks it against your zones, and tells them immediately if they are outside one. Taking payment and then discovering you cannot deliver is the single worst outcome in this flow.
reply-keyboardPayment settles through a provider that actually works in the UAE
Telegram Payments routes to a provider you hold a merchant account with. Which providers are available to a UAE entity is a real constraint and is worked out before the build starts, not discovered during it.
payments-apiThe kitchen gets a ticket and the customer gets a state
The order prints or appears on the kitchen tablet the moment payment clears. The customer sees accepted, preparing, out for delivery — updated by staff with one tap, because anything more elaborate does not get used during service.
webhookReordering skips everything above
A returning customer sees their last three orders and can repeat one, with the saved address and payment method. This is the flow the entire build exists for, and it is the one worth optimising to the second.
inline-keyboard
What Telegram will and will not let you do
Telegram Payments does not process money itself; it hands off to a payment provider you have a merchant account with.
Your available providers depend on your jurisdiction and entity. A UAE restaurant and a Cyprus one have materially different options, and this is settled before the build rather than during it.
Telegram Stars cannot be used to sell physical goods.
Stars are for digital goods and services. Selling food through them is against Telegram policy and risks the bot, so food orders always route through a real payment provider or cash.
A Mini App receives an `initData` string that must be HMAC-validated server-side against the bot token.
Without that check, anyone can post a fabricated basket to your order endpoint. It is a dozen lines and it is the difference between a menu and an open till.
A bot may send about 30 messages per second overall.
During a Friday evening rush with three hundred concurrent orders, status updates are paced rather than instant. It is not a problem at restaurant scale, but it does mean status is eventually consistent.
Location sharing gives coordinates, not a validated street address.
Zone checking is geometry against coordinates, which is reliable. Handing a driver a usable address in a city where building names matter more than street numbers still needs a text field, and pretending otherwise produces failed deliveries.
When not to build this
- You do not yet have repeat customers. This build monetises loyalty you already have; it does not create it, and an ordering bot with no returning customers is an expensive menu.
- You have no delivery capability of your own and no intention of building one. Taking orders you cannot fulfil without the aggregator solves nothing.
- Your average order value is under about fifteen dollars and volume is low. The payment provider fees and the build cost do not recover against the aggregator commission you avoid.
- Your menu changes daily and nobody will maintain it. A stale menu produces refunds and complaints, and is worse than no bot at all.
What it runs on
| Component | Version | Why |
|---|---|---|
| grammY | 1.45 | Bot framework, webhook mode, with the Mini App served alongside. |
| Cloudflare Workers | current | Runtime, sized for burst load during service hours. |
| Cloudflare D1 | current | Menu, orders, addresses and zone geometry. |
| Telegram Mini Apps | Bot API 9.x | The menu and basket interface, with initData validated server-side. |
| TypeScript | 5.9 | Strict mode. Money arithmetic in an untyped codebase is not worth the saving. |
Questions people ask before committing
How much of the aggregator commission does this actually save?
All of it, on the orders that move. The honest framing is that only a share of your customers will move — typically the frequent ones — so the saving is the aggregator commission on that segment minus payment provider fees of two to three per cent. Model it on your own repeat rate before committing.
Which payment providers work for a UAE restaurant?
Telr, PayTabs and Network International are the ones most UAE food businesses end up with, and Stripe is available depending on entity and category. What you can use depends on your licence and merchant account, which is checked at scoping rather than assumed.
Can customers pay cash on delivery?
Yes, and in much of the GCC you should offer it. Cash orders skip the payment step and go straight to the kitchen ticket with a flag, and the driver reconciles as they already do.
Does the kitchen need new hardware?
Not necessarily. Orders can print to an existing thermal printer over the network, or appear on any tablet with a browser. Which is better depends on how your line already works, and it is worth deciding before the build rather than after.
What happens if the payment succeeds but the order fails to reach the kitchen?
The order is written to the database before payment is confirmed to the customer, and kitchen delivery is retried with an alert to a manager if it does not land. A paid order that nobody cooks is the failure this design exists to prevent.
Can we run several branches from one bot?
Yes. The deep link or the delivery address decides the outlet, each branch has its own menu availability and its own ticket destination, and reporting separates them. One bot with branch routing is simpler to operate than several bots.
How do we get existing customers into the bot in the first place?
Print the QR code on the packaging of orders that arrive through the aggregator. Those customers already like your food, and the code reaches them at the moment they are eating it. That single tactic does most of the work.