Фрод и чарджбэки нельзя лечить одним API-эндпоинтом: нужна архитектура решений

Фрод и чарджбэки нельзя лечить одним API-эндпоинтом: нужна архитектура решений

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

Базовый набор правил:
• отдельный decision log: кто, когда и на каком сигнале заблокировал или пропустил платёж;
• идемпотентные API для callback, dispute, refund и retry;
• статусная машина без двусмысленных состояний: pending, settled, reversed, charged_back;
• неизменяемые сырьевые события для расследования, а не только агрегаты для дашборда.

Чарджбэк-обработка через API должна быть не «приёмом жалобы», а управляемым workflow: захват доказательств, дедлайн на ответ, привязка к исходной авторизации, контроль повторной отправки пакета. Идемпотентность в биллинге — это не рекомендация, а базовый вопрос выживания системы. Дубли в диспутах стоят дороже, чем дубли в логах.

Самая частая ошибка — смешать antifraud scoring и финальное решение по спору. Скоринг может пометить операцию как рискованную, но чарджбэк требует уже не эвристики, а трассируемой позиции по каждой транзакции. Грамотно спроектированная dunning-стратегия способна спасти до 15% уходящей регулярной выручки, но только если фрод-контур не режет платёжную воронку вслепую.

Держите антифрод и dispute pipeline как две согласованные, но независимые системы: первая снижает риск, вторая минимизирует потери и ошибки восстановления.