Dispute lifecycle в платежах: как выглядит путь от чарджбека до финального решения

Dispute lifecycle в платежах: как выглядит путь от чарджбека до финального решения

У dispute есть предсказуемая цепочка, и команда часто теряет деньги не на самом споре, а на разрыве процесса. Базовая схема такая: инициирование → сбор доказательств → подача representment → ответ эквайера/сети → решение.

На каждом шаге нужен свой артефакт:
• инициирование — reason code, дата, сумма, MID, descriptor
• сбор доказательств — инвойс, логин-логи, трекинг, переписка, подтверждение доставки
• representment — короткая хронология и документы в одном пакете
• решение — фиксация результата, чтобы не повторять ту же ошибку по тому же сценарію

Слабое место обычно в тайминге: если внутренний SLA на сбор данных длиннее окна сети, спор уже проигрывается операционно. Поэтому у нормального процесса есть один владелец кейса, единый шаблон ответа и чек-лист по типам reason code. Для friendly fraud и fraud-диспутов набор доказательств разный, смешивать их в одну папку нельзя.

Хорошая визуализация — это не блок-схема ради красоты, а доска с четырьмя статусами: new, evidence, submitted, closed. Тогда видно, где зависает MID, где ломается descriptor-цепочка и где нужен dispute-management, а не ручной хаос.