CloudPayments: приём платежей и подписок через банковский эквайринг

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

Что такое CloudPayments простыми словами

CloudPayments — российский провайдер платёжного шлюза, то есть технического сервиса, который принимает оплату на твоём сайте или в приложении и передаёт платёж в банк. Покупатель может заплатить банковской картой, через СБП (Систему быстрых платежей), Apple Pay или Google Pay — прямо на твоей странице, без перехода на сторонний сайт кассы.

Ключевое слово здесь — «эквайринг». Эквайринг — это услуга банка по приёму карточных платежей: именно банк-эквайер общается с платёжными системами (Мир, Visa, Mastercard), проводит деньги с карты покупателя и зачисляет выручку на твой расчётный счёт. CloudPayments работает с несколькими банками-эквайерами и выступает технической прослойкой между твоим приложением и банком: даёт готовый виджет оплаты, API, обработку подписок и уведомления, а денежную часть проводит банк, с которым ты заключаешь договор.

Хорошая аналогия — касса ресторана внутри торгового центра. Торговый центр (CloudPayments) даёт тебе кассовое оборудование, очередь покупателей и стандарты работы, но договор аренды и расчёты у тебя напрямую с владельцем площади (банком). Сравни с ЮKassa: там сервис сам является твоим «арендодателем» для платежей — один договор с агрегатором закрывает всё.

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

Из этого раздела унеси четыре термина, которые встретятся в личном кабинете и документации:

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

Чем CloudPayments отличается от ЮKassa

ЮKassa мы уже подробно разбирали в статье «Как подключить ЮKassa» — если нужен пошаговый разбор именно её, начни оттуда. Здесь — только сравнение.

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

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

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

Чем CloudPayments отличается от Prodamus

Prodamus мы тоже уже разбирали: «Prodamus: приём платежей и подписок». Это тоже агрегатор, но с ярко выраженной специализацией — он заточен под инфобизнес и онлайн-курсы: автоматическая выдача доступа к материалам после оплаты, готовые интеграции с платформами обучения, рассрочка для учеников, страницы продаж.

CloudPayments — универсальный эквайринг для любого интернет-магазина или приложения, без привязки к инфобизнесу. Его сильная сторона — не обвязка для курсов, а надёжность прямого банковского договора и гибкий API. Никакой «автоматической выдачи доступа к урокам» из коробки там нет: логику «оплатил → получил доступ» ты реализуешь сам в своём приложении — впрочем, для тебя это плюс, потому что доступ к функциям твоего приложения всё равно открывает твой собственный код.

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

Важный нюанс, который часто упускают: это не вопрос «навсегда». Между сервисами можно мигрировать, пока логика оплаты в твоём приложении не размазана по всему коду, а собрана в одном модуле. Скажи об этом ИИ-ассистенту прямо при подключении: «вынеси работу с платёжным сервисом в отдельный модуль, чтобы при смене провайдера менять только его». Такая просьба стоит одно предложение, а экономит недели при будущем переезде.

Зачем это вайбкодеру на курсе

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

CloudPayments стоит рассматривать в двух ситуациях:

• Тебе нужны именно автоматические списания по подписке — и ты готов сам описать ИИ логику «списать сумму X каждый месяц, при успехе продлить доступ, при неудаче — повторить попытку». API CloudPayments это позволяет, а ИИ-ассистент напишет такой код по твоей задаче.
• Низкая комиссия важнее простоты подключения. Если у тебя уже есть ИП или ООО и ты рассчитываешь на заметный оборот, прямой договор с банком через CloudPayments может обойтись дешевле агрегатора на каждом платеже. На старте разница копеечная, но при росте оборота проценты превращаются в ощутимые суммы.

Если же ты хочешь просто проверить гипотезу «купит ли кто-нибудь мою игру» без оформления документов — CloudPayments не лучший первый шаг: начни с ЮKassa или Prodamus, а к прямому эквайрингу вернись, когда появятся обороты и ИП.

Есть и третий, менее очевидный резон знать про CloudPayments, даже если подключать его ты будешь не скоро. Механика «виджет → webhook → доступ» устроена одинаково почти у всех платёжных сервисов: разобравшись с ней здесь, ты поймёшь любой другой шлюз в разы быстрее. Это как с первым языком программирования: конкретный синтаксис забудется, а модель «как всё устроено» останется навсегда и перенесётся на любой инструмент.

И не перепутай направление денег: CloudPayments решает, как тебе принимать рубли от российских покупателей. А чтобы тебе самому оплачивать зарубежные сервисы и инструменты разработки, нужна другая схема — она разобрана в статье «Зарубежная карта для оплаты».

Как это работает на практике

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

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

Шаг 2. Зарегистрируйся в CloudPayments и выбери банк-партнёр. Сервис работает с несколькими банками-эквайерами. Ты подаёшь заявку, и дальше заключаешь договор эквайринга напрямую с банком — CloudPayments помогает пройти этот процесс, но стороной договора выступает банк.

Шаг 3. Получи API-ключи. После подключения у тебя появляются два идентификатора: Public ID — публичный ключ, который используется в виджете на странице, и API Secret — секретный ключ для запросов с твоего сервера. Секретный ключ нельзя вшивать в код страницы или публиковать в репозитории: он живёт только на сервере, в переменных окружения.

Шаг 4. Встрой оплату. Есть два пути. Простой — встроить готовый виджет оплаты: пара строк JavaScript на странице, и у покупателя появляется форма для карты, СБП, Apple Pay или Google Pay. Гибкий — работать через API: твой сервер сам создаёт платёж и управляет подписками. Для подписки обычно комбинируют: первый платёж проходит через виджет (покупатель вводит карту и подтверждает списание), а дальнейшие списания твой сервер делает по API без участия покупателя.

Шаг 5. Настрой webhook. Webhook — это адрес на твоём сервере, куда CloudPayments отправляет уведомления о событиях: «платёж прошёл», «списание по подписке не удалось», «деньги возвращены». Именно по webhook твой код решает, что оплата состоялась, и открывает пользователю доступ. Никогда не открывай доступ по факту «пользователь вернулся на страницу успеха» — только по уведомлению от сервера платежей: страницу успеха легко подделать, webhook — нет.

Шаг 6. Протестируй и запусти боевой режим. На этапе разработки удобно тестировать webhook локально: сервису нужен публичный адрес, а твой компьютер его не имеет. Здесь помогает ngrok — утилита, которая даёт твоему локальному серверу временный публичный адрес, чтобы платёжный сервис мог прислать уведомление прямо на твою машину во время отладки.

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

flowchart TB
    U["Пользователь оплачивает"] --> W["Виджет CloudPayments"]
    W --> B["Банк-эквайер проводит платёж"]
    B --> H["Webhook уведомляет твой сервер"]
    H --> D["Доступ к подписке открыт"]

Как устроены рекуррентные платежи под капотом

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

Первый платёж всегда делает человек. Покупатель вводит данные карты в виджете на твоей странице, подтверждает оплату (обычно через 3-D Secure — код из SMS или push от банка) и отдельно соглашается на регулярные списания. Без этого первого сознательного действия автоматических списаний быть не может: ни один сервис не списывает деньги с карты, которую «просто знает».

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

Дальше списания инициирует твой сервер. Раз в месяц (или с другим периодом) твой код отправляет через API запрос «списать столько-то по этому токену». Покупатель в это время может спать — его участие не нужно. Расписание, суммы и логика «у кого подписка заканчивается завтра» — полностью твоя зона ответственности, и это тот самый код, который за тебя пишет ИИ.

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

Отмена должна быть честной. Пользователь в любой момент может отменить подписку — и твой сервер обязан прекратить списания. Спрячешь отмену в три клика глубоко или «забудешь» её реализовать — получишь жалобы, возвраты платежей (chargeback) и проблемы с банком-эквайером, вплоть до расторжения договора. Простая и заметная кнопка отмены — это не щедрость, а защита твоего договора.

Как поставить задачу ИИ, чтобы он подключил оплату

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

Плохой вариант: «Прикрути оплату к приложению». ИИ сделает что-нибудь — скорее всего, не то: без webhook, с ключами в коде, без тестового режима.

Хороший вариант описывает сценарий целиком, по шагам:

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

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

Чек-лист «Оплата готова к запуску»

• Оформлено ИП или ООО, открыт расчётный счёт.
• Заключён договор эквайринга с банком-партнёром через CloudPayments.
• Условия договора — комиссия, сроки зачисления, возвраты — уточнены у банка и записаны.
• Получены Public ID и API Secret, секрет хранится в переменных окружения.
• Виджет оплаты встроен на страницу подписки.
• Webhook настроен и отвечает успешным кодом.
• Доступ открывается только по webhook, не по странице успеха.
• Вся цепочка прогнана на тестовых картах: успех, отказ и повторное списание.
• Реализованы повторные попытки списания и отмена подписки.
• Решён вопрос с кассовыми чеками по 54-ФЗ.
• Конфигурация переключена на боевые ключи — осознанно, после всех проверок.

Есть ли тестовый режим

Да. У CloudPayments есть тестовый режим (песочница) с тестовыми картами: ты проходишь весь путь платежа — форму, подтверждение, webhook, — но реальные деньги никуда не двигаются. Тестовая карта ведёт себя как настоящая: можно проверить и успешную оплату, и отказ по нехватке средств.

Это важно не формально, а практически. Подписка — механизм с множеством веток: первый платёж прошёл, а очередное списание упало; пользователь отменил подписку; карта протухла. Всё это нужно прогнать в тестовом режиме до запуска боевых платежей, иначе первым тестировщиком станет реальный покупатель. Правило простое: пока вся цепочка «оплатил → webhook пришёл → доступ открылся → списание в следующем месяце прошло» не воспроизведена на тестовых картах, боевой режим не включаем.

Учти ещё два момента. Во-первых, тестовый и боевой режимы — это два отдельных мира с разными ключами: уведомления из тестового не приходят в боевой и наоборот. Во-вторых, тестовый режим проверяет технику, но не реальное поведение банков: в боевом режиме добавляются 3-D Secure, антифрод-проверки и реальные отказы карт. Поэтому после запуска первую неделю наблюдай за платежами вживую: смотри, какие списания проходят, какие падают и почему.

Сколько это стоит

Точной единой цены нет, и это принципиально. Комиссия при прямом эквайринге зависит от договора с конкретным банком, твоего оборота и категории бизнеса — поэтому цифры ты увидишь на сайте сервиса и в своём договоре после регистрации и согласования условий. Любая «точная цифра комиссии CloudPayments» из статьи двухмесячной давности — почти наверняка устарела, поэтому мы её здесь и не приводим: смотри актуальные тарифы на сайте.

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

Помимо процента с платежа, при сравнении вариантов смотри и на менее очевидные вещи: срок зачисления выручки на расчётный счёт (у разных банков он разный, а для молодого проекта скорость оборота денег бывает важнее десятых долей процента), условия по возвратам и спорным операциям, а также стоимость смежных услуг вроде онлайн-кассы, если она не входит в договор. Всё это — вопросы к банку на этапе согласования, до подписания договора.

Ограничения

Чтобы картина была честной, перечислим, где CloudPayments не подходит:

• Сложное подключение. Нужен отдельный договор с банком, пакет документов, согласование. Это дни и недели, а не «зарегистрировался за вечер».
• Не подойдёт без ИП или ООО. Банк заключает договор эквайринга только с предпринимателем или юрлицом. Если статуса нет и платежи пока единичные — начни с агрегатора, который работает с самозанятыми, или отложи монетизацию.
• Избыточен для разовых продаж. Если ты продаёшь один цифровой продукт пару раз в месяц, преимущество в комиссии не окупит сложность подключения.
• Логику подписки пишешь сам. В отличие от сервисов для инфобизнеса, здесь нет готовой «выдачи доступа»: webhook-обработчик, продление и отмена подписки — это код твоего приложения. С ИИ-ассистентом это посильная задача, но это задача.
• Нужен живой сайт с описанием продукта. Банк при подключении проверяет, что и кому ты продаёшь: страница с описанием приложения, ценами и условиями должна существовать и соответствовать действительности.
• Комиссия не фиксирована заранее. Итоговые условия ты узнаешь только при заключении договора с банком — закладывай это в планирование.

Типичные ошибки при подключении

Эти промахи встречаются у новичков чаще всего — проверь себя по списку до запуска.

Открытие доступа по странице успеха, а не по webhook. Страницу «оплата прошла» покупатель видит в браузере, и её можно подделать или открыть без оплаты. Единственный достоверный источник правды — уведомление от сервера платежей на твой webhook. Доступ открываем только по нему.

Утечка API Secret. Секретный ключ, случайно закоммиченный в публичный репозиторий или вшитый в код страницы, позволяет кому угодно делать запросы от имени твоего магазина — включая возвраты. Ключи хранятся в переменных окружения и файлах, исключённых из git. Если ключ засветился — немедленно перевыпусти его в личном кабинете.

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

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

Игнорирование фискализации. Онлайн-оплата в России требует выдачи покупателю кассового чека по закону 54-ФЗ. Уточни при заключении договора, как эта часть решается в твоей связке «банк + шлюз», — не доводи до первой проверки.

Попытка обойтись без ИП «на время». Принимать оплату за подписку как физлицо через прямой эквайринг не получится — банк просто не заключит договор. Это не препятствие, а сигнал: либо оформляй статус, либо начинай с агрегатора, который работает с самозанятыми.

Важная оговорка

Эта статья — обзор возможностей сервиса, а не юридическая или бухгалтерская консультация. Договор эквайринга — это финансовый договор с банком: условия, комиссии, сроки зачисления выручки и требования к документам у каждого банка свои и со временем меняются. Перед подключением свяжись с банком напрямую и уточни точные условия именно для твоей ситуации — вида деятельности, оборота и формы (ИП или ООО). Налоговые вопросы — какую систему налогообложения выбрать и как учитывать выручку от подписок — обсуждай с бухгалтером, а не со статьями в интернете, включая эту.

Частые вопросы

Можно ли подключить CloudPayments физлицу или самозанятому?

Нет: прямой договор эквайринга банк заключает с ИП или ООО. Если статуса пока нет, смотри в сторону агрегаторов, которые работают с самозанятыми, — например, ЮKassa.

CloudPayments хранит данные карт моих покупателей?

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

Что такое Public ID и API Secret и куда их вписывать?

Public ID — публичный идентификатор, он используется в виджете на странице и не является секретом. API Secret — секретный ключ для серверных запросов: создания платежей, списаний по подписке, возвратов. Он должен жить только на сервере в переменных окружения и никогда не попадать в код страницы, репозиторий или сообщения чатам.

Как подписка списывает деньги без участия покупателя?

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

Что делать, если webhook не приходит?

Проверь, что адрес webhook указан правильно и твой сервер отвечает на него успешным кодом. При локальной разработке помни: платёжный сервис не достучится до твоего компьютера без публичного адреса — используй ngrok или подобный туннель. Также убедись, что ты смотришь логи того окружения, где платил: тестовое и боевое раздельны.

CloudPayments или ЮKassa — что выбрать на старте?

Если нет ИП/ООО или нужен быстрый запуск — ЮKassa. Если статус есть, планируется подписка с заметным оборотом и важна комиссия — имеет смысл считать CloudPayments. Многие проекты стартуют на агрегаторе, а прямой эквайринг подключают позже, когда обороты оправдывают возню с документами.

Честный вывод

CloudPayments — хороший вариант, когда у тебя уже есть ИП или ООО, продукт построен на подписке и низкая комиссия с рекуррентными платежами важнее простоты подключения. Прямой договор с банком-эквайером требует больше документов и времени, но даёт контроль, надёжность банковской инфраструктуры и обычно более выгодные условия при росте оборота. Для быстрого старта без оформления проще начать с ЮKassa или Prodamus — и это нормальный путь: сменить платёжного провайдера позже проще, чем кажется, особенно если логика оплаты в твоём приложении с самого начала отделена от конкретного сервиса.

И последнее. Ни один платёжный сервис сам по себе не сделает продукт прибыльным: выручка зависит от того, насколько приложение нужно людям и как ты его продвигаешь, а не от выбора эквайера. Эквайер — это труба, по которой текут деньги от покупателей к тебе. Сначала должно появиться то, что в эту трубу потечёт.