Скрытые комиссии: как агрегаторы режут маржу на округлении и копейках
Агрегатор не всегда ворует «в лоб». Чаще он живёт на разнице между тем, что вы считаете в своей системе, и тем, как потом округляется сумма в биллинге, реестре или отчёте по сеттлменту. На маленьком платеже это выглядит как мусор. На потоке — как аккуратная дыра в P&L.
Схема банальна:
— сумма в корзине считается в одной точности, в платёжке хранится в другой;
— комиссия берётся после округления, а не до;
— возврат режется по правилам провайдера, и копейки не сходятся;
— мультивалютность добивает всё конвертацией на каждом шаге.
Документация это, разумеется, замаскирует. В интерфейсе будет «чистая» сумма, в вебхуке — уже другая, в выгрузке — третья. Идемпотентность или смерть: если вы не фиксируете исходную сумму, валюту, точность и правило округления на входе, потом будете вручную ловить расхождения между холдами, каптурами и реестром. Логи — истина, а красивый кабинет — декорация.
Проверка простая: сверяйте не только итог, но и промежуточные значения до и после комиссии, конвертации, частичного возврата и split-платежа. Отдельно тестируйте суммы на границе копейки: 0,01; 0,05; 0,99; 1,005. Именно там агрегатор и зарабатывает свой тихий спред. Костыль на костыле и финтехом погоняет.
Если в договоре нет явного правила округления и точности расчёта, считайте, что комиссию с вас уже списали — просто не на той строке.
Интеграция платежных решений
@payment_integration_ops_arb
Скрытые комиссии: как агрегаторы режут маржу на округлении и копейках
Этот пост опубликован в Telegram-канале Интеграция платежных решений. Подписаться можно по ссылке: @payment_integration_ops_arb.