Модель заказа
Состав, сумма, валюта, статусы и связь с платёжным идентификатором.
Бот с оплатой
Telegram-бот с оплатой
Связываем заказ и платёж так, чтобы выдача происходила только после подтверждённого события, а спорный случай можно было восстановить.
Короткий ответ
Платёжный сценарий зависит от типа продажи. Цифровые товары и услуги внутри Telegram должны оплачиваться Telegram Stars; для физических товаров и услуг доступны сторонние платёжные провайдеры. Бот не должен выдавать товар по нажатию кнопки: сначала проверяется заказ, затем фиксируется подтверждение успешного платежа и только после этого запускается исполнение.
Сценарий проверен: 1 сентября 2026 г.
Workflow
Схема процесса
Каждый переход должен иметь входные данные, ожидаемый результат и понятное действие при ошибке.
01
Заказ
Backend создаёт заказ с неизменяемым идентификатором, составом и суммой.
02
Счёт
Бот отправляет invoice в допустимой валюте и через выбранный сценарий оплаты.
03
Проверка
Перед завершением оплаты сервер повторно проверяет цену, доступность и статус заказа.
04
Подтверждение
Успешное платёжное событие сохраняется идемпотентно и связывается с заказом.
05
Исполнение
Товар, запись или доступ выдаётся один раз; поддержка видит статус и историю.
Когда решение подходит
- Оплата заказа внутри последовательного сценария
- Продажа цифрового доступа с учётом правил Stars
- Физические товары или услуги через поддерживаемого провайдера
- Выдача результата по подтверждённому платёжному событию
Что нужно до разработки
- Классификация товара или услуги: цифровой либо физический
- Юридически согласованные оферта, возвраты и поддержка
- Товар, цена, валюта и устойчивый идентификатор заказа
- Тестовый режим выбранного платёжного сценария
Результат проектного этапа
Конкретный состав фиксируется после обследования систем и процесса; ниже — базовые проверяемые результаты.
Платёжный контур
Invoice, проверка перед оплатой и обработка успешного события.
Идемпотентная выдача
Повторное событие не создаёт второй заказ и не выдаёт товар повторно.
Ошибки и возвраты
Неуспешная оплата, отмена, спор и согласованный порядок возврата.
Поддержка
Поиск заказа, команда помощи и данные для разбора обращения.
Проверка запуска
Тестовые платежи, повторные события и сверка статусов до production.
Контроль качества
Риски и failure modes
- Неверный способ оплаты для цифрового товара
- Цена меняется после формирования счёта
- Повторное событие исполняет заказ дважды
- Товар выдаётся до подтверждения платежа
- Нет процесса возврата и ответа на платёжный спор
Стоимость
Оценка после декомпозиции
Бюджет зависит от числа систем, ролей, состояний, интеграционных событий, качества исходных данных и требований к сопровождению.
Посмотреть ориентирыPrimary sources
Официальные правила платформы
Ограничения проверяются по документации владельца платформы, а перед запуском сверяются повторно.
Связанные решения
Связанные услуги
Разобрать ваш процесс
Покажите текущую схему, системы, роли и проблемные исключения. Предложим границы первого этапа и критерии приёмки без неподтверждённых обещаний результата.