Фрод и чарджбэк ломают биллинг там, где API не умеет спорить с реальностью

Фрод и чарджбэк ломают биллинг там, где API не умеет спорить с реальностью

Логика борьбы с фродом должна жить не в одном сервисе, а в цепочке: риск-скоринг до авторизации, правила на повторяющиеся паттерны, лимиты на карту/аккаунт/IP и отдельный контур ручной эскалации. Если решение принимается синхронно и без idempotency key, вы получите двойные списания, ложные отказы и рассинхрон между оркестратором и PSP.

Для чарджбэков важен не сам факт спора, а трассировка. В API должны сохраняться: исходный платеж, статус авторизации, capture, refund, device fingerprint, IP, payload заказа и все webhook-события. Без этой цепочки вы не докажете легитимность транзакции и не сможете быстро собрать пакет доказательств для representment.

Отдельная ошибка — смешивать антифрод и dunning. Фрод-подозрение должно блокировать дальнейшие попытки оплаты и ставить платеж в quarantine, а не запускать повторные ретраи. Dunning работает только для genuine decline: недостаточно средств, временный отказ эмитента, сетевой таймаут. Иначе система сама будет добивать рискованные карты повторными попытками.

В API полезно разделять статусы: approved, captured, disputed, reversed, lost, won. Тогда аналитика видит, где возникает revenue leakage: на авторизации, на возвратах или на спорах. Грамотно спроектированная событийная модель и неизменяемый audit trail сокращают время ответа на претензию и снижают потери от необоснованных чарджбэков.