LAVA оплата в Telegram-боте для курса: счет, webhook и доступ

Запрос "lava оплата в telegram боте для курса" обычно появляется в момент, когда онлайн-школа уже продает через Telegram, но платежи еще живут отдельно: ссылка в личке, таблица оплат, ручная выдача доступа, поддержка с вопросом "я оплатил, где уроки". Правильное решение не сводится к кнопке "Оплатить". Нужно связать оффер, сумму, ученика, внешний номер заказа, webhook от LAVA, статус покупки, CRM и сценарий доступа.

Короткий вывод: LAVA подходит для продажи курса в Telegram, если бот не просто отправляет ссылку, а создает счет под конкретного ученика, хранит pending-заказ, принимает подписанный webhook и только после подтверждения переводит покупку в оплаченный статус. В Strelo эта логика собирается вокруг ноды заказа, карточки контакта, покупок, тегов, полей и последующих веток сценария.

Что на самом деле нужно онлайн-курсу

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

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

Как выглядит рабочий маршрут

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

Что настроить в LAVA и Strelo

Для подключения нужны проект LAVA, идентификатор магазина, ключ для подписи запросов и ключ для проверки webhook. В интерфейсе Strelo это хранится в интеграции продаж. В сценарии курса администратор выбирает подключение LAVA, задает сумму, товар или описание платежа, срок действия счета и действия после оплаты.

Важный момент: описание платежа должно быть понятно ученику и поддержке. Не стоит писать только "курс" или "доступ". Лучше фиксировать конкретный продукт: "Курс по запускам, тариф База" или "Клуб, месяц июль". Тогда при споре, возврате или вопросе менеджер видит контекст без поиска в переписке.

Почему webhook важнее кнопки

Кнопка оплаты отвечает только за переход ученика на checkout. Решение о доступе должно принимать не сообщение ученика и не успешный редирект, а webhook от платежного провайдера. В документации LAVA для счета есть поле hookUrl, куда отправляется уведомление, а подпись строится через HMAC SHA256 по точной JSON-строке запроса. Поэтому интеграция должна подписывать исходящий запрос и проверять входящий webhook по сырым данным.

В Strelo webhook принимает публичный endpoint коммерческой интеграции. Сначала загружается интеграция, затем проверяется подпись, потом payload разбирается в нормализованную покупку. Для LAVA контакт сначала ищется по уже созданной pending-записи с тем же order_id, а customFields используется как запасной контекст. Это снижает риск, что произвольный payload подменит ученика.

Pending, completed и доступ к курсу

Самая частая ошибка в оплате курса через Telegram: считать покупку оплаченной сразу после клика по кнопке. Между кликом и подтверждением есть несколько состояний. Ученик мог открыть форму, закрыть ее, не пройти банк, оплатить позже или оплатить, но webhook задержался. Поэтому в CRM нужен pending-заказ, а не мгновенная выручка.

Когда LAVA возвращает успешный статус, покупка становится completed. В этот момент можно применить тег, метку CRM, поле контакта, отправить доступ, открыть ветку сопровождения или запустить задачу менеджеру. Если статус failed или refunded, доступ не выдается автоматически, а команда видит причину для поддержки.

Как учитывать разные тарифы курса

У курса редко бывает только одна цена. Есть базовый тариф, расширенный тариф с куратором, VIP-доступ, рассрочка, клубная подписка, ранняя цена и спецпредложение после вебинара. Если все эти варианты вести одной безымянной ссылкой, команда быстро потеряет связь между оплатой и обещанным форматом участия.

Лучше заранее договориться, что именно попадает в заказ. Название продукта отвечает на вопрос "что купил ученик", тариф отвечает на вопрос "какой объем доступа обещан", сумма отвечает на вопрос "сколько денег должно быть в отчете", внешний номер заказа отвечает на вопрос "какой webhook обновил статус". Тогда даже при ручной поддержке менеджер видит не просто "оплачен", а конкретную покупку.

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

Как не смешать оплату и выдачу доступа

Оплата и доступ - разные события. Оплата означает, что деньги прошли и webhook подтвердил счет. Доступ означает, что ученик получил право войти в уроки, канал, кабинет или закрытый чат. Иногда эти события происходят почти одновременно, но в системе их лучше разделять.

Такой разрыв помогает в спорных ситуациях. Например, ученик оплатил, но написал другой email для LMS. Или оплатил тариф с куратором, но попал в общий поток. Или прошел возврат, а доступ еще активен. Если в CRM есть отдельные поля "статус оплаты", "тариф", "срок доступа" и "канал выдачи", поддержка решает вопрос быстрее и без поиска по нескольким таблицам.

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

Как написать сообщение с кнопкой оплаты

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

Плохой вариант: "Оплатите по ссылке". Хороший вариант: "Вы выбрали курс по запускам, тариф База. Стоимость 18 900 рублей. После оплаты бот пришлет ссылку на личный кабинет и инструкцию по старту. Если форма не открылась, нажмите Поддержка". В таком сообщении нет перегруза, но есть все, что нужно ученику.

Что должна видеть поддержка

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

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

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

Как считать платежную воронку

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

Какие данные нужны для отчета

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

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

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

Где обычно ломается запуск

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

Минимальный запуск за один день

Для первой версии не нужно строить сложную LMS-архитектуру. Достаточно одного продукта, одной цены, понятного сообщения, LAVA-интеграции, pending-покупки, webhook, тега "оплатил", сообщения с доступом и отдельной ветки поддержки для проблемных оплат. Сложность лучше добавлять после первых реальных платежей.

Когда не стоит усложнять

Если вы продаете первый мини-курс на маленькую аудиторию, не нужно сразу строить сложную карту статусов, LMS-синхронизацию и десяток тарифов. Начните с одного продукта, одной цены, понятного сообщения и одного сценария после оплаты. Цель первой версии - доказать, что ученик может пройти путь без ручной сверки.

Но даже в самой простой версии не стоит жертвовать тремя вещами. Первая - уникальный orderId, чтобы webhook можно было связать с заказом. Вторая - pending-покупка, чтобы команда видела, кто начал оплату. Третья - проверка подписи, чтобы доступ не открывался от случайного запроса. Все остальное можно нарастить после первых платежей.

Когда появятся повторные запуски, несколько тарифов, кураторы и партнерские источники, структура уже будет готова. Вы добавите сегменты, отчеты, дожимы, новые поля контакта и интеграцию с LMS без переделки базовой платежной логики. Это и есть смысл правильной связки LAVA и Telegram-бота: сначала надежность, потом масштабирование.

Итог

LAVA в Telegram-боте для курса стоит внедрять как платежный контур, а не как отдельную ссылку. Счет должен быть связан с учеником, статус должен приходить через webhook, CRM должна хранить pending и completed, а доступ должен выдаваться только после подтверждения. Тогда Telegram становится не просто местом переписки, а каналом продажи, оплаты, учета и сопровождения ученика.

Для команды онлайн-школы это меняет ежедневную работу. Продюсер видит выручку и потери на шагах, администратор понимает, кому выдан доступ, менеджер отвечает с контекстом заказа, а ученик не ждет ручной сверки. Именно такая связка нужна, когда курс продается внутри Telegram, а не через набор разрозненных ссылок.