Телеграм бот с оплатой: как принимать платежи и учитывать заказы

Запрос "телеграм бот с оплатой" обычно означает не одну кнопку, а весь платежный контур: оффер в сообщении, понятная сумма, ссылка или invoice, подтверждение от провайдера, запись заказа в CRM и сценарий после оплаты. Если пропустить хотя бы один слой, клиент может заплатить, но не получить доступ, а менеджер не увидит покупку в карточке контакта.

Короткий вывод: для простого цифрового сценария внутри Telegram смотрите Bot API и Stars, для курсов, консультаций, магазинов и российских платежек чаще нужен внешний checkout с вебхуком. В Strelo этот маршрут собирается как часть воронки: бот создает заказ, отправляет ссылку, ждет подтверждение, фиксирует покупку у контакта и запускает следующий шаг без ручного контроля.

Короткий ответ: два маршрута оплаты

Если вы продаете цифровой товар внутри Telegram-приложения, смотрите в сторону Telegram Stars и Bot API. Если продаете физические товары, услуги, консультации, курсы или работаете через свой эквайринг, чаще понадобится внешний checkout с вебхуком.

Оба маршрута могут выглядеть одинаково для клиента: он видит сообщение, сумму и кнопку. Разница начинается после клика. Нативный Telegram Payments требует обработать invoice, pre-checkout и successful payment внутри бота. Внешний checkout требует создать заказ, сохранить внешний ID, отправить ссылку, принять вебхук и аккуратно перевести заказ из ожидания в оплату.

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

Telegram Payments: что реально дает Bot API

Telegram Bot API умеет отправлять invoice-сообщение методом sendInvoice. В таком сообщении есть описание товара, сумма и кнопка оплаты. Пользователь оплачивает внутри Telegram, а бот получает события, по которым должен подтвердить и завершить заказ.

Для физических товаров и услуг Telegram Payments работает через платежных провайдеров. Telegram в документации пишет, что не собирает платежные данные и не берет комиссию за Bot Payments для физических товаров и услуг. Но это не отменяет комиссии и правил самого провайдера, налоговой логики, чеков, возвратов и поддержки.

Ключевая точка - pre_checkout_query. Telegram отправляет ее перед завершением оплаты, а бот должен ответить через answerPreCheckoutQuery. В этом месте проверяют, доступен ли товар, не изменилась ли цена, можно ли продать этот оффер конкретному пользователю. Если бот молчит или отвечает поздно, платеж не завершается.

После успешной оплаты приходит successful_payment. Это не просто красивое событие для статистики. В нем нужно сохранить сумму, валюту, payload, telegram_payment_charge_id и provider_payment_charge_id. Эти данные пригодятся для сверки, поддержки, возвратов и разбора спорных случаев.

Telegram Stars: когда это отдельный маршрут

Digital goods and services внутри Telegram apps Telegram направляет в сторону Stars. Для таких платежей используется валюта XTR. В документации Telegram описан процесс: отправить invoice через sendInvoice, дождаться pre_checkout_query, подтвердить или отменить заказ, дождаться successful_payment, сохранить telegram_payment_charge_id и выдать товар или услугу.

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

Если вы продаете доступ к закрытому Telegram-каналу, цифровой файл или внутренний сервис в Telegram, Stars стоит изучать отдельно. Если продаете консультации, курсы с внешним кабинетом, физический товар или работаете с российским эквайрингом, чаще логичнее построить внешний платежный контур и вернуть результат в CRM вебхуком.

Внешний checkout: ссылка на оплату и вебхук

Внешний checkout устроен иначе. Бот или платформа создает заказ во внешней системе, получает ссылку на оплату и отправляет ее пользователю. После оплаты провайдер присылает вебхук. Этот вебхук должен быть подписан, разобран и связан с конкретным контактом.

В Strelo этот маршрут описывается через слой коммерции: нода "Заказ" создает заказ через commerce-интеграцию, записывает его в статусе ожидания оплаты и сохраняет payment_url в переменную. Дальше сценарий отправляет эту ссылку человеку. Когда провайдер присылает вебхук, Strelo резолвит контакт, обновляет запись в contact_purchases и запускает событие покупки или заказа.

Здесь Strelo выигрывает не как native SDK для sendInvoice, а как слой учета и автоматизации вокруг платежа. Заказ попадает в CRM, имеет статус, сумму, валюту, продукт, внешний ID и связь с контактом. Для бизнеса это часто ценнее, чем просто отправить красивую кнопку.

Как не потерять заказ между кликом и оплатой

Самая частая ошибка - считать заказ оплаченным сразу после клика по кнопке. Клик означает только интерес. Заказ становится оплаченной покупкой после подтверждения от платежного источника: successful_payment в Telegram Payments или подписанный вебхук во внешнем checkout.

Правильная модель статусов выглядит так: заказ создан в pending, ссылка отправлена, провайдер подтвердил оплату, запись стала completed, дальше запускается выдача доступа или follow-up. Возврат, ошибка или отмена не должны запускать ветку покупки.

В Strelo contact_purchases использует pending для заказа и completed для оплаченной покупки. Выручка считается только по оплатам. Это честная модель: заказ может быть создан, но человек еще не оплатил. Если смешать эти состояния, аналитика начнет показывать деньги, которых нет.

Идемпотентность: почему один платеж не должен стать двумя

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

Нужен стабильный external_order_id. Это ключ, по которому система понимает: событие относится к уже известному заказу. В Strelo повторный вебхук с тем же внешним ID не должен задваивать выручку. При смене статуса заказ обновляется, а пустой повтор не гоняет воронку заново.

Не используйте timestamp как главный ключ платежа. Два запроса по одному заказу получат разные timestamps и превратятся в две покупки. Не используйте связку "contact id плюс сумма" как единственный ключ: один человек может купить два одинаковых товара. Лучший ключ - внешний ID заказа или платежа, который стабилен у провайдера и сохраняется в вашей системе.

Как собрать платежный сценарий в Strelo

В Strelo платежный сценарий строится не вокруг отдельной кнопки, а вокруг цепочки: продукт, заказ, сообщение со ссылкой, вебхук, покупка, follow-up. Для большинства бизнесов это понятнее, чем писать собственный обработчик Telegram Payments.

Сначала создайте продукт или задайте сумму вручную. Затем добавьте ноду "Заказ", выберите commerce-интеграцию и укажите переменную, куда сохранить ссылку оплаты, например payment_url. После ноды добавьте сообщение: коротко повторите, что покупает человек, сумму, срок действия ссылки и что произойдет после оплаты.

Если оплата прошла вне основного сценария, используйте "Учет покупки". Эта нода фиксирует покупку контакта вручную или по логике воронки. Если есть внешний ID заказа, его лучше передать, чтобы повторные события не создавали дубль.

Для внешнего провайдера используйте "Интеграции продаж". Универсальная HTTP-интеграция может создавать заказ через ваш endpoint и принимать входящие вебхуки. Вебхук должен быть подписан: без подписи обработчик обязан отказать до любых действий. Это не формальность, а защита от чужих запросов на поддельную оплату.

UX сообщения с оплатой

Плохое сообщение выглядит так: "Оплатите здесь". Хорошее сообщение снимает тревогу до клика. Человек должен понять, что он покупает, сколько платит, куда попадет после оплаты и что делать, если ссылка не открылась.

В платежном сообщении не нужно много текста. Нужны четыре факта: название оффера, итоговая сумма, срок действия или условие оплаты, следующий шаг после платежа. Если есть операторская поддержка, напишите, куда обратиться. Это снижает число вопросов после списания.

Кнопка оплаты не должна быть единственным путем. Добавьте fallback: написать оператору, запросить счет, вернуться к выбору тарифа. Особенно это важно на мобильном трафике, где часть пользователей открывает ссылку во встроенном браузере, часть в системном, а часть теряет контекст и возвращается в чат с вопросом.

Что делать после оплаты

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

Минимальная post-payment цепочка: подтвердить оплату, выдать доступ или инструкцию, поставить тег покупателя, записать покупку в CRM, запустить серию онбординга, отправить вопрос о проблемах через несколько часов. Для курса это может быть ссылка на кабинет. Для консультации - выбор времени. Для магазина - статус доставки.

AI полезен после оплаты, но не должен решать спорные платежные вопросы без ограничений. Его задача - отвечать по базе знаний: где доступ, как вернуть деньги, где чек, как связаться с оператором. Вопросы про возврат, чарджбэк, ошибочную оплату или персональные данные лучше отдавать человеку.

Атрибуция: откуда пришла покупка

Оплата без источника трафика полезна бухгалтерии, но слаба для маркетинга. Если вы не знаете, из какого поста, рекламы или рассылки пришел покупатель, вы не понимаете, что масштабировать.

Связка "контакт плюс заказ плюс покупка плюс источник" дает нормальную картину: кто вошел в бота, где кликнул, что купил и какой follow-up сработал. Это особенно важно в Telegram, где один человек может сначала прийти из канала, потом вернуться из рассылки, а оплатить после ответа оператора.

Воронка оплаты должна считаться по этапам, а не только по финальным платежам. Смотрите созданные заказы, клики по ссылке, успешные оплаты, брошенные заказы, обращения в поддержку и возвраты. Один высокий общий процент ничего не объясняет, если половина людей падает на переходе в checkout.

Возвраты, ошибки и поддержка

Возврат не должен запускать ветку "Спасибо за покупку". Ошибка оплаты не должна попадать в выручку. Повторный вебхук не должен заново выдавать доступ. Эти правила нужно зашить до запуска, а не после первого конфликта с клиентом.

Юридическая часть тоже влияет на сценарий. В боте должны быть понятные условия покупки, контакты поддержки, политика возврата и информация о том, что человек получит после оплаты. Это не делает статью юридической консультацией, но снижает число спорных ситуаций.

Если пользователь пишет "деньги списались, доступа нет", оператор должен видеть не только переписку, но и заказ, статус, сумму, внешний ID и время события. Иначе поддержка превращается в ручной поиск по платежному кабинету.

Когда нужен самописный платежный бэкенд

Самописный бэкенд нужен, если вы строите сложный marketplace, подписки с собственным биллингом, несколько юридических лиц, кастомный риск-скоринг или глубокую интеграцию с ERP. В остальных случаях часто достаточно no-code слоя, который умеет создать заказ, отправить ссылку, принять вебхук, не задвоить покупку и показать ее в CRM.

Strelo уместен там, где Telegram - главный канал продаж, а бизнесу важен быстрый запуск без отдельной команды backend-разработки. Если задача - написать собственную платежную платформу, Strelo не заменяет архитектуру. Если задача - продавать из Telegram и видеть оплату в карточке контакта, это его зона.

Чеклист перед запуском оплаты в боте

Перед запуском проверьте не только счастливый путь. Создайте тестовый заказ, оплатите его, убедитесь, что контакт найден, покупка записана, доступ выдан, аналитика увидела выручку. Потом повторите вебхук с тем же ID и проверьте, что дубля нет. Отмените оплату и убедитесь, что покупка не попала в completed.

Проверьте плохие сценарии: неверная подпись вебхука, пустой контакт, сумма 0, другой product id, возврат, повторная доставка события, отключенная интеграция. Если эти кейсы не проверены, первый настоящий трафик проверит их за вас, но дороже.

Итог

Telegram оплата в боте - это не одна кнопка. Это цепочка состояния: счет или ссылка, проверка, подтверждение, запись заказа, выдача доступа, поддержка, аналитика. Нативный Telegram Payments хорош, когда вы готовы обрабатывать invoice-события Bot API. Внешний checkout хорош, когда у вас уже есть провайдер или нужен гибкий платежный контур.

Strelo в этой схеме закрывает слой операционной воронки: контакт, заказ, payment_url, вебхук, покупка, сегмент, post-payment сценарий и аналитика. Это не обещание native sendInvoice. Это практичный способ не потерять деньги и клиента после того, как он нажал оплату.