Скрытые комиссии в округлении — любимый способ агрегатора брать лишнее без лишнего шума

Агрегатор редко пишет «мы взяли комиссию за округление». Он пишет красивый net-settlement, а потом в стыке валют, копеек и частичных возвратов начинается магия: сумма авторизации, сумма списания и сумма проводки уже не совпадают. И вот у вас по отчёту всё вроде сходится, а в разрезе транзакций всплывает хвост на копейки. Документация — это ложь, логи — истина.

Классическая схема простая:
— округление на стороне провайдера, а не мерчанта;
— разный шаг округления для авторизации, capture и refund;
— конвертация по «внутреннему» курсу с добивкой в сторону агрегатора;
— дробные возвраты, где комиссия считается от исходной суммы, а не от факта списания.

Что надо проверять до интеграции: правила округления на входе и на выходе, порядок операций при частичном возврате, кто владеет FX-спредом, и есть ли в API отдельное поле для fees/adjustments. Если его нет — готовьтесь собирать расхождения сами, по выпискам и webhook-дампам. Идемпотентность или смерть.

Нормальный контроль — это сверка не только total, но и gross, fee, tax, refund, adjustment по каждой операции. Если провайдер прячет добивку в итоговом балансе, у вас не платежная платформа, а бухгалтерский квест с сюрпризом. Костыль на костыле и финтехом погоняет.

Финал простой: если агрегатор не показывает механику округления в разрезе статусов и валют, он зарабатывает на вашей невнимательности. Лечится только жёсткой сверкой и собственным ledger’ом.