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

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

В dispute-процессе важна не эмоция, а карта этапов. Если команда видит цепочку целиком, проще понять, где теряется время, деньги и шанс на успешную защиту.

Классическая схема такая:
— инициирование спора у эмитента;
— временный hold по сумме;
— запрос evidence от PSP/эквайера;
— сбор пакета: логин, IP, 3DS, delivery proof, descriptor, переписка;
— подача representment;
— review у сети и банка;
— либо reversal, либо second chargeback/arbitration.

На каждом шаге свои SLA. Если evidence собирается вручную и без шаблона, команда теряет окно ответа. Если у merchant’а слабый descriptor или нет связки «платёж → доставка → контакт», спор обычно решается не в его пользу.

Самая частая ошибка — готовить защиту как одну PDF-ку «на всё». Правильнее иметь матрицу по reason code: для friendly fraud важны устройство, 3DS и поведение клиента; для non-receipt — трекинг, статус доставки и подтверждение получения; для duplicate/recur — история биллинга и согласие на автосписание.

Держите dispute lifecycle как воронку: кто триггерит, кто собирает evidence, кто отправляет, кто контролирует дедлайны. Тогда чарджбек перестаёт быть хаосом и становится операционным процессом.