Telegram Stars in a Bot: How to Accept Them

Stars appeared as a way to pay for digital goods inside the messenger, and for some categories they are not an alternative but a platform requirement.

What they are

An internal currency: users buy Stars with real money and spend them inside the messenger. For you that means taking payment without connecting an external payment provider.

The key difference from ordinary payments: the platform itself is the intermediary. Both the advantages and the constraints follow from that.

When you need them

Mandatory for some digital goods and services consumed inside the messenger. Platform rules require this method, and working around it leads to the bot being blocked. Exactly what falls into that category should be checked against current rules: the wording has changed over time.

Convenient when you would rather not connect a payment provider and the amounts are small. Connecting a provider requires a legal entity and a contract; Stars do not.

Not suitable for physical goods and services outside the messenger. Those use ordinary payments.

How acceptance works

The flow matches ordinary payments, and so does the order of steps:

1. Create the order in your database with a pending status.
2. Issue a Stars invoice carrying the order identifier.
3. Wait for confirmation from the platform. A button press is not payment.
4. Check the order is not already paid. Skipping this is what causes double delivery.
5. Mark it paid and deliver.
6. Tell the user.

The idempotency requirement is exactly the same: a repeated confirmation must not deliver twice. The long version is in taking payments and on the blog: idempotent pipelines.

Differences from ordinary payments

No provider needed. No contract, legal entity or onboarding. The barrier to entry is much lower.

One currency. Prices are set in Stars rather than in local money. That affects pricing: rounding in Stars is coarser and a tidy price is not always achievable.

Payout and accounting follow platform rules. How money reaches you and what reporting exists is a question to settle before selling, not after the first month.

Refunds. The mechanics differ from provider refunds. Understand in advance what happens to delivered access when a refund occurs.

What to account for

• Rules change. The categories requiring Stars have been revised more than once. Check the current version before launch.
• Pricing. Converting from a familiar currency into Stars gives awkward numbers. Setting the price in Stars directly is simpler.
• Fees. The final amount differs from the sticker price. Model the economics on what you receive, not on the button.
• Testing. Run the full cycle, including a refund, before opening sales.
• Payment event logs. Resolving a dispute needs history, not memory.

An overview of every payment option: payments in a bot. What this looks like on a real project: a course sales bot. The overview is in the Telegram bots guide.