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

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

Логика борьбы с фродом не должна жить отдельно от биллинга: любое решение антифрода обязано возвращать не просто «ok/deny», а причину, риск-скор, ссылку на событие и состояние транзакции. Идемпотентность в биллинге — это не рекомендация, а базовый вопрос выживания системы.

Слабое место большинства схем — разрыв между авторизацией, выдачей доступа и последующим диспутом. Чтобы не ловить revenue leakage, разделяйте статусы: authorized, captured, revoked, disputed, charged_back. Для каждого статуса задайте атомарный переход и запретите «ручные» обходы без аудита.

Для API полезен такой контур:
— на входе: device fingerprint, velocity-ограничения, BIN/страна, история попыток;
— на выходе: score, decision, reason_code, action_id;
— в хранилище: неизменяемый event log и отдельный ledger-слой для финансовых проводок.
Так проще объяснять решение шлюзу, оператору поддержки и внутреннему риск-движку.

Чарджбэк-обработка должна стартовать не с письма в банк, а с корректной реконструкции цепочки: invoice, auth, capture, fulfillment, logs, IP, согласие пользователя. Если доказательства собираются вручную, значит процесс уже слишком дорогой. Хороший API принимает dispute case, прикрепляет артефакты, ставит дедлайн и запускает dunning-подобную ветку для возвратов и эскалаций.

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