<b>Скрытые комиссии: как агрегаторы зарабатывают на ошибках округления</b>

<b>Скрытые комиссии: как агрегаторы зарабатывают на ошибках округления</b>

Агрегатор почти никогда не ворует «в лоб». Он мелко режет суммы на округлениях, и в отчётах это выглядит как шум. Платёж прошёл, сверка сошлась «почти», а копейки осели на стороне провайдера. Идемпотентность или смерть: если у вас нет жёсткой сверки по order_id, minor units и валюте, вы сами подписали чек на утечку.

Типовые места, где прячется маржа:
— конвертация из float в decimal в биллинге;
— округление на уровне корзины, а не позиции;
— пересчёт НДС/комиссии после купона;
— разный scale у API, PSP и вашей базы;
— возврат не в той же логике округления, что списание.

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

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

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