Фрод и чарджбэки: как строить API, которое не теряет деньги на спорных платежах

Фрод и чарджбэки: как строить API, которое не теряет деньги на спорных платежах

Антифрод в подписках нельзя вешать на один скоринг-сервис: нужен конвейер из правил, поведенческих сигналов и транзакционного состояния. На входе фиксируйте device fingerprint, IP, velocity, BIN, историю попыток и флаги по аккаунту; решение должно возвращать не только allow/deny, но и причину, риск-уровень и TTL для пересмотра. Идемпотентность в биллинге — это не рекомендация, а базовый вопрос выживания системы.

Для оплаты и возвратов через API критичны: — единый idempotency key на авторизацию, capture, refund и dispute; — строгое состояние платежа, где «pending» не может перескочить сразу в «charged_back»; — очередь событий с повторной доставкой и дедупликацией; — журнал аудита, который связывает фрод-решение, эквайринг и действия саппорта в одну цепочку.

Чарджбэк не должен обрабатываться как ручная ошибка в CRM. Нужен отдельный workflow: intake спора, автосбор доказательств, таймеры по SLA, блокировка повторного списания и контроль двойного возврата. Давайте разберем, что происходит с транзакцией в момент сетевого сплита шлюза: если API ответил 500, а деньги уже списались, система обязана сверить исход по ledger, а не доверять последнему ответу.

Грамотно спроектированная dunning-стратегия способна спасти до 15% уходящей регулярной выручки. Но без синхронизации с антифродом она превращается в генератор ложных положительных срабатываний: повторные попытки оплаты, ретраи и ручные возвраты нужно ограничивать правилами риска, иначе рост recover rate маскирует revenue leakage. Настраивайте единый state machine и проверяйте каждый спор как финансовое событие, а не как тикет.