Фрод и чарджбэки ломают биллинг не в момент спора, а в момент плохой архитектуры

Фрод и чарджбэки ломают биллинг не в момент спора, а в момент плохой архитектуры

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

Через API важно строить не «отправили запрос и забыли», а транзакционный протокол с idempotency key, correlation id и неизменяемым audit trail. При повторе запроса шлюз, антифрод и биллинг должны сходиться к одному состоянию: approved, declined, reversed, disputed. Идемпотентность в биллинге — это не рекомендация, а базовый вопрос выживания системы.

Для чарджбэков нужен отдельный state machine: received → evidence_pending → evidence_sent → won/lost → financial_adjustment. На каждом переходе храните payload запроса, версию правил, ответ провайдера и таймстамп события. Тогда можно быстро собрать пакет доказательств: IP, device fingerprint, 3DS-результат, историю повторных попыток, факт оказания услуги, корреляцию с подпиской.

Ошибки обычно две: блокировать слишком агрессивно и терять выручку, либо не блокировать вовсе и платить двойной раз: за фрод и за dispute fee. Грамотно спроектированная dunning-стратегия способна спасти до 15% уходящей регулярной выручки, если она не конфликтует с антифрод-правилами.

Делайте антифрод и чарджбэки частью единого платежного контура: один журнал событий, один источник истины, один набор причин отказа. Тогда спор не разрушает систему, а лишь проверяет её на зрелость.