Обзор сервисов экосистемы Cloud и зачем это знать техспецу

Если вы работаете с онлайн-школами, c CloudPayments вы точно знакомы. Но теперь на одном сайте Cloud представлены ещё касса, чеки и донаты. Я посмотрел, какие задачи школы можно решить этими сервисами, где понадобится техспец и как у них устроена партнёрская программа.

«Нам бы платежку подключить». Кажется, понятная задача: включить интеграцию, провести тест и отдать заказчику. Но вот ученик заплатил — и пишет в поддержку, потому что урок не открылся. Менеджер ищет платёж в кабинете, вручную добавляет человека на курс. А бухгалтер спрашивает, почему по одной покупке пришло два чека.

Форма сработала. Покупка — нет.

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

Допустим, школа продаёт курс за 80 000 ₽. Один ученик готов оплатить картой. Второй привык к СБП. Третьему нужна рассрочка. Четвёртый находится за границей и пишет менеджеру: «Не проходит оплата».

Фраза «приём платежей подключён» ничего не говорит о том, сможет ли каждый из них купить курс. В CloudPayments есть оплата картами, СБП, pay-методами и варианты оплаты частями. Какие именно методы будут доступны школе, зависит от подключения и условий. Я бы здесь начинал с простого вопроса: как сегодня пытаются платить ваши ученики и где именно у них не получается? Потом уже проверял нужные способы на тестовых покупках. Способы оплаты и решения Cloud для онлайн-образования можно посмотреть отдельно.

Сайт нужен не для каждой сделки. Бывает, менеджер поговорил с человеком, договорился об индивидуальной цене и отправил ссылку на оплату в Telegram. CloudPayments позволяет выставлять такие счета и платёжные ссылки.

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

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

У CloudPayments есть интеграция с GetCourse; для сайта на Tilda есть инструкция по подключению. Свою LMS или CRM можно связать с платёжными событиями через инструменты разработчика.

Но готовое подключение не знает, что именно продала школа. Например, после покупки курса кому-то нужно сразу открыть все уроки, кому-то — доступ только с даты старта, а по персональному предложению ещё уведомить менеджера. Эти правила школа задаёт сама. Наша задача — сделать так, чтобы событие оплаты запускало нужную цепочку, и проверить её целиком, а не только увидеть слово «Успешно» в платёжной форме.

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

Представим клуб за 4 900 ₽ в месяц. Первый платёж прошёл, доступ открылся. Через месяц карта ученика заблокирована и очередное списание не получилось. Доступ закрывать немедленно? Дать человеку время обновить карту? Напомнить ему об оплате? А если он отменил подписку за день до следующего периода?

У Cloud есть сервис подписок. Но сам по себе рекуррент не отвечает за все эти решения. Техспецу нужно вместе с заказчиком описать правила клуба, а затем связать статусы платежа с доступом, сообщениями и работой поддержки. Вот это уже отдельная услуга — запуск подписочной модели, а не просто «включить автосписание».

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

Поэтому сначала выясняем географию учеников, какие карты они используют, на каком шаге возникает ошибка. Затем согласовываем доступные варианты и тестируем весь путь: платёж, заказ, доступ, чек. Формулировка «у нас принимаются иностранные карты» бесполезна, если конкретный ученик всё равно не может оплатить.

Кстати, о партнёрке. Если вы подключаете заказчику CloudPayments, посмотрите агентскую программу Cloud. На публичной странице для этого продукта заявлено вознаграждение от 0,1% оборота привлечённого проекта. К условиям ещё вернёмся ниже.

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

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

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

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

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

Здесь есть чёткая граница, о которой лучше знать заранее: согласно справке Cloud, Cloud-чеки работают только при приёме платежей через CloudPayments. Если у школы другой эквайринг, его платежи не получится просто направить в Cloud-чеки. Тогда уже смотрят в сторону CloudKassir или другой подходящей кассовой схемы.

В GetCourse можно настроить отправку данных для чека. Связка CloudPayments с фискализацией тоже может это делать. Если оставить две независимые отправки на одну и ту же покупку, есть риск получить два чека. И техспецу приходится разбираться с проблемой, которую он сам же создал подключениями.

Поэтому я бы до настройки записал на одной странице: кто инициирует чек, откуда берутся позиции и сумма, где смотреть результат, что происходит при возврате. По курсу с оплатой до старта отдельно спросил бы бухгалтера, как оформлять предоплату и последующие события. У Cloud есть справка по чекам, а у GetCourse — материал по своей стороне фискализации.

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

Первый вопрос, который у меня возник: «Какие ещё чаевые? Мы же продаём курсы». А потом вспоминаешь, сколько у школ бесплатного контента: эфиры, открытые разборы, полезные статьи, встречи сообщества. Люди иногда хотят сказать спасибо автору или преподавателю и перевести деньги добровольно.

Для такого сценария у Cloud есть CloudTips. Можно создать страницу, взять ссылку или QR и разместить в Telegram, на эфире или в блоге. Для трансляций есть отдельные механики донатов.

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

Я бы не использовал донат как обход обычной продажи. Если «добровольные 3 000 ₽» обязательны, чтобы получить запись или доступ к курсу, по смыслу это плата за продукт. Для неё нужен нормальный платёжный и учётный сценарий. И рекламные формулировки о налогах для чаевых нельзя автоматически переносить на любой перевод школе или преподавателю: сначала смотрим, кто получает деньги и за что.

Что может сделать техспец? Собрать страницу, поставить ссылку в нужные каналы, вывести QR во время эфира, проверить путь зрителя с телефона. Иногда больше и не требуется: для базового сценария не нужно связывать донаты со всей системой продаж школы.

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

Я бы сформулировал услуги через ситуации клиента:

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

Раз уж техспец советует заказчику, как принимать деньги и формировать чеки, стоит знать про партнёрскую программу Cloud. По описанию компании, в ней могут участвовать ИП и юридические лица. Партнёр подаёт заявку, подписывает оферту, передаёт контакт потенциального клиента, а команда Cloud помогает с подключением. Статистика доступна в кабинете; выплаты компания описывает как регулярные, обычно ежемесячные.

На 24 сентября 2026 года на публичной странице указаны такие ориентиры:

Давайте переведу 0,1% в деньги, чтобы почувствовать масштаб. Если весь месячный оборот проекта в 1 млн ₽ участвует в расчёте по этой ставке, получится 1 000 ₽. При 5 млн ₽ — 5 000 ₽. Это арифметика, не обещание дохода: фактическая ставка, учитываемый оборот и начисления зависят от условий программы и проекта. Перед подключением их нужно уточнить у Cloud.

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

Школа уже арендует другую кассу. Если она устраивает заказчика, можно подключить CloudPayments для приёма денег и настроить передачу данных в действующую кассу. Здесь нужно заранее проверить совместимость и выбрать одну точку формирования чека.

Платежи уже идут через другой эквайринг. CloudKassir умеет работать с рядом других платёжных сервисов. Например, в документации есть интеграция с ЮKassa. Возможность и схему подключения проверяют для конкретной связки.

Клиенты платят на расчётный счёт. У CloudKassir описано формирование чека вручную без интернет-эквайринга. Если нужно делать это автоматически, придётся отдельно решить, откуда касса получит сведения об оплате и заказе.

CloudPayments уже подключён. Для его платежей можно рассмотреть Cloud-чеки или CloudKassir — выбор зависит от согласованной схемы школы. Но через Cloud-чеки нельзя пробивать платежи, прошедшие через другой эквайринг.

Хотят принимать благодарности после эфира. CloudTips может жить своей жизнью: ссылка в Telegram, QR на экране. Для этого не требуется перестраивать оплату курсов.

Короче, я бы начал не с вопроса «Какие сервисы Cloud подключим?», а с просьбы: «Покажите, как ученик у вас сейчас покупает курс — от первого клика до доступа и чека». На этом маршруте обычно видно, где действительно нужна новая связка. Если всё работает и новой задачи нет, трогать систему пока незачем.

Функции и публичные условия партнёрской программы сверены по официальным материалам Cloud 24 сентября 2026 года. Перед публикацией и подключением клиента стоит проверить их снова.