Платежи в Telegram

Оплата подписки в Telegram-боте: статусы и доступ

Подписка требует отдельного учёта периода: подтверждённый платёж продлевает paid_until один раз, а не просто ставит бессрочный флаг.

Короткий ответ и границы сценария

Подписка требует отдельного учёта периода: подтверждённый платёж продлевает paid_until один раз, а не просто ставит бессрочный флаг. Материал рассчитан на бота клуба, поддержки или сервиса с оплатой за фиксированный период. Сначала определите бизнес-объект, который изменится после оплаты: заказ, бронь, период доступа, лицензия или обязательство перед клиентом.

Участник оплачивает ещё 30 дней за неделю до окончания. Система добавляет период к текущему paid_until, а не к сегодняшней дате; повторное событие с тем же payment_id не увеличивает срок второй раз. Это конкретный пример модели, а не универсальное разрешение для любой категории. Условия подключения, способы оплаты и документы подтверждаются для проекта во время модерации.

Важное ограничение. Если подписка открывает цифровую функцию внутри Telegram, сначала применяются правила Telegram Stars. Внешний checkout рассматривают только для сценария, который действительно допускается правилами платформы и условиями подключения.

У оплаты в Telegram есть два разных слоя. Интерфейс бота или Mini App создаёт заказ и показывает пользователю кнопку, а платёжный сервер формирует счёт, принимает результат и меняет доступ. Секретный ключ нельзя помещать в клиентский JavaScript или сообщение бота: запрос создания платежа выполняет ваш backend.

Как выбрать рабочий вариант

Сравнивайте варианты по тому, какое действие нужно подтвердить и кто отвечает за следующий шаг. В таблице — три контрольные точки именно для темы «оплата подписки в Telegram-боте».

Контрольная точкаКак зафиксироватьС чем связать
тариф и периодЗаписать принятое решение, владельца и критерий готовности.правило сложения дней и внутренний order_id.
дата paid_untilСохранить выбранное значение и версию условий.повтор webhook и ожидаемый результат.
счёт на продлениеОпределить проверку, состояние ошибки и безопасный повтор.напоминание об окончании, payment_id и время обработки.
Путь от сообщения в Telegram до подтверждения оплаты и выдачи доступа
Схема сценария. Визуальный путь для запроса «оплата подписки в Telegram-боте»: от сохранённого заказа до подтверждённого результата.
тариф и периодЗафиксировать объект и условия до создания платежа.
счёт на продлениеСвязать заказ с order_id, payment_id и точной суммой.
повтор webhookВыполнить результат один раз после проверенного события.

Шесть точек, которые определяют результат

тариф и период

Контрольная точка «тариф и период» задаёт исходные данные для материала «Оплата подписки в Telegram-боте: статусы и доступ». Зафиксируйте решение в карточке заказа до создания платежа, чтобы повторный запрос не создавал новую продажу случайно.

дата paid_until

Пункт «дата paid_until» должен быть понятен покупателю до перехода в форму: покажите сумму, назначение и ожидаемый результат. Интерфейс отдельно объясняет ожидание, успех, отмену и истечение, не подменяя серверный статус красивым экраном.

счёт на продление

Для пункта «счёт на продление» определите техническое доказательство завершения: проверенное событие, совпавшие сумма и валюта, известные order_id и payment_id. Только после этой проверки запускайте продуктовую выдачу или исполнение заказа.

правило сложения дней

У элемента «правило сложения дней» должен быть владелец исключений. Ему нужна история попыток и правило, которое объясняет, можно ли безопасно повторить создание, отправку ссылки или выдачу без доступа к API-ключам.

повтор webhook

Требование «повтор webhook» проверьте повторной доставкой callback. Два одинаковых события не должны дважды продлевать доступ, резервировать место, начислять баланс или отправлять товар; ограничение фиксируют на уровне данных.

напоминание об окончании

Для точки «напоминание об окончании» заранее опишите возврат, спор и задержку результата. Покупателю нужен понятный канал поддержки, а команде — связь между исходным заказом, платежом, документом и обратной операцией.

Пошаговая схема

  1. тариф и период. Связывайте Telegram user_id с внутренним customer_id, но не используйте его как единственный идентификатор заказа. Запишите входные данные, ответственного и условие завершения. Если нужен денежный результат, сообщение пользователя и визуальный редирект не заменяют проверенный серверный статус.
  2. дата paid_until. Создавайте новый order_id для каждой покупки и сохраняйте payment_id до отправки ссылки пользователю. Запишите входные данные, ответственного и условие завершения. Если нужен денежный результат, сообщение пользователя и визуальный редирект не заменяют проверенный серверный статус.
  3. счёт на продление. Разделите сообщения об ожидании, успехе, отмене и истечении срока платежа. Запишите входные данные, ответственного и условие завершения. Если нужен денежный результат, сообщение пользователя и визуальный редирект не заменяют проверенный серверный статус.
  4. правило сложения дней. Проверяйте подпись webhook по исходному телу запроса до JSON-разбора. Запишите входные данные, ответственного и условие завершения. Если нужен денежный результат, сообщение пользователя и визуальный редирект не заменяют проверенный серверный статус.
  5. повтор webhook. Повторное событие не должно повторно выдавать доступ или отправлять товар. Запишите входные данные, ответственного и условие завершения. Если нужен денежный результат, сообщение пользователя и визуальный редирект не заменяют проверенный серверный статус.

Шестая точка — напоминание об окончании — завершает цикл. Она должна быть видна в личном кабинете или внутренней системе проекта, чтобы поддержка могла восстановить ход операции без доступа к секретным ключам и без просьбы прислать скриншот.

Как собрать сценарий на RollyPay

В сценарии «оплата подписки в Telegram-боте» бот отвечает за диалог, а backend — за секреты и состояние заказа. Сервер фиксирует «тариф и период», создаёт платёж и передаёт боту только готовый pay_url; X-API-Key не попадает в сообщение или Mini App.

Кнопка реализует пункт «дата paid_until», но не подтверждает оплату. Backend принимает callback_url, проверяет X-Signature по исходному телу и сопоставляет событие с order_id и payment_id.

Пункт «повтор webhook» выполняется один раз после payment.paid. Если пользователь закрыл форму, бот может показать актуальный статус из вашей базы; ему не нужно верить скриншоту или факту возврата на success URL.

Для темы «Оплата подписки в Telegram-боте: статусы и доступ» условия и варианты подключения собраны на странице решения RollyPay. Там можно сопоставить сценарий с продуктом, а здесь сохранить инструкцию и контрольные детали для реализации.

Частые ошибки

Нет внутреннего объекта продажи. Пункт «тариф и период» существует только в переписке, поэтому платёж нельзя однозначно связать с товаром или обязательством. Сначала создайте внутренний заказ и только затем внешний платёж.

Интерфейс принят за доказательство. Пункт «дата paid_until» может быть кнопкой, QR, ссылкой или экраном возврата. Денежный результат всё равно подтверждают серверное состояние и проверенное событие.

Разорваны данные процесса. Пункты «счёт на продление» и «повтор webhook» должны быть связаны через order_id, payment_id, сумму, валюту и последнее событие. Тогда повтор или позднее подтверждение обрабатываются безопасно.

Нет владельца исключений. Пункт «напоминание об окончании» включает возврат, истечение, спор и сбой доставки. Для каждого случая нужны статус, ответственная роль и понятное сообщение покупателю.

Что проверить до публикации

Для цифровых товаров и услуг, продаваемых внутри приложений Telegram, официальные правила требуют Telegram Stars. Внешняя платёжная ссылка не является универсальной заменой Stars. Для физических товаров, офлайн-услуг и допустимых внешних сценариев действуют другие варианты, но категорию товара и актуальные правила нужно проверить до запуска.

Надёжный бот не выдаёт товар после простого возврата пользователя на success URL. Он ждёт серверное событие, проверяет подпись, сверяет сумму и order_id, делает операцию идемпотентной и только затем меняет роль, срок подписки или статус заказа.

  • Категория проекта и предмет продажи описаны одинаково на сайте, в боте и в заявке на подключение.
  • Цена, валюта, срок действия предложения и правила возврата видны до оплаты.
  • Секреты находятся только на сервере, а журнал не содержит API-ключей и полного тела с чувствительными данными.
  • Успех, отмена, истечение, повтор события и недоступность callback проверены до реальных продаж.
  • Налоговый или кассовый документ создаётся по правилам статуса продавца и связан с заказом.

Частые вопросы

С чего начать подключение по этому сценарию?

Начните с внутреннего заказа и точки «тариф и период»: определите продавца, предмет продажи, сумму и результат, который можно выдать только после подтверждения.

Можно ли считать переход на успешную страницу подтверждением оплаты?

Нет. Редирект нужен для интерфейса. Состояние заказа меняют после проверенного серверного события и сверки payment_id, order_id, суммы и валюты.

Что делать, если webhook пришёл повторно?

Сохраните уникальный ключ обработки и верните успешный ответ без повторного действия. Особенно важно не дублировать элемент «повтор webhook».

Какие данные нужны поддержке для разбора?

Достаточно order_id, payment_id, времени, суммы, последнего статуса и результата шага «напоминание об окончании». API-ключи и signing secret передавать поддержке нельзя.

Источники и документация