Как мы построили платёжную систему маркетплейса: номинальный счёт, эквайринг и новая архитектура

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

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

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

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

Подробная информация по данному кейсу доступна по карточке ниже.

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

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

На платформе реализовано четыре сценария возврата денежных средств:

1.  Частичный выкуп — происходит при завершении заказа, когда покупатель выкупает только часть товаров. Оставшиеся денежные средства возвращаются покупателю.
2.  Полный возврат — происходит при отмене заказа, который ещё не был отправлен.
3.  Удержание двойной стоимости доставки — если покупатель отменяет заказ, который уже передан в транспортную компанию, с него удерживается удвоенная стоимость доставки.
4.  Удержание полной стоимости заказа — если удвоенная стоимость доставки превышает сумму заказа, покупателю ничего не возвращается, заказ завершается.

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

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

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

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

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

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

При успешном завершении продажи сделка исполняется, и денежные средства уходят продавцу. При отмене продажи сделка отменяется,
а нужная сумма возвращается по реквизитам плательщика.

Техническое взаимодействие с API банка оказалось несложным.
Все запросы подписываются с использованием RSA-шифрования.

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

Бенефициара необходимо создавать в номинальном счёте с данными
из профиля продавца. Банк не позволяет создать бенефициара
с некорректными данными — неверным ИНН, КПП, расчётным счётом
или БИК.

Решение: мы добавили проверку данных с помощью API банка на этапе регистрации продавца. Если данные невалидны — профиль просто
не создаётся. Это позволило убрать лишние проверки граничных случаев
и сделать систему проще и надёжнее.

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

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

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

На следующий день все денежные средства (уже за вычетом комиссии) поступают на номинальный счёт одним платежом.

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

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

Эквайринг раз в день отправляет денежные средства одним платежом на номинальный счёт. Если за день было принято 10 платежей по 100 рублей
от разных покупателей для разных продавцов — на номинальный счёт
это всё придёт одной суммой (за вычетом комиссии).

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

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

Расчёт может быть простым: например, 10 платежей по 100 рублей поступило, никто их не возвращал — система списывает комиссию
и идентифицирует суммы на 10 разных бенефициаров.

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

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

Особенности системы учёта

Система учёта платежей должна учитывать следующие параметры:

1.  Тип платежа — по карте или по счёту
2.  Дату платежа
3.  Статус заказа
4.  Сумму платежа с учётом комиссии эквайринга (комиссия списывается сразу)
5.  Факт и дату возврата
6.  Сумму возврата и свободную сумму для перераспределения
7.  Балансы бенефициаров должны копейка в копейку соответствовать действительности

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

Ключевые моменты, которые нужно учитывать:

• Комиссия эквайринга списывается сразу при поступлении платежа — это влияет на все расчёты возвратов и перераспределений
• Банковская система не позволяет идентифицировать платёж по частям — нужно сразу распределять консолидированный платёж по бенефициарам
• Валидацию данных продавцов лучше выносить на этап регистрации — это упрощает код и улучшает пользовательский опыт
• Система должна уметь перераспределять свободные средства между бенефициарами при возвратах
• Балансы должны соответствовать действительности с точностью до копейки

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