Как у них всё устроено: CloudPayments — IT-сервис, который помогает принимать платежи, но не становится банком

Запускаю рубрику «Как у них всё устроено».

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

— кто заключает договор с клиентом;— кто фактически оказывает регулируемую услугу;— от чьего имени действует платформа;— как распределены деньги, данные и ответственность;— за счет какой конструкции компания сохраняет статус IT-бизнеса.

Первый проект — CloudPayments.

CloudPayments — российский сервис интернет-эквайринга. Он помогает интернет-магазинам, онлайн-сервисам, образовательным платформам, микрофинансовым организациям и другим компаниям принимать платежи на сайтах и в приложениях.

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

Но юридически за одной кнопкой оплаты скрывается несколько участников и несколько договорных уровней.

CloudPayments основали в 2014 году Дмитрий Спиридонов и Константин Ян.

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

В этой заметке сосредоточимся на том, как CloudPayments работает с клиентами и почему сервис, фактически обеспечивающий прием онлайн-платежей, не становится банком.

Упрощенно пользовательский сценарий выглядит так:

Из интерфейса может показаться, что CloudPayments самостоятельно оказывает услугу эквайринга и проводит платеж.

Но договорная модель устроена иначе.

В базовой модели есть как минимум четыре участника:

— покупатель;

— интернет-магазин или другой получатель платежа;

— CloudPayments;

— банк.

В договоре CloudPayments называет себя агрегатором, а подключаемый бизнес — предприятием.

Банк обеспечивает проведение расчетов и банковскую часть операции. CloudPayments отвечает за информационно-технологическое взаимодействие между бизнесом, покупателем и платежной инфраструктурой.

Именно это разделение функций лежит в основе всей модели.

Основной договор называется договором об информационно-технологическом взаимодействии.

По нему CloudPayments оказывает бизнесу IT-услуги. В частности:

— собирает, обрабатывает и передает информацию о переводах физических лиц в пользу компании;

— обеспечивает технологическое взаимодействие при приеме платежных карт;

— предоставляет платежный интерфейс, API и личный кабинет;

— обеспечивает передачу запросов и уведомлений;

— предоставляет дополнительные инструменты, связанные с приемом платежей.

Собственная ценность CloudPayments находится именно в технологическом слое:

— платежных формах;— интеграциях;— API;— автоматизации регулярных платежей;— уведомлениях;— аналитике;— личном кабинете;— дополнительных способах оплаты.

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

Для обеспечения расчетов CloudPayments действует от имени выбранного банка и заключает с компанией договор об осуществлении расчетов по интернет-платежам.

Упрощенно схема выглядит так:

Компания заключает договор с CloudPayments.

CloudPayments от имени банка присоединяет компанию к условиям расчетов.

Банк проводит платежи и перечисляет деньги компании.

Получается двухуровневая модель.

CloudPayments обеспечивает:

— интерфейс;

— интеграцию;

— обработку и передачу информации;

— личный кабинет;

— уведомления;

— дополнительные технологические функции.

Банк:

— участвует в авторизации операции;

— осуществляет перевод денежных средств;

— производит расчеты с компанией;

— выполняет функции регулируемого финансового участника.

Для клиента это один сервис. Юридически — несколько связанных отношений.

CloudPayments не принимает на себя роль кредитной организации.

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

Это позволяет развивать платежный продукт без собственной банковской лицензии.

Но одной формулировки «мы IT-компания» для этого недостаточно. Фактическая модель должна соответствовать договору:

— банковские функции остаются у банка;— деньги переводятся в рамках банковской инфраструктуры;— CloudPayments обеспечивает технологическое взаимодействие;— роли и полномочия участников закреплены в документах.

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

Эта архитектура позволяет разделить:

— регулируемую финансовую функцию;

— самостоятельный IT-продукт.

У CloudPayments есть собственное программное обеспечение, интерфейсы, API, интеграции и технологическая инфраструктура.

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

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

Архитектура «банк проводит платеж — IT-компания обеспечивает технологический продукт» позволяет разделить эти функции гораздо яснее.

В судебных спорах CloudPayments участвует как третье лицо — сервис-провайдер, через который технически проводилась оплата.

Например, в постановлении Арбитражного суда Московского округа от 19.02.2024 № Ф05-33179/2023 по делу № А40-245686/2022 суд указал, что сервис-провайдером по договору выступало ООО «Клаудпэйментс».

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

Разумеется, конкретная квалификация зависит от обстоятельств отдельного спора. Но сама договорная конструкция поддерживает роль агрегатора, а не непосредственного продавца или банка.

Теперь посмотрим внимательнее на условия договора CloudPayments с подключаемым бизнесом.

Основной документ представляет собой договор присоединения.

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

Фактически комплект документов состоит из нескольких элементов:

— основного договора об информационно-технологическом взаимодействии;

— заявления о присоединении;

— условий осуществления расчетов;

— тарифов;

— документов по отдельным дополнительным сервисам.

Это не одна простая оферта на «прием денег», а связанная договорная система.

Для подключения компания подает заявление и указывает:

— данные юридического лица или ИП;

— сведения о магазине или сервисе;

— расчетный счет;— выбранный банк;

— тарифы;

— технические параметры подключения.

Акцепт подтверждается в том числе верификационным платежом в размере одного рубля.

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

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

Единой ставки в публичном договоре нет.

Комиссия:

— согласовывается с конкретной компанией;

— фиксируется в заявлении;

— может отображаться в личном кабинете;

— может отличаться в зависимости от способа оплаты;

— может включать минимальную сумму за операцию.

Поэтому при проверке договора недостаточно прочитать только общие условия. Нужно отдельно анализировать заявление и согласованные тарифы.

По общей модели банк перечисляет деньги компании после обработки операций.

Сумма перечисляется за вычетом:

— комиссии;

— возвратов;

— удержаний по спорным операциям;

— иных сумм, предусмотренных договором.

Срок зависит от условий расчетов и может отличаться по отдельным способам оплаты.

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

Возврат покупателю должен проводиться через предусмотренный договором механизм — как операция возврата.

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

При этом ранее удержанная комиссия может не возвращаться.

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

Таким образом, возврат стоимости товара не всегда означает возврат всех расходов, которые понес бизнес при исходной операции.

Договор позволяет удерживать из выплат компании:

— суммы возвратов;

— требования по опротестованным операциям;

— суммы спорных транзакций;

— штрафы;

— иные предусмотренные договором требования.

Также могут применяться механизмы заранее данного акцепта на списание средств со счетов компании в банке.

Для бизнеса это одна из ключевых зон риска.

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

Компания должна быть готова подтвердить реальность каждой операции.

В зависимости от характера бизнеса такими доказательствами могут быть:

— заказ;

— чек;

— договор;

— акт;

— накладная;

— переписка с клиентом;

— подтверждение доставки;

— лог использования цифрового продукта;

— подтверждение предоставления доступа.

Проблемы возникают, если:

— покупатель оспаривает операцию;

— отсутствует подтверждение передачи товара или оказания услуги;

— операция признана подозрительной;

— данные платежа не совпадают с информацией о заказе;

— сайт или пользовательский сценарий не соответствуют требованиям.

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

Физической накладной у таких проектов обычно нет.

CloudPayments может приостановить информационно-технологическое взаимодействие, если:

— банк прекратил обработку операций;

— компания нарушает договор;

— изменился домен или модель бизнеса без уведомления;

— возник риск существенных убытков;

— появились требования закона или регулятора;

— деятельность компании вызывает повышенные финансовые или репутационные риски.

Это означает, что прием платежей зависит не только от технической доступности сервиса.

Платежная инфраструктура может быть отключена и по юридическим, комплаенс- или репутационным причинам.

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

CloudPayments и банк не становятся стороной основного договора между продавцом и покупателем.

Компания самостоятельно отвечает за:

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

Если покупатель недоволен товаром, курсом, подпиской или сервисом, основной спор возникает с продавцом.

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

В договоре компания признается оператором персональных данных и поручает CloudPayments обработку данных покупателей.

Обрабатываться могут:

— ФИО;

— телефон;

— электронная почта;

— сведения о заказе;

— данные платежного средства;

— иная информация, необходимая для проведения платежа и отображения операции в личном кабинете.

CloudPayments принимает на себя обязанности по конфиденциальности, защите данных и соблюдению требований к их обработке.

Но наличие условия о поручении не освобождает саму компанию от собственной ответственности.

Интернет-магазину или онлайн-сервису нужно:

— определить основание обработки;

— уведомить пользователя;

— описать передачу данных платежному сервису;

— включить интеграцию в политику ПДн;

— проверить формы и чекбоксы;

— синхронизировать договор с фактическим обменом данными через API.

Платежная интеграция одновременно является и интеграцией по персональным данным.

При некоторых способах интеграции компания получает доступ к реквизитам платежных карт или влияет на их обработку.

В таком случае могут применяться требования PCI DSS и дополнительные требования информационной безопасности.

Компания отвечает за:

— сохранность логинов и секретных ключей;

— безопасность собственного сайта;

— действия разработчиков и подрядчиков;

— ограничение доступа к платежным данным;

— уведомление о возможных инцидентах.

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

Готовый платежный виджет и самостоятельная обработка карточных реквизитов — это не одно и то же с точки зрения ответственности.

Нет.

Программное обеспечение и интеграция предоставляются с ограниченными гарантиями. CloudPayments не обещает абсолютного отсутствия ошибок и непрерывной работы.

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

Если исполнение зависит от банка, платежной системы и внешнего агрегатора, эти ограничения нужно учитывать:

— в пользовательском соглашении;

— в SLA;

— в правилах оплаты;

— в плане аварийного восстановления;

— в резервных способах приема платежей.

CloudPayments вправе обновлять публичные условия.

Новая редакция публикуется на сайте и становится обязательной в установленный договором срок.

Для бизнеса это означает, что договор нельзя один раз скачать при подключении и забыть.

Нужен процесс контроля изменений:

— кто отслеживает новые редакции;

— кто оценивает влияние изменений;

— нужно ли обновлять собственные документы;

— изменились ли тарифы, порядок удержаний или требования безопасности.

Особенно важно это для компаний, у которых платежный сервис критически влияет на выручку.

Упрощенно путь операции можно представить так:

Покупатель видит одну кнопку.

За ней находятся:

— сайт продавца;— программное обеспечение CloudPayments;— API;— банк;— платежная система;— договоры;— правила обработки данных;— механизмы безопасности;— порядок возвратов и оспаривания операций.

CloudPayments — хороший пример архитектуры цифрового сервиса, работающего внутри регулируемой отрасли.

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

Можно встроить лицензированного участника в продуктовую модель.

Один документ не всегда способен одновременно описать:

— IT-услуги;

— банковскую операцию;

— полномочия представителя;

— обработку ПДн;

— тарифы;

— возвраты;

— безопасность;

— дополнительные сервисы.

Связка документов зачастую точнее отражает реальный продукт.

Договорная конструкция должна совпадать с тем, что происходит в пользовательском сценарии и API.

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

CloudPayments не просто направляет клиента в банк.

Сервис создает отдельный технологический продукт:

— интерфейс оплаты;

— API;

— подписки;

— интеграции;

— уведомления;

— личный кабинет;

— аналитику;

— автоматизацию.

Именно наличие самостоятельной IT-ценности позволяет компании оставаться технологическим сервисом.

CloudPayments — не просто платежная кнопка и не банк.

Это технологическая платформа, которая:

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

А основной договор показывает, что подключение платежного сервиса — это гораздо больше, чем согласование комиссии.

Юристу нужно понять:

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

Именно это отличает юридическую архитектуру продукта от обычной оферты.

В следующем выпуске рубрики «Как у них всё устроено» разберем другой цифровой сервис — его продуктовую модель, договоры и распределение ответственности.