Продажа доступа в закрытый телеграм канал - это связка из трёх кусков: деньги, документ об оплате и сама выдача ссылки. Каждый кусок можно закрыть руками - принять перевод на карту, кинуть чек в личку, добавить человека в канал вручную. На потоке 5-10 подписчиков в день это ещё работает. На потоке 50+ в день ручная выдача превращается в отдельную должность, а забытый чек или подписка, которую никто вовремя не отключил, оборачивается разговором с налоговой или с недовольным подписчиком, который платит, а доступа не получил. Ниже - как я собираю такие связки на практике: от выбора эквайринга до бота, который сам создаёт одноразовую ссылку и выкидывает пользователя из канала по истечении срока.
Архитектура платного канала: из чего она реально состоит
В Telegram нет встроенного пейволла для обычных закрытых каналов - есть только звёздные подписки для авторов контента, и они закрывают узкий сценарий. Для остальных случаев архитектуру собираешь сам вокруг пригласительных ссылок с ограничениями: expire_date (время жизни), member_limit (сколько раз можно перейти) и creates_join_request (заявка на вступление, которую бот одобряет вручную или автоматически).
В рабочей связке обычно шесть элементов:
- точка приёма оплаты - лендинг, сайт на Tilda или кнопка в самом боте;
- эквайринг или платёжный сервис, который присылает уведомление об оплате;
- онлайн-касса, формирующая чек;
- генератор пригласительной ссылки на стороне Telegram Bot API;
- база данных с датой окончания подписки для каждого пользователя;
- задача, которая ежедневно кикает тех, у кого срок вышел.
Если выкинуть последний пункт, канал постепенно наполняется людьми, которые платили один раз три месяца назад и продолжают читать бесплатно - и это не гипотетическая проблема, а то, с чем реально приходят ко мне после полугода ручного администрирования.
Способы приёма оплаты за доступ к каналу
Выбор платёжки определяет, насколько просто дальше автоматизировать выдачу и чек. Сравнение по своей практике:
| Способ | Как подключается | Комиссия на рынке | Когда имеет смысл |
|---|---|---|---|
| T‑Bank эквайринг | сайт/лендинг + виджет оплаты, вебхук на успешный платёж | обычно 2,5-3,5% с оборота | своя посадочная страница, нужен рекуррент для юрлиц |
| ЮKassa | виджет или API, чек формируется автоматически | от 2,8% в зависимости от оборота | быстрый старт без своей кассы |
| CloudPayments | API + встроенная фискализация | около 2,7-3,2% | рекуррентные подписки, автосписание раз в месяц |
| Telegram Stars / Payments внутри бота | оплата прямо в чате бота, без ухода на сайт | комиссия площадки + конвертация звёзд | минимальный порог входа, аудитория без банковских карт |
| СБП по QR | через банк-эквайер или платёжный агрегатор | обычно ниже эквайринга карт, 0,4-1% | разовые платежи без подписки |
Если планируешь именно подписку с ежемесячным списанием, а не разовую продажу, сразу уточняй у банка возможность рекуррентных платежей - это отдельный тип договора, не все тарифы его включают по умолчанию. Я обычно связываю приём оплаты с лендингом на Tilda через кастомный скрипт, который дергает вебхук после успешной оплаты и передаёт его дальше в бота или в n8n.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Чеки и 54-ФЗ: как оформить продажу подписки легально
Любая систематическая продажа доступа физлицам подпадает под 54-ФЗ - чек должен формироваться в момент оплаты, а не когда вспомнишь. Три рабочих варианта в зависимости от статуса:
- самозанятый - чек через API «Мой налог», НПД 4% с физлиц или 6% с ИП/ООО, свою кассу покупать не нужно;
- ИП или ООО без своей кассы - берёшь облачную кассу от ЮKassa или CloudPayments, они сами фискализируют платёж и отправляют чек на почту клиента;
- ИП или ООО с оборотом, который не покрывает облачное решение по условиям банка - ставишь физическую или облачную ККТ отдельно (например, Атол Онлайн) и интегрируешь через API.
Разовая продажа или подписка с автосписанием
Разовая продажа проще технически - оплатил, получил ссылку, дальше твоя забота только про истечение срока и кик. Подписка с автосписанием требует хранения токена карты на стороне платёжки (сам его не видишь и не хранишь - это забота банка, не твоя), отдельного согласия на рекуррент от клиента и логики повторной попытки списания, если карта не прошла с первого раза. Я закладываю на подписочную модель отдельный вебхук «списание не удалось», который переводит пользователя в статус «грейс-период 3 дня», а не сразу кикает - иначе support завален вопросами из-за банальных технических сбоев на стороне банка.
Отдельно - про хранение данных подписчиков: если ведёшь базу с телефонами, почтами и датами оплаты, держи её на сервере в РФ (своя база Postgres, CRM с российским хостингом), а не в Google Sheets или Airtable - по 152-ФЗ персональные данные россиян должны обрабатываться на серверах, расположенных в России.
Автовыдача доступа: бот-привратник на aiogram
Схема, которую я собираю чаще всего: канал закрыт для прямого вступления, все заявки идут через creates_join_request=True, а бот с правами администратора одобряет их только тем, у кого есть активная запись в базе.
Последовательность такая: оплата → вебхук в бота → бот создаёт одноразовую ссылку с member_limit=1 и коротким expire_date (обычно 15-30 минут, чтобы ссылку не успели переслать третьим лицам) → отправляет её пользователю → пользователь переходит и отправляет заявку → бот ловит событие chat_join_request и одобряет только если в базе есть активная оплата на этот user_id.
@router.chat_join_request()
async def approve_paid_member(request: types.ChatJoinRequest):
subscription = await db.get_active_subscription(request.from_user.id)
if subscription and subscription.expires_at > datetime.utcnow():
await request.approve()
await bot.send_message(request.from_user.id, "Доступ открыт до " + subscription.expires_at.strftime("%d.%m.%Y"))
else:
await request.decline()
Такая схема закрывает главную дыру ручной выдачи - пересланную другу ссылку без ограничения по времени и числу переходов, которая гуляет по каналу месяцами.
Автоматизация через n8n без написания бота с нуля
Если не хочется поднимать отдельного бота под каждый канал, тот же процесс собирается в n8n за один workflow: нода Webhook принимает уведомление от ЮKassa или T‑Bank об успешной оплате, нода Function проверяет подпись запроса, дальше HTTP Request дергает Telegram Bot API createChatInviteLink, а следующая нода пишет запись со сроком действия в Postgres - не в Google Sheets, чтобы не тащить персональные данные подписчиков за пределы РФ.
curl -X POST "https://api.telegram.org/bot/createChatInviteLink"
-d chat_id=-1001234567890
-d member_limit=1
-d creates_join_request=true
-d expire_date=1735689600 Отдельным плюсом такой связки идёт скорость сборки - на n8n workflow с приёмом оплаты, генерацией ссылки и записью в базу у меня уходит один-два дня против недели на бота с нуля. Готовый шаблон подобного сценария есть у меня в библиотеке готовых скриптов - можно взять за основу и адаптировать под свою платёжку.
Автокик по истечении подписки и напоминания
Выдать доступ - половина дела, вторая половина - вовремя его забрать. Ежедневная cron-задача (в n8n - нода Schedule Trigger, в боте - APScheduler) сравнивает даты окончания подписок с текущей датой и для просроченных вызывает banChatMember, а сразу следом unbanChatMember - это исключает пользователя из канала, но не банит его навсегда, он сможет вернуться после новой оплаты.
За 3 дня до окончания стоит присылать напоминание в личку с кнопкой продления - это снижает отток на 15-20% по моим замерам на паре ботов с платной подпиской, просто потому что часть людей забывает продлить, а не осознанно отказывается.
| Параметр | Ручное администрирование | Бот с автовыдачей и автокиком |
|---|---|---|
| Время до выдачи доступа | от нескольких минут до часов, зависит от того, когда админ увидел оплату | секунды после вебхука |
| Риск бесплатного доступа после просрочки | высокий, если админ забыл проверить | исключён - кик по расписанию |
| Масштаб без потери качества | комфортно до 10-20 заявок в день | ограничен только лимитами Bot API |
| Пересылка ссылки третьим лицам | стандартная ссылка на канал, легко расшарить | одноразовая ссылка с истечением, риск минимален |
Автоматизация в мессенджере
Telegram-бот / Mini App
от 30 000 ₽
Подробнее →Частые вопросы
Можно ли принимать оплату переводом на личную карту и не пробивать чек?
Если это разовая продажа другу - формально не страховой случай для налоговой. Но систематическая продажа доступа физлицам за деньги - это предпринимательская деятельность, и для неё нужен статус самозанятого, ИП или ООО с чеком на каждую оплату, независимо от того, идут деньги через СБП, эквайринг или на карту.
Что будет, если добавлять людей в канал вручную по мере оплаты?
На малых объёмах ничего критичного, кроме потери времени. На больших - растут задержки между оплатой и доступом, появляются забытые просроченные подписчики и споры по возвратам, потому что нет единого лога, кто и когда получил ссылку.
Сколько стоит бот с автовыдачей доступа и автокиком по подписке?
Базовый телеграм-бот с генерацией одноразовых ссылок и ежедневным кикером у меня стоит от 30 000 ₽. Если добавляется интеграция с рекуррентными платежами, онлайн-кассой и CRM - сумма растёт, обычно старт от 50 000 ₽ в зависимости от количества платёжных систем.
Как быть с возвратами, если подписчик просит деньги назад?
Возврат оформляется через API эквайринга (ЮKassa, CloudPayments и T‑Bank это поддерживают), а параллельно бот должен сразу отозвать доступ - иначе получится ситуация, где деньги вернули, а человек продолжает читать канал до конца оплаченного периода.