Paid Telegram access: joining, expiry and removal in practice
Granting access is easy — taking it back needs a system. This is the full lifecycle: invite, identification, expiry, removal, and the returning member.
Paid Telegram access has two very different jobs at its two ends. Letting someone in is simple: you send an invite. The harder question is what comes after — who is legitimately in, until when, and what should happen when that runs out. By hand this stays tractable up to a few dozen members; beyond that the record drifts, and the revenue with it.
Here I describe the full access lifecycle built on the Telegram Bot API, as I built and run such a system. The payment side — how a charge becomes an event — is taken as given.
- 01 payment
- 02 identification
- 03 single-use invite
- 04 membership
- 05 grace period
- 06 removal
the returning member re-enters the same loop
How does a payer get in?
With the Bot API a bot can create an invite link that is good for a single join and can carry an expiry. This is the foundation of paid access: every buyer gets their own, the link can't be passed on, and it can't be reused. A shared, reusable link has no place here — one leaked link opens the whole group.
There's a second route: the group can also work with join requests. The bot then approves or declines each request according to whether the applicant is among the payers. That's useful when the link might appear in a public place: on its own it lets nobody in. The two can be combined; in both cases the point is that entry is tied to payment, not to possession of a link. The bot needs appropriate administrator rights in the group for these operations — creating invites and removing members require them.
How do you link the payment to the Telegram account?
This is the least obvious point in the system. At the payment provider the buyer has an e-mail address; in Telegram they have a numeric identifier — and nothing connects the two by itself. If the system doesn't know which Telegram account belongs to which payment, it can reliably neither admit nor remove anyone.
The established pattern is the bot's start link. After payment the buyer receives a link that opens the bot and carries a unique code. When they start the conversation, the bot receives that code along with the buyer's numeric identifier. Payment and account are now linked, and the bot can send the personal invite. The code is single-use and expires, for the same reason the invite does.
What should happen at expiry?
Expiry isn't a single moment but a short process. A payment provider usually doesn't declare a failed renewal on the first try — it retries the charge, and that takes time. The grace period exists for that window: the member is still in, but the system already tells them the renewal failed and gives them a chance to sort it out. How long that period runs is a business decision, not a technical one; the system merely enforces it.
When the grace period also runs out, the bot removes the member. Here sits the Bot API's most insidious behaviour: removal is a permanent ban by default, which would also shut out a returning buyer. Handling it correctly takes two calls. The member should be notified of the removal too: access that vanishes without a word produces complaints, whereas a message beforehand produces renewals.
What about the returning member?
A returning buyer is a natural part of the lifecycle, not an exception. If the removal was done properly, the path back is the same as the first time: payment, identification, a new single-use invite. All the system has to do is not treat the return as an anomaly — which is exactly what a permanent ban would make it.
Questions on this topic
Should paid content live in a group or a channel?
In a channel only you post and members read — that suits a content service: analyses, alerts, news. In a group everyone writes, which suits a community. Access management works the same either way; the decision is about the product: are you selling content, or membership of a conversation.
What if somebody passes the invite on?
With a single-use invite there is nothing to pass on: the link is good for one join and can be given an expiry as well. Anyone receiving an already-used link sees an error from Telegram. That doesn't hold for a shared, reusable link — which is why such links don't belong in paid access.
Can the bot see who is in the group?
It can tell you whether one specific person is a member — but the Bot API doesn't hand over the full member list. That's why the system needs its own record of who joined, when, and how long their access runs. The bot works from that record, not from the group's membership.
What happens if the bot goes down?
The group and its members remain — the bot doesn't hold the group, it manages it. While it isn't running, new buyers get no invite and expired members stay in, so the important question isn't whether it can go down but whether you notice: you need an alert when an operation didn't run, and missed operations must be able to run afterwards.
The decisions in this article exist as running code as well: telegram-subscription-access — single-use invites, the pairing code, and removal that still lets the member return.
If you run a paid group or channel — or are considering one — and joining is still handled by hand, send me an e-mail. Say how many members there are and what takes the most manual work right now: admitting people, tracking expiry, or removal. I'll look at what can be automated.
kristof@kristofkarner.com