Get paid in Telegram Stars,
wired into what your bot already does

Why skip the checkout redirect

Telegram Stars is Telegram’s own in-app currency for paying inside a bot or Mini App. It runs on the Bot API’s invoice and payment flow. A user buys Stars once, through Telegram itself, then spends them inside any bot that accepts them. That removes the usual friction of sending someone to an outside payment page.

Calling sendInvoice is the easy part. Building this well means more. The pre-checkout step has to check that what the user is buying is still in stock and still priced right. The successful-payment event has to actually deliver what was promised, a digital good, an access grant, a subscription period. It cannot just log that money arrived and leave the rest to a human.

When Stars fits, and when it does not

You need this if your product already lives inside Telegram: a bot-based store, a game club, a content subscription, a paid feature in a Mini App. You want a payment method that never leaves the chat. It is a strong fit for digital goods, since delivery can happen in the same message thread as the purchase. It also works well for audiences who find card payments awkward, since Telegram’s own currency skips that step.

You do not need Stars if your audience is not mostly on Telegram. You also do not need it if your product needs something Stars cannot cover, like physical goods with shipping or a true multi-currency B2B invoice. Those cases need a standard payment gateway instead. That gateway can run alongside Stars rather than replacing it, for the parts of your business Stars was never meant to handle.

How the invoice, check and delivery line up

The bot, aiogram in Python or Telegraf in Node and TypeScript, matching your existing stack, creates an invoice for the specific product. That invoice carries the price in Stars and the metadata needed to fulfill the order later.

The pre-checkout handler runs just before payment is taken. This is where we check anything that could have changed since the invoice was created: stock, price, whether the user is still eligible. Only after Telegram confirms the payment does the successful-payment handler run. That handler is wired straight into your delivery logic. It opens up content, sends a digital key, or extends a subscription. The charge and the product it paid for happen in one transaction path, not two systems that can drift apart over time.

Every invoice, payment and refund gets logged with enough detail to reconcile later. Admins get a notification on each purchase, so support can see what happened without digging through bot logs by hand.

Where Stars has real limits

Stars are Telegram-specific. There is no way to accept them outside the platform. Payouts from Stars back to real currency go through Telegram’s own revenue-sharing terms, not a bank transfer you control directly. That is worth knowing before you base a whole revenue model on them.

Running cost is close to zero beyond normal bot hosting, since there is no separate gateway fee on your side. The main ownership risk is treating pre-checkout as optional. Skipping it is how bots end up selling items that are already out of stock, or honoring a price that already changed underneath the buyer.

Price and timeline

Related

This pairs well with subscription billing with dunning if Stars are funding a recurring subscription. It also pairs with crypto payments acceptance for stores that sell outside Telegram too and want both rails. It is part of the development service. The delivery and catalogue logic here matches the instant-delivery marketplace engine case study.

Ready to add Stars to your bot’s actual purchase flow? Get in touch and send us how your bot sells today.