Telegram бот с Robokassa для онлайн-школы: оплата курса, чек и доступ

Запрос "telegram бот с robokassa для онлайн школы" обычно возникает в момент, когда простая ссылка на оплату уже не устраивает. Нужно, чтобы ученик увидел оффер в Telegram, оплатил курс, получил чек, попал в нужный сегмент, открыл доступ и не завис между платежным кабинетом, LMS и менеджером.

Короткий вывод: Robokassa закрывает прием платежа и фискальный контур, а Telegram-бот должен закрыть клиентский путь вокруг него. В Strelo этот путь можно собрать как коммерческий сценарий: создать заказ, отправить платежную ссылку, принять подписанный ResultURL, записать покупку в CRM и запустить ветку после оплаты.

Где Robokassa находится в контуре онлайн-школы

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

У онлайн-школы обычно есть четыре слоя. Первый слой - витрина: вебинар, пост, рассылка, консультация или Telegram-воронка. Второй слой - платеж: сумма, способ оплаты, чек, статус. Третий слой - доступ: курс, группа, закрытый канал, кабинет или запись на созвон. Четвертый слой - учет: контакт, источник, покупка, менеджер, повторные касания и аналитика.

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

Для кого такой сценарий особенно полезен

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

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

Второй тип - школа с evergreen-воронкой. Трафик приходит каждый день, оплата идет без вебинара, а доступ нужен сразу. Здесь опасно ждать ручной проверки: ученик платит вечером, а доступ получает утром, пишет в поддержку и теряет доверие.

Третий тип - команда, которая оставляет уроки в GetCourse или другой LMS, но хочет продавать через Telegram. В этом варианте Telegram становится продажным фронтом, Robokassa - платежным шлюзом, LMS - учебным слоем, а CRM отвечает за контакт и повторные касания.

Как выглядит правильный путь ученика

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

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

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

Что делает Strelo вокруг Robokassa

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

Когда Robokassa присылает ResultURL, Strelo проверяет подпись через Password 2, разбирает данные, связывает событие с контактом и обновляет покупку. Для Robokassa обработчик возвращает plain text OK с InvId, как требуется протоколом. Это важно: платежный вебхук не должен быть просто страницей успеха.

У Strelo есть и отдельная нода Оплата Robokassa как платежный gate. Она отправляет кнопку оплаты и кнопку проверки платежа. Если webhook уже подтвердил заказ, нода может продолжить сценарий по paid-ветке. Если платеж еще не найден, пользователь остается на шаге и видит понятное сообщение ожидания.

Чек и фискализация: где нужна осторожность

Для онлайн-школы чек - не декоративная деталь. Покупатель ожидает подтверждение, бухгалтерия ожидает корректный состав заказа, а поддержка должна понимать, что отвечать на вопрос "где чек". Robokassa публично описывает несколько решений для чеков и онлайн-кассы, включая Robokassa Online, Robocheki и Robocheki SMZ.

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

Важно не обещать ученику автоматический доступ раньше, чем платеж подтвержден. Кнопка, клик и переход на checkout не равны оплате. Оплаченным считается только заказ, который получил доверенный статус от Robokassa и прошел проверку подписи.

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

Самая неприятная поломка выглядит так: деньги списались, ученик вернулся в Telegram, а бот молчит. Обычно причина в том, что сценарий полагался на SuccessURL или на ручной клик, а не на серверное уведомление.

SuccessURL удобен для UX: человек возвращается после оплаты и видит понятное сообщение. Но он не должен быть единственным источником правды. Пользователь может закрыть окно, сеть может оборваться, встроенный браузер может не вернуться в Telegram. ResultURL от Robokassa должен оставаться авторитетным сигналом.

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

Как писать платежное сообщение в боте

Платежное сообщение не должно выглядеть как техническая ссылка. Ученик должен понять пять вещей: что он покупает, сколько платит, каким способом можно оплатить, что будет после оплаты и куда писать, если что-то не открылось.

Хороший текст короткий. Например: "Вы выбрали тариф Практика. Стоимость 9900 руб. Нажмите Оплатить, после подтверждения бот пришлет доступ и инструкцию. Если ссылка не открылась, нажмите Помощь". В таком сообщении нет лишней SEO-воды, зато есть снятие тревоги.

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

Тарифы, рассрочка и промокоды

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

Перед отправкой в Robokassa бот должен знать продукт и тариф. В заказе полезно хранить не только сумму, но и код оффера, название тарифа, источник скидки, срок доступа, ответственного менеджера и правило post-payment. Тогда после оплаты не нужно угадывать, какой доступ открывать.

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

Что делать с неоплаченными заказами

Заказ в pending - это не провал. Это теплый сигнал. Человек дошел до оплаты, значит он понял оффер и готов сравнивать условия. Если его бросить, часть денег уйдет в тишину.

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

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

Интеграция с LMS и GetCourse

Многие школы не хотят переносить уроки из LMS. Это нормально. Telegram-боту не обязательно становиться учебным кабинетом. Его задача - продать, объяснить, принять оплату, зафиксировать контакт и передать ученика туда, где лежит обучение.

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

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

Проверка перед рекламным трафиком

Не запускайте рекламу сразу после того, как появилась платежная ссылка. Минимальный тест должен пройти как реальный ученик: новый контакт, выбор тарифа, переход на Robokassa, оплата в тестовом или боевом режиме на малой сумме, ResultURL, запись покупки, выдача доступа, повторный вебхук, вопрос в поддержку.

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

В аналитике нужно считать не только оплаченные заказы. Полезны четыре числа: дошли до оффера, нажали оплату, завершили платеж, получили доступ без обращения в поддержку. Тогда понятно, где чинить воронку: текст оффера, checkout, webhook или post-payment ветку.

Итог

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

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