Платежи в Telegram

Оплата бронирования в Telegram-боте: слот, ссылка и статус

Бот с бронированием должен удерживать слот до оплаты, создавать отдельный заказ и подтверждать запись только по серверному событию. Так два клиента не займут одно время.

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

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

Пользователь выбирает время в боте, backend ставит резерв на десять минут и создаёт order_id. После payment.paid бронь подтверждается один раз; при expiry слот автоматически возвращается в расписание. Это конкретный пример модели, а не универсальное разрешение для любой категории. Условия подключения, способы оплаты и документы подтверждаются для проекта во время модерации.

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

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

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

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

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

выбор услуги

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

свободный слот

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

временный резерв

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

кнопка pay_url

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

payment.paid

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

подтверждение или освобождение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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