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

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

Антифрод нельзя встраивать как «проверку перед оплатой». Нужен отдельный контур: сигнал риска, решение, причина, следствие. Идемпотентный API должен уметь принимать повторный сигнал без двойной блокировки, а каждая смена статуса — фиксироваться как событие, а не перезапись строки.

Разделите решения на 3 уровня: — allow без задержки; — step-up с дополнительной верификацией; — deny с понятным кодом причины. Для каждого ответа храните не только verdict, но и feature set: IP, device fingerprint, BIN, история возвратов, частоту попыток. Это позволяет разбирать ложные срабатывания и не ломать легитимный конверт.

Чарджбэк — это не спор с банком, а процесс с дедлайнами, доказательствами и трассировкой. API должно принимать вебхук о dispute, создавать immutable case, подтягивать заказ, логи авторизации, IP, delivery proof, consent trace. Если доказательства собираются вручную, вы уже проиграли часть кейсов из-за latency и человеческих пропусков.

Отдельно проектируйте retry и reconciliation: один и тот же спор придет повторно, статус может меняться, а шлюз — отдавать пустые или запаздывающие ответы. Нужны дедупликация по external case id, журнал переходов и алерт на рассинхрон между платежом, возвратом и бухгалтерской книгой. Идемпотентность в биллинге — это не рекомендация, а базовый вопрос выживания системы.

Фрод и chargeback-операции должны жить в одном контуре наблюдаемости: тогда вы видите не только потери, но и причину утечки выручки.