Сплит-платежи и расчёты с поставщиками в маркетплейсе на 1С-Битрикс

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

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

Маркетплейс-модель на Битрикс и зачем сплитование

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

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

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

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

Что такое сплитование платежей ЮKassa

У ЮKassa решение для маркетплейсов исторически называлось «Безопасная сделка», сейчас в документации оно проходит как «Сплитование платежей». Суть в том, что при одной оплате покупателя сервис умеет распределить сумму между несколькими получателями и отдельно удержать комиссию площадки. Для площадки это готовый инструмент, который избавляет от необходимости самостоятельно вести субсчета и гонять переводы между продавцами.

Механика на верхнем уровне выглядит так. У площадки есть основной магазин в ЮKassa (shopId площадки). Каждый продавец, который хочет продавать на площадке, регистрируется как отдельный получатель средств — ему заводится свой субсчёт и идентификатор. Когда покупатель оплачивает заказ, площадка при создании платежа передаёт не одну сумму, а массив «получатель → сумма → назначение». Сервис принимает деньги, а затем разводит их согласно этой разбивке.

Ключевые понятия, которыми оперирует сплитование:

• Получатель средств (recipient). Продавец, зарегистрированный в системе площадки и имеющий свой субсчёт. У него есть идентификатор, который передаётся в разбивке платежа.
• Трансфер (transfer). Часть платежа, которая адресована конкретному получателю. В одном платеже несколько трансферов — по числу продавцов в заказе.
• Комиссия платформы (platform_fee). Сумма, которую площадка удерживает с трансфера в свою пользу как вознаграждение агента.
• Баланс продавца. Накопленные на субсчёте средства, из которых потом делаются выплаты на банковский счёт продавца и покрываются возвраты.

Важный нюанс: сплитование — это отдельный продукт со своим подключением и модерацией. Его нужно активировать в личном кабинете ЮKassa и пройти проверку, а продавцов — заводить через API регистрации получателей. Это не «включается галочкой» в стандартном платёжном модуле Битрикса, поэтому под маркетплейс обработчик оплаты почти всегда дорабатывается. О базовом подключении приёма оплаты и СБП мы отдельно писали в материале про подключение ЮKassa и СБП — сплитование строится поверх этого фундамента.

Распределение суммы заказа между продавцами и площадкой

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

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

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

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

Чеки для каждого продавца по 54-ФЗ и роль агента

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

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

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

Что нужно передавать в составе чека, чтобы он был корректным:

• Позиции с привязкой к продавцу. Каждая строка чека относится к своему поставщику; система бьёт отдельные чеки по продавцам.
• Признак агента. Указывается, что площадка — агент/комиссионер, а поставщик товара — другое лицо.
• Данные поставщика. Наименование и ИНН продавца, чей товар в позиции.
• Ставка НДС по каждой позиции. Продавцы могут быть на разных системах налогообложения, поэтому НДС указывается на уровне позиции, а не заказа.
• Признак способа и предмета расчёта. Полная оплата, предоплата, товар/услуга — по правилам 54-ФЗ.

Хранение реквизитов и статусов продавцов

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

• Идентификатор получателя в ЮKassa. Тот самый recipient/субсчёт, на который уходит трансфер. Без него продавца нельзя включить в сплит.
• Юридические реквизиты. Наименование, ИНН, ОГРН/ОГРНИП, форма (ООО, ИП, самозанятый) — для чеков и договоров.
• Система налогообложения и ставка НДС. Определяют, как считать НДС в позициях чека.
• Банковские реквизиты для выплат. Куда сервис перечисляет накопленный баланс.
• Ставка комиссии площадки. Может быть общей или индивидуальной для продавца/категории.
• Статус. Прошёл ли продавец модерацию, активен ли, не заблокирован ли — от этого зависит, можно ли включать его товары в продажу.

В 1С-Битрикс продавцов удобно хранить в отдельном инфоблоке «Продавцы» (или highload-блоке, если полей много и они однородны). Каждый товар каталога получает свойство-привязку к элементу этого инфоблока — свойство «Продавец». Тогда по любому товару в заказе можно мгновенно получить продавца и все его реквизиты. Личный кабинет поставщика (список товаров, заказы, баланс, выплаты) строится как раздел сайта с доступом по роли — здесь пригодится опыт построения дилерских и B2B-кабинетов.

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

Заказ с товарами разных продавцов: разбиение на отгрузки

Покупатель не должен думать о том, что его корзина собрана из товаров пяти продавцов. Для него это один заказ, одна оплата, один статус «в целом». Но внутри системы такой заказ живёт сложнее, и правильный способ это отразить в 1С-Битрикс — разбить заказ на несколько отгрузок (доставок), по одной на каждого продавца.

Модель заказа в Битриксе это позволяет: у одного заказа (Order) может быть несколько отгрузок (Shipment), а каждая отгрузка содержит свой набор позиций. Логично сгруппировать позиции по продавцу и создать отгрузку под каждого. Тогда каждая отгрузка получает собственный жизненный цикл: один продавец уже собрал и передал товар в доставку, второй ещё комплектует, третий отменил свою позицию из-за отсутствия на складе. Заказ при этом не блокируется целиком.

Что даёт разбиение на отгрузки по продавцам:

• Независимые статусы. Каждый продавец двигает свою отгрузку, не мешая другим.
• Корректные выплаты. Выплата продавцу привязывается к факту выполнения именно его отгрузки.
• Частичные возвраты. Вернуть товар одного продавца можно, не трогая остальные отгрузки заказа.
• Прозрачная логистика. Разные продавцы могут отправлять товар разными службами и в разные сроки.
• Понятная аналитика. Легко считать метрики по каждому поставщику — оборот, возвраты, сроки.

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

Возвраты и отмены при сплите

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

ЮKassa поддерживает частичные возвраты по сплит-платежам: в запросе на возврат указывается сумма и получатель, с чьего баланса она списывается. Это позволяет вернуть покупателю стоимость одной позиции, забрав деньги с конкретного продавца. Общая логика возврата при сплите такая:

1. Определите, чей товар возвращается. По позиции возврата находим продавца и его отгрузку в заказе.
2. Посчитайте сумму возврата. Стоимость возвращаемых позиций плюс, при необходимости, доля доставки и часть комиссии по правилам договора.
3. Проверьте баланс продавца. На субсчёте должно хватать средств. Если денег недостаточно (уже выведены), возврат закрывается за счёт площадки с последующим взысканием с продавца.
4. Оформите возврат в ЮKassa. Частичный refund с указанием суммы и получателя, у которого списывается доля.
5. Пробейте чек возврата. Фискальный чек с признаком «возврат прихода» по правилам 54-ФЗ, с данными того же продавца.
6. Обновите заказ. Отметьте возврат в соответствующей отгрузке, скорректируйте статусы и расчёты.

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

Механику возвратов и отмен именно на стороне Битрикса — статусы, откат отгрузок, возврат на баланс покупателя — мы детально разбирали в отдельной статье про возвраты и отмены заказов в 1С-Битрикс. При сплите эта логика дополняется адресностью: важно не просто откатить заказ, а вернуть деньги с правильного продавца.

Сверка расчётов и выплаты поставщикам

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

Что сверяется и зачем:

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

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

Юридическая схема: агентский договор

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

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

Что обязательно должно быть зафиксировано в договоре:

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

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

Реализация в 1С-Битрикс: заказ, свойства, обработчик

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

1. Инфоблок «Продавцы». Заведите отдельный инфоблок (или highload-блок) с элементами-продавцами. Поля: идентификатор получателя ЮKassa, ИНН и реквизиты, система налогообложения и ставка НДС, ставка комиссии, банковские реквизиты, статус.
2. Свойство «Продавец» у товара. Добавьте в инфоблок каталога свойство типа «Привязка к элементам инфоблока», указывающее на продавца. Заполняйте его при заведении/импорте товара. Теперь по любой позиции заказа доступен продавец.
3. Личный кабинет поставщика. Раздел сайта с доступом по роли: свои товары, свои заказы/отгрузки, баланс, история выплат. Здесь пригодится опыт дилерских кабинетов и B2B-порталов.
4. Разбиение заказа на отгрузки. На событии создания заказа (или в кастомном шаге оформления) сгруппируйте корзину по продавцу и создайте отгрузку под каждого продавца.
5. Кастомный платёжный обработчик. Скопируйте базовый обработчик ЮKassa и доработайте формирование запроса на оплату: добавьте массив трансферов по продавцам, комиссию площадки и состав чека с привязкой позиций к продавцам.
6. Обработка вебхуков. Настройте приём уведомлений ЮKassa (оплата прошла, возврат, выплата) и обновляйте статусы заказа, отгрузок и баланс продавца.
7. Сверка и выплаты. Агент по расписанию сверяет зеркало операций с реестром ЮKassa и инициирует выплаты продавцам по регламенту.

Отдельный большой блок — интеграция с внешними маркетплейсами и товароучётом. Часто площадка не только продаёт у себя, но и тянет остатки/заказы из Ozon, Wildberries и учётных систем. Как связать это с каталогом и заказами, мы разбирали в статье про интеграцию с маркетплейсами Ozon и Wildberries. Для сплит-схемы важно, чтобы источник остатков и статус продавца были согласованы: нельзя продавать товар продавца, который на модерации или без действующего получателя в ЮKassa.

Обработчик оплаты и запрос к API ЮKassa

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

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

С точки зрения размещения кода, кастомный обработчик оформляется как расширение существующей платёжной системы Битрикса. Базовый обработчик ЮKassa копируется в личное пространство (чтобы обновления модуля не затирали правки), и в него добавляется формирование поля с трансферами и комиссией, а также сборка чека с несколькими продавцами. Событиями заказа (OnSaleOrderSaved и смежные) навешивается разбиение на отгрузки и запись зеркала операций.

Безопасность, идемпотентность и вебхуки

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

Идемпотентность. Запросы к API ЮKassa (создание платежа, возврат, выплата) должны идти с ключом идемпотентности (Idempotence-Key). Это защищает от двойного списания и дублей при повторной отправке из-за таймаутов и ретраев. Один ключ на одну логическую операцию — тогда повтор запроса не создаст второй платёж.

Проверка вебхуков. Уведомления о смене статуса платежа приходят на ваш URL. Их нельзя принимать вслепую: нужно проверять подлинность источника (по подписи/IP из документации сервиса) и перепроверять статус запросом к API, прежде чем менять состояние заказа и начислять баланс продавцу. Иначе подделанный вебхук может «оплатить» неоплаченный заказ.

Транзакционность и логирование. Начисление баланса продавца, смена статуса заказа и запись зеркала операции должны происходить согласованно. Каждый шаг работы с деньгами логируйте: что отправили, что получили, каким ключом. При разборе спорных ситуаций с продавцом лог операций — единственный объективный источник правды.

Отдельно — обработка ошибок разбивки. Если хотя бы один получатель заблокирован, реквизиты неверны или сумма не сходится, платёж не создастся. Обработчик должен это ловить и давать понятную ошибку (и покупателю — вежливую, и в лог — техническую), а не падать с 500-й. На маркетплейсе с сотнями продавцов такие ситуации не редкость, и от аккуратности обработки ошибок зависит конверсия оплаты.

Частые ошибки

• Принимают всю выручку продавцов на счёт площадки без агентского договора — налоговая считает это доходом площадки со всеми доначислениями.
• Считают комиссию без контроля округления — сумма трансферов не сходится с суммой платежа, и запрос к ЮKassa падает на копейке.
• Не проверяют статус продавца перед сплитом — трансфер к заблокированному получателю валит весь платёж заказа.
• Выплачивают продавцу всё сразу без холда — при возврате нечем вернуть деньги покупателю, убыток ложится на площадку.
• Задают одну ставку НДС на весь магазин — у продавцов разные системы налогообложения, и чеки получаются некорректными.
• Не разбивают заказ на отгрузки по продавцам — статусы, возвраты и выплаты по разным поставщикам путаются в одном заказе.
• Правят файлы платёжного модуля напрямую — ближайшее обновление затирает сплит-логику, и оплата встаёт.
• Принимают вебхуки без проверки подписи и не используют идемпотентность — риск двойных списаний и поддельных «оплат».

Чек-лист внедрения

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

1. Юридическая схема утверждена. Есть агентский (комиссионный) договор с продавцами, роли и признак агента в чеке согласованы с бухгалтером.
2. Сплитование подключено. В ЮKassa активировано «Сплитование платежей», площадка прошла модерацию, продавцы регистрируются как получатели через API.
3. Модель продавцов готова. Инфоблок продавцов с реквизитами, ставкой НДС, комиссией, статусом и recipientId; товары привязаны свойством «Продавец».
4. Разбивка суммы считается на сервере. Трансферы и комиссия считаются по данным заказа, округление контролируется, схождение сумм проверяется до отправки.
5. Чеки корректны. Состав чека собирается по продавцам, с признаком агента, данными поставщика и индивидуальной ставкой НДС по позиции.
6. Отгрузки по продавцам. Заказ бьётся на отгрузки по продавцу, статусы и логистика ведутся независимо.
7. Возвраты адресны. Частичный возврат списывается с нужного продавца, заложен холд, прописан сценарий пустого баланса.
8. Надёжность обеспечена. Идемпотентность запросов, проверка вебхуков, логирование и транзакционность операций с деньгами.
9. Сверка и выплаты автоматизированы. Ведётся зеркало операций, регулярная сверка с реестром ЮKassa, выплаты по регламенту с реестром в кабинете продавца.

Вывод

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