<b>Скрытые комиссии в платежках: где агрегатор доит вас на округлении</b>

<b>Скрытые комиссии в платежках: где агрегатор доит вас на округлении</b>

Агрегаторы любят продавать «честную комиссию с оборота», но деньги утекают не в тариф, а в математику. Классика жанра: сумма в копейках, валюта с minor units, конвертация, потом округление на стороне шлюза, а дальше — сеттлмент уже на уровне, где никто не хочет считать хвосты. Документация, как обычно, молчит. Логи — истина.

Главные точки утечки:
— округление по строке, а не по батчу;
— разная база для комиссии: до/после скидки, до/после налога;
— FX-конверсия с двойным спредом и «служебным» округлением;
— возвраты, где комиссия пересчитывается не зеркально, а как удобно провайдеру.

Идемпотентность тут тоже не спасает: если у вас повторный capture или ретрай после таймаута, агрегатор может засчитать операцию дважды в отчетности, а потом «исправить» это на своем конце без прозрачного reconciliation. В итоге бухгалтерия видит расхождение на мелочи, а на массовом трафике это уже не мелочь, а утечка маржи.

Что проверять в интеграции:
— raw amount и settlement amount в одном отчете;
— правила округления по каждому currency minor unit;
— как считаются partial refund и chargeback fee;
— есть ли выгрузка транзакций на уровне event log, а не только сводный CSV.

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