Robokassa или Lava для Telegram бота: что выбрать для оплаты

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

Главная ошибка в запросе "Robokassa или Lava для Telegram бота" - сравнивать только комиссии. В боте важнее цепочка: пользователь нажал кнопку, заказ получил внешний ID, провайдер вернул подписанное событие, контакт стал покупателем, доступ выдан один раз, а источник трафика сохранился в аналитике. Если эта цепочка ломается, разница в комиссии уже не спасает конверсию.

Эта статья дополняет общий разбор оплаты в Telegram-боте. Там речь про архитектуру платежа в целом. Здесь фокус уже на выборе между двумя конкретными провайдерами для бота, который продает через внешнюю платежную ссылку и должен продолжать сценарий после подтверждения.

Быстрый вердикт: когда выбрать Lava, а когда Robokassa

Lava стоит брать первой, если вы хотите создавать счет через API, передавать hookUrl из сценария, получать invoice URL и держать заказ как часть Telegram-цепочки. Это хорошо ложится на модель "нода создала заказ, сообщение отправило ссылку, вебхук завершил оплату".

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

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

Что технически отличается в оплате бота

У Lava и Robokassa разные точки контроля. Lava создает invoice через серверный запрос к Business API. Robokassa в классическом протоколе строит ссылку на оплату локально: магазин формирует параметры, считает SignatureValue и отправляет пользователя на auth.robokassa.ru.

В Telegram-боте это меняет логику сценария. У Lava вы просите провайдера создать счет и передаете адрес вебхука сразу при создании. У Robokassa вы должны заранее настроить ResultURL в кабинете магазина, а в ссылке передать InvId и Shp-параметры, чтобы потом связать вебхук с контактом и заказом.

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

Как работает Lava в Telegram-воронке

Lava подходит для сценария, где бот должен создать invoice на конкретный заказ, сохранить ссылку в переменную и дождаться вебхука. По документации Lava для создания счета обязательны сумма, orderId, shopId и подпись, а hookUrl указывает, куда отправлять hook.

В практической воронке это выглядит так: пользователь выбрал тариф, нода Lava создала счет, сообщение отправило payment_url, провайдер прислал webhook, Strelo нашла pending-заказ и запустила ветку после оплаты. Для Telegram это удобно, потому что все события остаются привязаны к контакту.

Слабое место Lava - вы должны аккуратно хранить shopId, secret key и additional key, проверить подпись вебхука и не путать тестовый контур с боевым. Если вебхук не проходит проверку, покупка не должна становиться completed.

Как работает Robokassa в Telegram-воронке

Robokassa в классическом протоколе не требует исходящего API-запроса для создания платежной ссылки. Сервер формирует набор параметров, считает SignatureValue по Паролю #1, добавляет InvId и Shp-поля, после оплаты Robokassa шлет ResultURL, а обработчик проверяет подпись по Паролю #2.

Для Telegram-бота это удобно, когда нужен стабильный числовой InvId и магазин уже настроен в Robokassa. В Strelo нода Robokassa: Заказ создает pending-покупку, кладет payment_url в переменную и сохраняет integration_id, чтобы следующая нода Оплата Robokassa могла проверить статус через OpState.

Слабое место Robokassa - дисциплина настроек. ResultURL задается на уровне магазина, ответ обработчика должен быть OK плюс InvId, а SignatureValue приходит в form-urlencoded теле. Если перепутать Пароль #1 и Пароль #2, ссылка может открываться, но вебхук не подтвердит оплату.

Таблица выбора для бизнеса

Для Telegram-продаж провайдер нужно выбирать по модели бизнеса. У курса за 990 руб., консультации за 15000 руб. и магазина с повторными заказами разные риски: где-то важна скорость клика, где-то чек и документы, где-то надежный возврат в сценарий после платежа.

Если вы продаете один цифровой продукт внутри прогрева, Lava часто проще как invoice API. Если у вас уже работает Robokassa, есть привычный кабинет, подключены способы оплаты и настроена фискализация, менять только ради Telegram-бота необязательно. Лучше встроить текущий магазин в нормальную воронку.

Комиссии и способы оплаты нельзя фиксировать как вечную истину. На момент проверки 2026-07-03 публичная страница Lava показывала LAVA кошелек 0.5%, банковские карты от 3% и СБП от 1%. У Robokassa публичная страница для юрлиц показывала 15+ методов приема оплат, включая карты, СБП и pay-методы, а тарифы зависят от типа бизнеса и оборота.

Что важнее комиссии

Комиссия видна сразу, а стоимость сбоев видна позже. Если бот не понимает, что человек оплатил, оператор вручную ищет платеж, пользователь пишет в поддержку, доступ выдается с задержкой, а реклама не получает нормальную атрибуцию. Поэтому платежный контур нужно оценивать как часть продаж, а не как отдельный checkout.

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

Вебхуки: место, где чаще всего ошибаются

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

У Lava подпись считается HMAC SHA256 по подготовленной JSON-строке, а дополнительный ключ используется для проверки подписей в hooks. У Robokassa ResultURL требует сверки SignatureValue и ответа OK плюс InvId. Это две разные дисциплины, их нельзя описывать одной фразой "есть вебхук".

Что меняется именно для Telegram-бота

Сайт может показать страницу успеха и ждать, что пользователь сам вернется в кабинет. В Telegram так делать нельзя. Пользователь ожидает ответ в чате: оплата прошла, вот доступ, вот инструкция, вот поддержка. Поэтому провайдер должен возвращать событие в сценарий, а не только показывать SuccessURL.

Если человек оплатил и закрыл платежную страницу, бот все равно должен продолжить цепочку. Это задача webhook plus CRM, а не текста кнопки. Именно поэтому в воронке бота платежный шаг лучше проектировать рядом с сегментами, рассылками и поддержкой.

Как выглядит рабочий сценарий в Strelo

В Strelo выбор провайдера не отрывается от конструктора. Сначала вы подключаете магазин, потом в сценарии создаете заказ, затем отправляете ссылку на оплату и описываете, что произойдет после completed. Это убирает ручной стык между ботом, CRM и платежами.

Для Robokassa есть отдельный платежный гейт: сообщение с кнопкой оплаты и кнопкой проверки. Если человек нажал Проверить платеж, Strelo смотрит статус. Если вебхук пришел раньше, подтверждение уже есть в contact_purchases, и сценарий может идти по ветке paid.

Для Lava сценарий проще в части UX: нода создает invoice, сообщение отправляет ссылку, вебхук закрывает заказ. Но в обоих случаях одно правило остается неизменным: pending - не покупка, completed - покупка, failed или refunded не запускают ветку выдачи доступа.

Фискализация, чеки и юридические тексты

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

Robokassa чаще воспринимается бизнесом как привычный платежный кабинет с эквайрингом, кассовыми решениями и разными способами оплаты. Lava чаще воспринимается как быстрый платежный API и кошелек для сценариев, где нужна ссылка на invoice. Но окончательный выбор зависит от вашего юрконтура и требований к чекам.

Типовые сбои после запуска

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

Разделите поддержку на состояния. Если оплата не подтверждена, оператору нужен внешний ID, сумма, контакт и провайдер. Если доступ не выдан, нужен статус completed и журнал post-payment действий. Если пришел возврат, сценарий не должен повторно благодарить за покупку.

QA перед боевым запуском

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

Если у вас нет времени на полный тест, минимум такой: создать заказ, открыть ссылку, оплатить, дождаться webhook, проверить, что contact_purchases стал completed, убедиться, что доступ выдан один раз, повторно отправить тот же webhook в тестовом контуре и проверить отсутствие дубля.

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

Покупка в Telegram-боте должна запускать не только сообщение Спасибо. Нужны выдача доступа, обновление сегмента, остановка дожима, отметка источника, поддержка и следующая коммерческая ветка. Иначе вы получите оплату, но потеряете CRM-ценность контакта.

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

Можно ли потом сменить провайдера

Да, но смена провайдера не должна менять смысл заказов. Сохраняйте внешний ID, payment_url, source, status, сумму, валюту, contact_id и время события. Тогда вы сможете сравнить Lava и Robokassa не по ощущениям, а по конверсии, поддержке и проценту завершенных оплат.

Не запускайте оба провайдера хаотично в одной ветке. Лучше сделать A/B по сегментам или продуктам: например, дешевый цифровой продукт через Lava, дорогой курс через Robokassa, потом сравнить открытия checkout, completed rate, обращения в поддержку и долю ручных проверок.

Где здесь Strelo

Strelo не заменяет платежного провайдера. Strelo закрывает слой между провайдером и продажами в Telegram: визуальная воронка, CRM-контакт, заказ, signed webhook, post-payment ветка, сегменты, рассылки и аналитика. Поэтому вопрос звучит не "какой провайдер лучше", а "какой провайдер точнее ложится в вашу Telegram-воронку".

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

Итог

Выбирайте Lava, если вам важна invoice API-модель, hookUrl на заказ, быстрый внешний checkout и простая связка с Telegram-сценарием. Выбирайте Robokassa, если у вас уже есть магазин, нужен классический российский эквайринг, ResultURL, широкий платежный контур и привычная операционная работа с чеками и кабинетами.

В обоих случаях не считайте оплату завершенной по клику. Завершает заказ только подписанное событие или проверенный статус. Все остальное - UX вокруг платежа.