Telegram Mini App shop
The catalogue, the cart and the payment all sit inside the messenger. The customer installs nothing, and the order lands in the same chat.
- Buildfrom $1,450
- Timeline3–6 weeks
- Supportfrom $420/mo
Who this suits: Selling that already happens in a chat, where the order is assembled in messages, the price is confirmed by hand and carts are lost along the way.
What is in the first version
- catalogue with search
- cart and delivery
- in-chat payment
- order screen
The figures above are the package this sits on: Telegram Mini App. Anything past its edges the calculator adds before the work starts, not after.
How the path goes
- 01
The shop opens from a chat
No install and no registration: the person is already signed in, and the shop knows who opened it.
- 02
The cart is priced server-side
Price, discount and delivery are read from the catalogue at checkout, so the server names the amount, not the cart.
- 03
Payment and the order stay in-chat
The invoice is issued inside the messenger, and the confirmation and every status arrive in that same chat.
What decides whether this works or annoys people
The mini app cannot be trusted
The messenger’s signature on the user data is verified on every request, and the total is recomputed from the catalogue.
Digital and physical pay differently
Physical goods use an ordinary provider and digital goods the platform’s own mechanism, so which you sell is settled before the build.
It is somebody else’s window
A swipe closes checkout, so the cart survives a close, an unfinished order asks before exit, and the dark theme is tested too.
What to measure once it is live
- orders placed without messaging anyone
- time from opening to payment
- share of carts abandoned
- repeat orders from the same chat
Why this comes out faster
The shape of this one is known: the states, the edge cases and the things that usually go wrong have been decided before. Nothing here is a template, and the saving is not in your half of the work. It goes into your process, your content and the systems this has to talk to, which is the part nobody can have solved in advance.
A likely stack for this
Picked against the task when we scope it, not decided in advance. This is the shelf it usually comes off.
- Mini appTypeScriptReactNext.js
- Bot, server and dataNode.jsTelegram Bot APIPostgreSQLPrismaRedis
- Payments and operationsStripePaddleDockerGrafana
Price it yourself, right here
Five steps, and you can see the number without leaving a contact. The estimate accounts for the kind of work, what you already have and what it will need inside.
These bills do not come from us
- payment fees and the platform’s share
- hosting or a VPS for the shop
- a domain and certificate for the mini app
- the till and fiscal receipts
Asked before the first call
- Why this, if we already have a site?
- The audience is already there and signed in, so the path from post to payment loses a registration and a browser jump. In exchange the shop is not indexed and works on your existing traffic.
- How do we take the money, and where does it land?
- Through a payment provider connected to your bot and your account: the money goes to you directly and never passes through us. The contract is yours, and so are the refunds.
- Where does the catalogue come from if the goods sit in 1C?
- From whichever system is already the truth about items and stock, agreed before the build. A second catalogue kept by hand diverges within a week, and the customer who paid finds out first.