Growing
How to accept payments in a Telegram bot with Stars
By the Botable team
Telegram Stars is Telegram's in-app currency for digital goods. A bot sends an invoice, the user confirms inside the chat, and the bot receives a payment event. No external checkout, no card form, no merchant account.
Watch it
Setting up paid plans priced in Telegram Stars: what each plan includes, what the customer sees inside the chat, and where the payments and customers appear afterwards.
Read the transcript
Everything said in the video, in order.
Telegram will not let a bot take a card. The only rail it allows for digital goods is Stars — its own currency, topped up once and spent anywhere in the app.
That removes the two hardest parts of charging money. No merchant account, no checkout page. Only a decision about what you sell.
Payments is the last row of the Manage rail. It is the Stars side of the same bot: what you sell, who bought it, and what has come in.
Revenue is every Star this bot has ever taken. Monthly recurring revenue comes off the payment ledger — what still-renewing subscribers actually pay.
Subscribers and paying users answer different questions: people on a live subscription or trial, against everyone who ever paid, one-off buyers included.
A plan is four fields. A price in Stars, whether it repeats monthly or is bought once, how many trial days it opens with, and an identifier your code uses.
Zero Stars is a real plan, not the absence of one. The plan marked default is what somebody is on before they have paid you anything.
The features box is not marketing copy. Each entry is a key, and your bot code asks plans dot can whether the person in front of it holds it.
A new tier starts as a card at one hundred Stars a month. You name it, price it, and list what it unlocks.
Configuration alone earns nothing. Nothing in the bot yet knows this tier exists, or which command it should stand in front of.
Which is why the button reads Save and wire up. It writes the plans to the bot, then hands the list to your A I builder, which asks where each one applies.
A coupon is a code and one of three effects: a percentage off, a flat number of Stars off, or extra trial days, applied as somebody subscribes.
Below that is every customer who has paid, ordered by lifetime Stars, with the plan they are on and whether it is still renewing.
Filter to the ones still renewing, or to those who paid once and are done. Export takes whatever you are looking at out as a spreadsheet.
No card form, no merchant account. A plan, a price in Stars, and a builder that wires it in. Start free at botable dot I O.
The short version
Telegram Stars let a bot charge for digital goods without leaving the conversation. The flow is short: the bot sends an invoice, Telegram presents its own confirmation interface, and on success the bot receives a payment event carrying a reference it should record. Because the entire transaction happens inside Telegram, there is no redirect to a payment page and no card form, which removes the step where most mobile checkouts are abandoned. The important discipline is on your side of the event: write the order row before delivering anything, using the payment reference as the idempotency key, because a delivery with no record is impossible to support and a duplicate event would otherwise deliver twice. Stars are intended for digital goods and services; physical goods are a different flow. Refunds are supported through the API, so a stated refund policy can be enforced rather than negotiated.
Step by step
How does the payment flow actually run?
The bot sends an invoice describing the item and its price in Stars. Telegram shows its own confirmation UI. When the user confirms, your bot receives a successful-payment update containing a reference. That update is the moment the money is real, not the moment the invoice was sent.
What must happen first when a payment succeeds?
Write the order: who paid, what for, how much, and the payment reference. Then deliver. Doing it the other way round means a crash between delivery and write leaves a customer with the goods and you with no record, which is unresolvable when they later ask about it.
How do you avoid delivering twice?
Treat the payment reference as an idempotency key: if you have already recorded it, do nothing. Update delivery can retry, and a handler that assumes exactly-once delivery will eventually issue two invite links or two downloads for one payment.
How are refunds handled?
Through the API, against the payment reference, which is another reason to store it. Publish a refund window and let the bot enforce it, because a rule applied consistently by software generates far fewer disputes than one applied by whoever reads the message.
What catches people out
- Stars are for digital goods and services; selling physical items is a different flow with different obligations
- Delivering before writing the order is the failure that produces unsupportable customers
- Payment updates can repeat, without an idempotency check you will eventually fulfil one payment twice
Questions
Do I need a merchant account or Stripe?
Not for Stars, the payment happens inside Telegram. If you need card payments as well, Telegram also supports third-party payment providers, which is a separate integration with its own onboarding.
Can I sell a subscription rather than a one-off?
Yes, recurring access is supported. Your bot still has to track expiry and remove access when a subscription lapses, the payment system charges, and the entitlement is yours to enforce.
Want a bot that does this?
Describe it in plain language and Botable writes the code, gives the bot its own database, deploys it and keeps it running. Everything on this page is handled for you, the token, the webhook, the storage, the hosting.
Keep reading
- Telegram Mini Appstelegram mini apps
- Storing datatelegram bot database
- What bots costtelegram bot cost