Building for Telegram Web Apps: a storefront that lives inside the messenger
In Uzbekistan Telegram is not a secondary channel but the primary one. A Web App puts a full storefront inside the chat with nothing to install.
What a TWA is technically
A Telegram Web App is your web page opened in the messenger's embedded browser with access to window.Telegram.WebApp. Through it the page reads user data and theme, drives the main button and closes itself.
It launches from a bot menu button, an inline button under a message, or a keyboard button. On the development side it is an ordinary React or Next.js frontend deployed over HTTPS.
The key difference from a website is context. The user is already authenticated, you have their id and name, and neither registration nor a phone number is needed at step one.
Authentication and verifying initData
Telegram passes an initData string of user parameters plus a hash field. Never trust it client-side: anyone can open the URL directly and substitute another id.
Verification happens only on the server: sort parameters alphabetically, join them with newlines, compute HMAC-SHA256 with a key derived from the bot token, and compare with the supplied hash.
Always check auth_date and reject initData older than, say, 24 hours; otherwise an intercepted string works forever. After a successful check, issue your own session instead of passing initData with every request.
Interface: how a TWA differs from a mobile site
Do not draw your own bottom 'Place order' button — use the API's MainButton: it is native, always positioned correctly and aware of the keyboard. Back navigation is also system-level via BackButton.
Take colours from themeParams: a user on Telegram's dark theme expects a dark storefront. A hardcoded white background inside a dark client reads as a foreign insert and erodes trust.
Respect safe areas and viewport height from the API rather than CSS: collapsed and expanded window states differ, and fixed elements otherwise cover content on iPhone.
Payment and taking the order
Two paths exist: Telegram's built-in payments via a bot invoice, or your own flow through Payme, Click or Uzum. Locally the second is usually more appropriate because users look for familiar bank buttons.
Returning from a payment gateway inside an embedded browser is fragile. It is more reliable to close the Web App once payment starts and deliver the status as a bot message, right where the user already is.
sendData can hand the bot a compact JSON result, but the payload is limited and arrives as a service message. For orders, write directly to your backend and keep sendData for simple choices.
When a TWA beats a site or an app
TWA wins where the audience already lives in Telegram: food delivery, service booking, quick-order catalogues, loyalty programmes, internal staff tools. No install, no app store, no registration.
A further advantage is server-side updates: you deploy and every user has the new version immediately, with no store release or review wait.
The limits are real too: no proper offline mode, restricted access to device capabilities, and total dependence on platform policy. For a daily-use product built on push notifications, that can be decisive.
Development practice and budget
Test in real clients on Android and iOS: the embedded browsers behave differently, especially around keyboards, scrolling and fixed panels. Desktop Telegram is a third distinct case.
Keep the bundle light: TWAs open over mobile data, and the 3G rules apply unchanged. Static generation and preloading the first screen make a perceptible difference.
Pricing guidance: a simple catalogue storefront with a cart from 15,000,000 UZS; a version with accounts, payments and accounting-system integration from 30,000,000 UZS. An existing site is partly reusable, but the interface must be built separately.