Auto-remove subscribers when access ends
Paid access stays paid only when non-payers leave on their own. Here's the mechanics of the kick, the grace period, and re-entry.
Why removal has to be automatic
Every subscription reaches a moment where access has expired and the person hasn't renewed. If you run the channel by hand, each case is your job: remember who paid and when, open the member list, find the right person, remove them. At ten subscribers that's tolerable. At a hundred it's a steady source of mistakes — you either forget to remove a non-payer (who now sits in a paid channel for free) or remove someone who just renewed.
So removal after a subscription ends should be mechanical, not a judgment call. The system knows the date a person paid through, and when that date passes, it acts on its own. This isn't harshness, it's hygiene: paid access stops being paid if you can skip paying for it.
How an automatic kick works
Technically, access is owned by the bot that's an admin of your private channel. While a subscription is active, the bot keeps the person inside. When the end date arrives and there's no payment, the bot removes the member from the channel. In Telegram this is done via a kick: the person loses access to posts and can't return via an old link.
One important detail: a correct implementation does not ban the person permanently — it just removes them. The distinction is critical. A ban means they can't return even after paying, which breaks the single most important scenario: a removed member changing their mind and wanting to pay again. So "remove" and "ban" are different actions, and for subscriptions you want the former.
Grace period: don't cut people off cold
Between "expired" and "removed" there should be a grace period — a few days during which the person is still inside even though they formally haven't paid yet. Why? Payments lag, cards fail on the first try, people simply forget to renew for a day or two. If you remove someone at exactly midnight on the expiry date, you'll lose a slice of people who genuinely wanted to stay.
A sensible sequence looks like this: a few days before expiry the bot sends a renewal reminder; on the expiry day, another one; then the grace period with a final warning; and only if there's still no payment, removal. That way you cut off true non-payers without punishing those whose payment just didn't land on time.
Re-joining after renewal
The scenario this whole system exists for: someone is removed, then a week later wants back in. Automation matters here just as much. When a former subscriber pays again, the bot should grant access without your involvement — generate a fresh invite link and let them back in. No "DM me and I'll add you."
This is exactly why removal must not be a ban: a banned person hits a wall even with money in hand, and you lose an easy repeat sale. The right model is a door that opens whenever a payment clears and closes when it stops. Access state always mirrors payment state.
What to log
Every automatic removal is worth recording: when, who, and why (subscription expired, payment refunded, manual kick). This isn't bureaucracy — it's your protection. When someone writes "why was I removed, I paid," you have a precise answer instead of a guess. The log also shows how many people drop off at expiry, a direct signal of how well your renewals are working.
Log the reverse events too: renewals, re-joins, successful reminders. Together they give an honest picture of the subscriber lifecycle, showing where you lose people and whether they come back.
The takeaway
Automatic removal isn't about punishing anyone. It's about keeping paid access paid without your daily involvement: remind, give a few days of slack, remove if there's no payment, and instantly let people back in when one arrives. All of this should run quietly while you focus on content.
In RybkaOS this is already wired: the bot watches the dates, sends reminders, holds a grace period, removes non-payers (without banning them), and restores access after renewal — with every action landing in the activity log. You never have to keep lists by hand.