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

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

Привет, я Антон Фокин — CEO Qtim.

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

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

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

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

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

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

1. Итог зависит от нескольких событий

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

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

2. У разных курьеров действуют разные правила

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

3. После выплаты возникают корректировки

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

4. Сумму нужно объяснить человеку

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

5. Выплаты приходится сверять с несколькими системами

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

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

В нашем кейсе Poison Drop мы в Qtim совместно развивали frontend, backend, интеграции и инфраструктуру интернет-магазина украшений. Оформление заказа связывает профиль, корзину, скидки, доставку и оплату в единый сценарий; для расчётного контура важен тот же механизм согласованной передачи данных между несколькими состояниями и системами.

Для расчётов с исполнителями этот принцип можно представить так:

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

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

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

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

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

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

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