Фрод и чарджбэки ломают биллинг там, где API не умеет спорить с реальностью

Фрод и чарджбэки ломают биллинг там, где API не умеет спорить с реальностью

Если антифрод и chargeback API живут отдельно, система быстро теряет консистентность: платёж уже принят, а риск-сигнал приходит позже. Нужен единый decision layer, который на входе оценивает атрибуты сессии, поведение клиента, историю попыток и контекст устройства, а на выходе возвращает не только approve/decline, но и reason code для дальнейшего расследования.

Ключевые правила:
— все входящие события должны быть идемпотентны по payment_intent_id;
— скоринг и ручные флаги хранятся как события, а не как перезаписываемое состояние;
— при споре по карте сохраняйте полный audit trail: payload запроса, ответ шлюза, таймстамп, merchant reference, BIN, device fingerprint;
— для high-risk потоков включайте step-up: 3DS, hold, delayed capture, лимит по сумме или количеству попыток.

Чарджбэк-обработка через API не должна быть «папкой для документов». Это workflow с SLA: intake → классификация → сбор доказательств → формирование representment package → статус-контроль → решение по восстановлению выручки. Каждому кейсу нужен свой state machine, иначе вы потеряете дедлайны на подачу и не заметите, где течёт revenue leakage.

Давайте разберем, что происходит с транзакцией в момент сетевого сплита шлюза: если платёж был проведён, но подтверждение не дошло, повторный запрос без идемпотентного ключа создаёт двойное списание или ложный decline. Поэтому antifraud должен работать рядом с биллингом, а не над ним.

Если API не умеет связывать риск, платёж и спор в один контур, система защищается от фрода ценой собственной выручки.