Сервис выплат не заменяет модель расчёта с курьерами

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

Перевод денег не объясняет начисление

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

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

Исследование OECD по платформам доставки в Хорватии описывает комбинации базовой части, расстояния, транспорта, бонусов и коэффициентов. Российский рынок оно не характеризует, но показывает, как несколько условий влияют на одну выплату.

Пять признаков отдельного проекта

1. Сумма зависит от нескольких событий. Заказ, доставка, отмена и возврат приходят в разное время. Журнал событий позволяет восстановить основание начисления.
2. У исполнителей разные правила. Версия тарифа должна сохраняться вместе с расчётом, иначе старый заказ нельзя корректно объяснить или пересчитать.
3. Есть корректировки после выплаты. Корректировка хранит причину и связь с исходным начислением; она не стирает историю.
4. Итог нужно объяснить. Исполнитель и оператор должны видеть основания суммы и путь разбора спорной ситуации.
5. Сверка объединяет несколько систем. Заказ, начисление, перевод и корректировка требуют устойчивых идентификаторов.

Оценка Fairwork Colombia рассматривает оплату вместе с контрактами и управлением. Для расчётного контура это означает, что рядом с итогом нужны основания суммы и маршрут разбора спора. Методология относится к Колумбии и не задаёт требования для российского рынка.

Когда правила и исключения уже не помещаются в настройках готового сервиса, требуется платформенное решение.

От заказа до сверки

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

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

Корректировка не стирает историю

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

Когда интеграции достаточно

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

Как выбрать следующий шаг

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

В Qtim помогут разобрать схему расчётов и определить состав платформенного решения.