Комиссия маркетплейса: тарифы, расчёт и корректировки

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

Автор: Александр Поркулевич, CEO и основатель, 404gen.

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

Разбор предназначен владельцу и продуктовой команде новой площадки. Это не актуальная таблица тарифов Ozon или Wildberries и не консультация по налоговой модели. Договорные, платёжные и учётные условия согласовываются со специалистами отдельно. Здесь рассматриваем устройство программного модуля: как сохранить правила, рассчитать результат и проверить исправления.

С чего начинается комиссия маркетплейса

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

Затем опишите базу расчёта. В неё могут входить определённые составляющие стоимости, а доставка, скидки и дополнительные услуги учитываться отдельно. Нельзя использовать слово «оборот» без определения: разные сотрудники могут понимать под ним стоимость корзины до скидки, оплаченную сумму или стоимость фактически переданного товара. Формула должна ссылаться на конкретные поля.

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

Какие части расчёта нужно разделить

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

Версия тарифа важнее текущего процента

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

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

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

База, точность и округление

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

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

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

Сценарии для проверки тарифного модуля

В корзине товары нескольких продавцов

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

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

На товар действует скидка площадки

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

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

Тариф изменился после создания заказа

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

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

Исполнена только часть количества

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

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

Покупатель вернул одну позицию

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

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

Возврат произошёл после расчёта с продавцом

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

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

Повторно пришло подтверждение оплаты

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

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

Ручная корректировка требует согласования

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

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

Внешний платёжный сервис применяет собственные правила

Платёжная схема может разделять оплату, вознаграждение платформы, перечисление и возврат. Сохраните внешние идентификаторы этих частей. Документация Stripe Connect о destination charges показывает отдельное удержание платформой части платежа и передачу остального. Это пример модели интеграции, а не рекомендация доступности этого провайдера для российского бизнеса.

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

Продавец оспаривает расчёт

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

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

Кабинет продавца и внутренний реестр

Внешний экран показывает начислено, ожидает выполнения условий, скорректировано и перечислено. Эти категории должны иметь точные определения. Одна крупная цифра «ваш баланс» без состава порождает вопрос, можно ли её вывести и почему она отличается от суммы заказов. Доступное действие определяется текущим состоянием и правилами расчёта.

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

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

Проверка расчётов до запуска

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

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

Изменение тарифного движка проверяется на ранее сохранённых примерах. Это помогает заметить, что новое правило повлияло на старые версии. У команды должен быть способ остановить новые расчёты, не теряя принятые заказы. Непрояснённые операции остаются в очереди, а не переводятся массово в успешное состояние ради выпуска.

Когда достаточно простого тарифа

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

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

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

Можно ли хранить только процент продавца?

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

Комиссия и стоимость эквайринга — одно и то же?

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

Нужно ли пересчитывать всё после смены тарифа?

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

Как проверить частичный возврат?

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

Что понадобится для оценки разработки маркетплейса?

Опишите участников, момент начисления, базу, скидки, расчёт с продавцом и исключения. Добавьте несколько вручную разобранных учебных заказов и предполагаемый платёжный контур. Готовая схема позволит оценить объём точнее, чем требование «комиссия как на крупной площадке», у которой могут быть другие договоры и процессы.

Описать свою модель расчётов

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

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