Telegram Stars or a custom system?
Telegram can do subscriptions, built in. The question is what it cannot do — and whether that matters to you.
People planning a paid Telegram channel often start by looking for someone to build the access system for them. Frequently there is no need: Telegram has subscriptions built in. A bot can create an invite link that charges a recurring fee, and membership ends by itself if it is not renewed. This arrived with Bot API 7.9, in August 2024.
The fee is charged in Telegram Stars — Telegram's own in-app currency, which the user buys through an app store. This article goes through when that is enough, and where the point comes at which a custom payment system is needed instead. The technical handling of access — invites, expiry, removal — is covered in a separate article; here the subject is the decision, not the implementation.
When the built-in one is enough
The built-in subscription does what it was designed for: charging a recurring fee for content, on one channel, at one price. If that is the situation, a custom system is an unnecessary cost.
- There is one channel with one package — no tiers, no annual discount.
- The audience is international, or made up of individuals who do not need an itemised invoice.
- Nothing has to be connected: no website to pay on, no CRM, no database of your own.
- You are just starting, and want to find out whether anyone pays at all. For that the built-in one is the fastest route — no development, no lead time.
When it is not enough
There are four situations where the built-in solution hits a wall. None of them is theoretical — each tends to come up in the first months.
When itemised invoices are required
With Stars you are not paid directly by the buyer. The buyer purchases Stars from Telegram, spends them with you, and the revenue reaches you from Telegram. That is a different flow of money from a card payment made to you. What it means for invoicing in your own tax setup is a question for your accountant — but the difference is worth clarifying before the first subscriber joins.
When you need multiple tiers or custom rules
Several subscription invite links can be created, so tiers can be set up. What is harder: switching between tiers, temporary discounts, trial periods, and the one-off exception for the handful of customers you agreed something else with. These are rules that have to be stored and enforced somewhere — and the built-in solution has no room for them.
When payment happens somewhere other than access
Often the customer pays on your website, and Telegram is only one of the places they get access to — alongside an email sequence, a downloadable file, perhaps a members' area. In that case the natural home of payment is your own system, and Telegram is one output among several. The built-in subscription cannot do this: there, Telegram is also the place of payment.
When the revenue turns into volume
Stars are bought by the user through an app store, so the store's commission is deducted before the money reaches you. With your own payment provider, only the provider's fee comes off. At low volume this difference is not interesting; as the membership grows, it increasingly is.
If you are planning a paid channel and it is not obvious which route is yours, send an email: how many tiers there will be, whether invoices are needed, and where the customer would pay. Those three usually settle it — and if the built-in one is enough, I will say so.
kristof@kristofkarner.comFrom here on: what the difference between the two routes looks like in practice — what you get with the built-in one, and what has to be built in the other case.
What the built-in gives, and what has to be built
With the built-in subscription, Telegram handles collecting the fee, renewal and expiry: if someone does not renew, membership ends by itself. In exchange, the rules are Telegram's rules — the price is in Stars, the money arrives from there, and there is no way into the process.
With a custom system you build the same thing yourself: a provider handles the payment, your system receives its events, and from there access expires or renews according to your logic. That is more work, and there are a few traps in it. In exchange, payment happens between you and your customer, invoicing runs on your own system, and you can have as many packages as you want.
In practice the two do not exclude each other: some start with the built-in one, measure whether there is demand, and only build a custom system when invoicing or tier structure demands it. That is a defensible order — the one thing worth knowing up front is that the move is not free: existing subscribers have to be migrated to the new payment route, and while the old ones keep paying through Telegram, two systems run side by side for a while.
What does a custom system look like live? Among my projects, the case study connecting Stripe subscriptions with Telegram access is the closest to this: there, payment, the Hungarian invoice and admission all run in one system. The technical side of invoicing is covered in a separate article.
Questions on the subject
Can you issue a proper invoice for revenue that comes from Telegram Stars?
The invoicing and tax side is for your accountant, not for this article. The technical difference matters to that conversation though: with Stars you are not paid directly by the buyer. The buyer purchases Stars from Telegram, spends them with you, and the revenue reaches you from Telegram. Anyone who needs an itemised, buyer-addressed invoice for every subscription should go through what that means in their own tax setup before the first subscriber joins.
How much less is left from Stars than from direct payment?
A specific figure is not worth writing down, because it changes. The structure is: Stars are bought by the user through an app store, so the store's commission is deducted before the revenue ever reaches you. With your own payment provider, only the provider's fee comes off. The gap between the two is not negligible, and it grows with volume.
Can multiple tiers be handled with the built-in subscription?
Several subscription invite links can be created, so tiers can be set up. What is harder: switching between tiers, temporary discounts, trial periods and one-off exceptions. Those are rules that have to be stored and enforced somewhere — the built-in solution offers no place for them, a custom system does.
If I start with the built-in one, can I move to a custom system later?
You can, but the move is not free: existing subscribers have to be migrated to the new payment route, and while the old ones keep paying through Telegram, two systems run in parallel for a while. So it is worth thinking through at the start whether invoicing or tier structure will force a custom system eventually anyway.