Школа IT юриста

Как устроены платежные сервисы: разбираем юридическую модель платежного сервиса



Рубрика: «Как у них устроено»
В IT-проектах за технологией почти всегда стоит сложная юридическая архитектура.
В новой рубрике «Как у них устроено» мы разбираем реальные цифровые сервисы и смотрим, как построена их юридическая модель:
·какая используется договорная конструкция
·нужна ли лицензия
·какие риски возникают у проекта
·какие правовые решения используются для масштабирования.
Начнём с сервиса приема платежей Unitpay

Что делает сервис Unitpay

По описанию функционала сервис предлагает:
• прием платежей из России и из-за рубежа
• альтернативу онлайн-кассам — Unit.Чеки
• собственное anti-fraud решение (3DS native)
• защиту данных по стандарту PCI DSS
• более 40 модулей интеграции для CMS и CRM
• вывод средств на расчетный счет на следующий день.
Когда юрист видит формулировку «прием платежей», возникает логичный вопрос:
нужна ли здесь банковская лицензия?

Нужна ли лицензия на прием платежей

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

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

По сути сервис представляет собой технологическую платформу, которая соединяет несколько участников платежа:
1️ банк
2️ плательщика
3️ получателя платежа.
В документах сервиса это описано следующим образом:
«Система Unitpay — совокупность программных средств, веб-форм, программно-аппаратных решений и объектов интеллектуальной собственности».
То есть юридическая модель выглядит так:
IT-продукт + договорная инфраструктура с финансовыми организациями.
Функция сервиса — предоставить технологическую инфраструктуру и интерфейс для обработки платежей.

Как проходит платеж в такой системе

На практике платежная архитектура обычно выглядит следующим образом.
Шаг 1. Пользователь оплачивает товар или услугу на сайте.
Шаг 2. Деньги поступают на счет платежного партнера (банка).
Шаг 3. Банк распределяет средства между участниками операции.
Шаг 4. Получатель платежа получает деньги.
Шаг 5. сервис получает комиссию за технологическое обслуживание.
В некоторых моделях используются так называемые транзитные счета, через которые банк распределяет поступившие средства.

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

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

1. Работа с персональными данными

Платежные сервисы обрабатывают большой объем персональных данных пользователей:
• ФИО
• телефоны
• email
• платежные реквизиты.
Это требует:
— правильно выстроенной архитектуры обработки персональных данных
— договоров с банками и партнерами
— соблюдения стандартов безопасности.
Особенно важно учитывать требования законодательства о персональных данных и стандартов безопасности платежной информации.

2. Передача данных третьим лицам

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

3. Лицензирование деятельности

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

4. Интеллектуальная собственность

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

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

Юрист, работающий с IT-бизнесом, должен понимать не только нормы законодательства, но и архитектуру цифровых продуктов.
Разбирая такие сервисы, можно увидеть:
• где проходит граница лицензируемой деятельности
• как устроены договорные модели финтех-проектов
• какие риски возникают при работе с платежами
• как технологические решения влияют на юридическую конструкцию бизнеса.
Именно такие вопросы сегодня чаще всего возникают у юристов технологических компаний.

Где учиться разбираться в юридической архитектуре IT-проектов

Если вы хотите глубже разобраться в том, как устроены юридические модели технологических сервисов, мы подробно разбираем такие кейсы на программе:
«Юрист IT-компании»
На программе изучаем:
• юридическую архитектуру цифровых продуктов
• лицензирование IT-проектов
• защиту интеллектуальной собственности
• работу с персональными данными
• юридические модели маркетплейсов, платформ и финтех-сервисов.
Подробнее о программе:
https://itpravo.tech/itlawyer#kurs

2026-03-13 15:56