Короткий ответ и границы сценария
Webhook соединяет платёжный сервер с логикой бота; его нужно подписывать, сохранять и обрабатывать повторно без двойной выдачи. Материал рассчитан на разработчика backend части Telegram-бота. Сначала определите бизнес-объект, который изменится после оплаты: заказ, бронь, период доступа, лицензия или обязательство перед клиентом.
Обработчик сначала проверяет HMAC по исходным байтам, затем в транзакции отмечает payment_id обработанным и меняет заказ. Сообщение в Telegram отправляется после commit; если Telegram временно недоступен, отдельная очередь повторяет только уведомление. Это конкретный пример модели, а не универсальное разрешение для любой категории. Условия подключения, способы оплаты и документы подтверждаются для проекта во время модерации.
У оплаты в Telegram есть два разных слоя. Интерфейс бота или Mini App создаёт заказ и показывает пользователю кнопку, а платёжный сервер формирует счёт, принимает результат и меняет доступ. Секретный ключ нельзя помещать в клиентский JavaScript или сообщение бота: запрос создания платежа выполняет ваш backend.
Как выбрать рабочий вариант
Сравнивайте варианты по тому, какое действие нужно подтвердить и кто отвечает за следующий шаг. В таблице — три контрольные точки именно для темы «webhook оплаты для Telegram-бота».
| Контрольная точка | Как зафиксировать | С чем связать |
|---|---|---|
| raw body | Записать принятое решение, владельца и критерий готовности. | payment_id и внутренний order_id. |
| X-Timestamp | Сохранить выбранное значение и версию условий. | таблица обработанных событий и ожидаемый результат. |
| X-Signature | Определить проверку, состояние ошибки и безопасный повтор. | сообщение пользователю, payment_id и время обработки. |
Шесть точек, которые определяют результат
raw body
Контрольная точка «raw body» задаёт исходные данные для материала «Webhook оплаты для Telegram-бота: проверка и обработка». Зафиксируйте решение в карточке заказа до создания платежа, чтобы повторный запрос не создавал новую продажу случайно.
X-Timestamp
Пункт «X-Timestamp» должен быть понятен покупателю до перехода в форму: покажите сумму, назначение и ожидаемый результат. Интерфейс отдельно объясняет ожидание, успех, отмену и истечение, не подменяя серверный статус красивым экраном.
X-Signature
Для пункта «X-Signature» определите техническое доказательство завершения: проверенное событие, совпавшие сумма и валюта, известные order_id и payment_id. Только после этой проверки запускайте продуктовую выдачу или исполнение заказа.
payment_id
У элемента «payment_id» должен быть владелец исключений. Ему нужна история попыток и правило, которое объясняет, можно ли безопасно повторить создание, отправку ссылки или выдачу без доступа к API-ключам.
таблица обработанных событий
Требование «таблица обработанных событий» проверьте повторной доставкой callback. Два одинаковых события не должны дважды продлевать доступ, резервировать место, начислять баланс или отправлять товар; ограничение фиксируют на уровне данных.
сообщение пользователю
Для точки «сообщение пользователю» заранее опишите возврат, спор и задержку результата. Покупателю нужен понятный канал поддержки, а команде — связь между исходным заказом, платежом, документом и обратной операцией.
Пошаговая схема
- raw body. Связывайте Telegram user_id с внутренним customer_id, но не используйте его как единственный идентификатор заказа. Запишите входные данные, ответственного и условие завершения. Если нужен денежный результат, сообщение пользователя и визуальный редирект не заменяют проверенный серверный статус.
- X-Timestamp. Создавайте новый order_id для каждой покупки и сохраняйте payment_id до отправки ссылки пользователю. Запишите входные данные, ответственного и условие завершения. Если нужен денежный результат, сообщение пользователя и визуальный редирект не заменяют проверенный серверный статус.
- X-Signature. Разделите сообщения об ожидании, успехе, отмене и истечении срока платежа. Запишите входные данные, ответственного и условие завершения. Если нужен денежный результат, сообщение пользователя и визуальный редирект не заменяют проверенный серверный статус.
- payment_id. Проверяйте подпись webhook по исходному телу запроса до JSON-разбора. Запишите входные данные, ответственного и условие завершения. Если нужен денежный результат, сообщение пользователя и визуальный редирект не заменяют проверенный серверный статус.
- таблица обработанных событий. Повторное событие не должно повторно выдавать доступ или отправлять товар. Запишите входные данные, ответственного и условие завершения. Если нужен денежный результат, сообщение пользователя и визуальный редирект не заменяют проверенный серверный статус.
Шестая точка — сообщение пользователю — завершает цикл. Она должна быть видна в личном кабинете или внутренней системе проекта, чтобы поддержка могла восстановить ход операции без доступа к секретным ключам и без просьбы прислать скриншот.
Как собрать сценарий на RollyPay
В сценарии «webhook оплаты для Telegram-бота» бот отвечает за диалог, а backend — за секреты и состояние заказа. Сервер фиксирует «raw body», создаёт платёж и передаёт боту только готовый pay_url; X-API-Key не попадает в сообщение или Mini App.
Кнопка реализует пункт «X-Timestamp», но не подтверждает оплату. Backend принимает callback_url, проверяет X-Signature по исходному телу и сопоставляет событие с order_id и payment_id.
Пункт «таблица обработанных событий» выполняется один раз после payment.paid. Если пользователь закрыл форму, бот может показать актуальный статус из вашей базы; ему не нужно верить скриншоту или факту возврата на success URL.
Для темы «Webhook оплаты для Telegram-бота: проверка и обработка» условия и варианты подключения собраны на странице решения RollyPay. Там можно сопоставить сценарий с продуктом, а здесь сохранить инструкцию и контрольные детали для реализации.
Пример для интеграции
Фрагмент показывает только ключевой принцип. Добавьте типизацию ответа, таймауты, безопасное хранение секретов, журналирование без чувствительных данных и обработку всех HTTP-статусов.
const expected = hmacSha256(signingSecret, timestamp + "." + rawBody);
if (!constantTimeEqual(expected, signature)) return res.sendStatus(403);
const event = JSON.parse(rawBody);
if (event.event_type === "payment.paid") await grantTelegramAccessOnce(event.payment_id, event.order_id);Частые ошибки
Нет внутреннего объекта продажи. Пункт «raw body» существует только в переписке, поэтому платёж нельзя однозначно связать с товаром или обязательством. Сначала создайте внутренний заказ и только затем внешний платёж.
Интерфейс принят за доказательство. Пункт «X-Timestamp» может быть кнопкой, QR, ссылкой или экраном возврата. Денежный результат всё равно подтверждают серверное состояние и проверенное событие.
Разорваны данные процесса. Пункты «X-Signature» и «таблица обработанных событий» должны быть связаны через order_id, payment_id, сумму, валюту и последнее событие. Тогда повтор или позднее подтверждение обрабатываются безопасно.
Нет владельца исключений. Пункт «сообщение пользователю» включает возврат, истечение, спор и сбой доставки. Для каждого случая нужны статус, ответственная роль и понятное сообщение покупателю.
Что проверить до публикации
Для цифровых товаров и услуг, продаваемых внутри приложений Telegram, официальные правила требуют Telegram Stars. Внешняя платёжная ссылка не является универсальной заменой Stars. Для физических товаров, офлайн-услуг и допустимых внешних сценариев действуют другие варианты, но категорию товара и актуальные правила нужно проверить до запуска.
Надёжный бот не выдаёт товар после простого возврата пользователя на success URL. Он ждёт серверное событие, проверяет подпись, сверяет сумму и order_id, делает операцию идемпотентной и только затем меняет роль, срок подписки или статус заказа.
- Категория проекта и предмет продажи описаны одинаково на сайте, в боте и в заявке на подключение.
- Цена, валюта, срок действия предложения и правила возврата видны до оплаты.
- Секреты находятся только на сервере, а журнал не содержит API-ключей и полного тела с чувствительными данными.
- Успех, отмена, истечение, повтор события и недоступность callback проверены до реальных продаж.
- Налоговый или кассовый документ создаётся по правилам статуса продавца и связан с заказом.