Ссылка на одного участника в Telegram — ещё не персональный доступ

Представим закрытый канал: бот подтвердил оплату и выдал покупателю ссылку с member_limit=1. Кажется, что схема защищена: один платёж — один участник. Но лимит не проверяет, кто именно вступает.
По документации Telegram, member_limit ограничивает число пользователей, которые могут одновременно состоять в чате, вступив по этой ссылке. Это не привязка к Telegram ID покупателя и не гарантия одного использования за всё время.

Пример: Анна оплатила доступ и переслала приглашение Борису. Борис вступил первым. Лимит соблюдён, но доступ получил другой аккаунт. Даже если ссылка действует пять минут, переслать её можно за несколько секунд.

Здесь речь об обычных приглашениях, когда доступом управляет бот. Нативные платные ссылки Telegram Stars — отдельный механизм.
На мой взгляд, проверять нужно право конкретного пользователя на вход. Приглашение позволяет подать заявку, а решение принимается по актуальным правам аккаунта.

Для обычных chat_join_request без query_id схема такая:

1. Бот создаёт ссылку с creates_join_request=True, без member_limit: эти параметры нельзя использовать одновременно.

2. При получении заявки берёт chat.id и from.id, проверяет действующее, не отозванное право пользователя на конкретный чат.

3. При положительном решении вызывает approveChatJoinRequest. Боту нужны права администратора с can_invite_users.

Допустим, доступ оформлен для user_id=101 в канал A. Приходит заявка от user_id=202, у которого такого права нет. Само наличие приглашения не становится основанием для одобрения. И наоборот: оплата канала A не должна автоматически открывать канал B.
Если разрешены подарки, получателя доступа нужно определить заранее. С заявкой сравнивается его Telegram ID, который может отличаться от ID плательщика.

Отдельный случай — задержка обработки оплаты. Он возможен при общей ссылке на заявки, доступной ещё до покупки. В случае если приглашение выдаётся только после записи права доступа, заявка по нему уже не может опередить эту запись.

Условная последовательность для общей ссылки:

— 12:00:00 — пользователь оплачивает подписку;
— 12:00:02 — приходит заявка, но обработчик платежа ещё не создал право доступа;
— 12:00:05 — подтверждение оплаты обработано, право записано.

Заявку для повторной проверки с ограниченным временем ожидания я бы сохранял. После обработки платежа можно заново проверить актуальный доступ и попробовать одобрить заявку. Скриншота платежа для этого недостаточно. Если БД недоступна, автоматическое одобрение тоже следует отложить.
Это относится к обычным заявкам. Для событий с query_id действует другой протокол: в течение 10 секунд нужно вызвать answerChatJoinRequestQuery или sendChatJoinRequestWebApp. Переносить туда ту же логику ожидания без изменений нельзя.

Срок приглашения и срок подписки тоже нужно разделять. Например, ссылка действует пять минут, а доступ оплачен на месяц. Истечение expire_date не удаляет уже вступившего участника. За окончание доступа отвечает отдельная логика.
Проверка заявки защищает только этот способ вступления. Другие ссылки без одобрения и действия администраторов тоже нужно учитывать. Копирование самого контента она не предотвращает.

Собственная система нужна не всегда: для ежемесячного доступа в один канал у Telegram есть платные пригласительные ссылки с оплатой Stars. Дополнительная модель прав становится полезной, когда продукт объединяет несколько чатов и тарифов.

Отсюда вопрос: как вы организуете приглашения, отдельной ссылкой на каждого получателя или общей ссылкой с проверкой каждой заявки? Какие различия заметили в аудите восстановлении доступа?