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

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

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

Схема должна быть событийной и идемпотентной: один платежный intent, один fraud-score, одно решение. На входе — нормализация сигнала, device fingerprint, velocity checks, BIN/geo mismatch, повторяемость реквизитов. На выходе — allow, step-up, hold, deny. Любое повторное API-вызовы должны ссылаться на тот же ключ операции.

Чарджбэк-обработка через API требует отдельного state machine: received → evidence_required → evidence_sent → won/lost. Важно хранить не только статус, но и версию доказательств, таймстемпы, канал платежа, merchant descriptor, историю коммуникаций. Иначе вы не сможете собрать пакет возражения без ручного поиска по логам.

Не менее критичны дедупликация и дедлайны: один и тот же dispute может прийти через несколько вебхуков, а решение нужно принять до истечения SLA. Поэтому ответы API должны быть транзакционными, а повторная подача доказательств — безопасной, без создания дублей и без потери предыдущего пакета.

Держите антифрод, биллинг и dispute-management в одной модели событий. Идемпотентность в биллинге — это не рекомендация, а базовый вопрос выживания системы.