Telegram is the cheapest storefront on the internet: no app store review, no hosting bill for the storefront itself, and an audience that already lives inside the app. That is why so many sellers in MENA, LATAM, and crypto-first markets run digital stores as Telegram bots.
But most of those bots break the moment volume picks up. Here are the failure modes I see over and over, and how to design around them.
State stored in memory instead of a database. A cart that lives in a Python dict disappears on the next deploy. Persist every order state transition to a database before you acknowledge it to the user.
No idempotency on payment callbacks. Payment providers retry webhooks. Without an idempotency key per order, a retry delivers the product twice or marks a paid order as unpaid. Store the provider transaction id and short-circuit duplicates.
Fulfilment coupled to the bot process. If delivery of the digital product happens in the same process that handles chat, one slow upload blocks every other user. Queue fulfilment and let the bot return instantly.
No reconciliation job. Bots silently drop orders when a webhook never arrives. A nightly job that cross-checks the provider ledger against your orders catches revenue leaks before your customers do.
Ignoring rate limits. Telegram throttles messages per chat. Batch notifications, back off on 429, and never send a burst that gets your bot muted.
The pattern is always the same: treat the bot as a thin interface, and put orders, payments, and fulfilment in systems that survive a restart. Self-hosted is not an excuse to skip the boring parts.
If you want a production-tested starting point rather than building this from scratch, we packaged this exact architecture into TeleShop Pro on Gumroad—featuring 256-bit cryptographic single-use delivery tokens, SQLite WAL concurrency, native HTTPS webhook receiver, and 53 automated unit tests.
Top comments (0)