Dispute/Representment: как выигрывать

1) Цель Representment и принцип «правильного пакета»

Representment — это контр-аргумент мерчанта на чарджбек по правилам схемы. Вы выигрываете не «правдой в целом», а точным соответствием: причина чарджбека ↔ допустимые доказательства ↔ дедлайны ↔ формат. Ключ: отправить релевантные артефакты в нужной форме и вовремя.

2) Процесс и дедлайны (высокоуровнево)

1. Retrieval/Inquiry — запрос информации.
2. Chargeback — списание; старт окна для ответа.
3. Representment — ваш пакет доказательств.
4. Pre-Arbitration (Pre-Arb) — дополнительный раунд.
5. Arbitration (Arb) — финал у схемы, высокие сборы.

3) Карта причин → что доказывать

3.1 Фрод / «No Cardholder Authorization»

Цель: показать, что держатель аутентифицирован и/или транзакция совершена легитимно именно этим клиентом.

• 3DS 2.x: ECI, CAVV/AVV, dsTransID/threeDSServerTransID, ARes/CRes референсы (liability shift).
• Device/IP fingerprint, таймстемпы, совпадение гео с профилем, история логинов.
• KYC-статус, действия в аккаунте (депозиты, сессии, выводы).
• Уведомления/письма/пуши и подтверждения со стороны клиента.

3.2 Диспут услуги («Услуга не оказана/не соответствует»)

Цель: доказать, что услуга оказана в соответствии с офертой.

• Логи игровых сессий: время, IP/устройство, ставки/выигрыши, балансовые движения.
• Выписки по кошельку аккаунта: депозит → игра → вывод/остаток.
• Версия Правил/ToS/бонусных условий на момент сделки + согласие.
• История тикетов и ответы поддержки, предложения урегулирования.

3.3 Технические/операционные (дубли, суммы, валюты)

Цель: показать отсутствие ошибки или ее своевременное исправление.

• Журнал идемпотентности, `payment_id ↔ psp_txn_id ↔ arn/rrn`.
• Reconciliation-логи (авторизация/капчур/возврат).
• Подтверждение возврата (если сделан) с датами и суммами.

4) «Сторителлинг» пакета: как оформить

1. Кейс-резюме (1 страница): причина чарджбека, тезис позиции, список вложений, таймлайн.

2. Факты/хронология: по пунктам, с ссылкой на метки времени.

3. Доказательства: вложения с нумерацией и краткими аннотациями.

4. Нормативная ссылка: пункт правил схемы/эквайера, под который подпадает ваш кейс (на уровне формулировок без цитирования внутреннего регламента, если это не требуется).

5. Вывод: чего вы просите (отклонить чарджбек).

5) Шаблоны аргументации (готовые формулировки)

• «Транзакция аутентифицирована по EMV 3DS 2.x: ECI=X, CAVV=…, dsTransID=…. В соответствии с правилами, ответственность переносится на эмитента. Дополнительно прилагаем совпадение устройства/IP и активность аккаунта сразу после депозита».

• «Имеются совпадение девайса/браузера, IP-страны, нормальная сессия игры после депозита, вывод средств на тот же способ оплаты. Вероятность компрометации низка; транзакция легитимна».

• «Игровая активность подтверждена логами (время, ставки, результаты), правила и ограничения были доступны и приняты. Запрос на возврат поступил после использования услуги/бонуса».

• «Дублирование зафиксировано механизмом идемпотентности; избыточная сумма возвращена в T+1, ARN/rrn прилагаются. Просим закрыть спор».

6) Автоматизация: что должен делать оркестратор

Автосбор 3DS-артефактов (ECI, CAVV, dsTransID) и привязка к `payment_id`.
Журналы событий: Auth/Capture/Refund/Chargeback/Representment в единой ленте.
Витрина «Case Builder»: чек-листы, генерация титульного листа и таймлайна из логов.
Интеграция с DWH: быстрый выгрузчик сессий/баланса.
Алерты по SLA: T–3/T–1 до дедлайна, контроль полноты пакета.
Шаблоны текстов под типы причин на нужном языке.

7) Метрики успеха (KPI) и целевые уровни

Win Rate (общий) — цель: ≥ 60–70% по фрод-кейсам с 3DS; ≥ 40–50% по диспуту услуги.
Coverage Rate — доля кейсов с полным пакетом (цель: 95%+).
Time-to-Respond p95 — не позднее T–1 к дедлайну эквайера.
Repeat CB (recurrence) по клиентам/устройствам — снижение QoQ.
Cost per Case / ROI защиты — рост отдачи от подготовленных пакетов.
3DS Liability Shift Protected % — доля фрод-кейсов, закрытых за счет 3DS.

8) Практические плейбуки по сценариям

A. «No Auth», 3DS проходил (frictionless/challenge успех)

1. Проверка артефактов 3DS → 2) Добавить device/IP/гео → 3) Краткий сторителлинг → 4) Отправить.

Цель: быстрый win за счет liability shift.

B. «Услуга не оказана», сессии есть

1. Выгрузить логи игры/баланса → 2) Приложить ToS/бонусные условия → 3) Приложить скрин тикетов → 4) Отправить.

Цель: показать фактическое потребление.

C. Дубли/сумма/валюта

1. Проверить идемпотентность → 2) Сделать возврат при подтверждении → 3) Приложить ARN/rrn → 4) Просить закрыть.

Цель: снять техническую претензию.

9) Работа с эквайером и «тональности» переписки

Держите канал с списком контактов эскалации (L1/L2/L3 у эквайера).
Пишите кратко, структурно, без эмоций, со ссылками на вложения и таймкоды.
Не спорьте с «мнениями» — оперируйте правилами схемы, фактами логов, 3DS, KYC.

10) Юридические и комплаенс-заметки

GDPR/PII: включайте минимально необходимую информацию; маскируйте адреса, e-mail, телефоны.
PCI DSS: никаких PAN/CVV; только токены/last4 и идентификаторы транзакций.
Локальные требования: для некоторых стран — тексты на местном языке/часовой пояс/валюта.

11) Частые ошибки (и как их избегать)

Опоздали с пакетом → автоматический проигрыш. Решение: SLA-алерты, резервные исполнители.
Нет ключевых артефактов 3DS → проигрыш фрод-кейса. Решение: автосбор в оркестраторе.
Слабый сторителлинг: «много скринов без логики». Решение: единый шаблон.
Лишние PII/PAN → риски PCI/GDPR. Решение: пред-фильтр экспорта.
Перепутанные идентификаторы (payment_id/psp_txn_id/arn) → несшивается кейс. Решение: карта соответствий в лейджере.

12) Чек-лист Representment (короткая версия)

• Правильно определена причина и выбран шаблон аргумента.
• 3DS-артефакты (ECI/CAVV/dsTransID) собраны и проверены.
• Логи сессий/баланса и выписки: есть, читаемы, аннотированы.
• ToS/бонусные условия на момент сделки — приложены.
• Идентификаторы сквозные: `payment_id ↔ psp_txn_id ↔ arn/rrn`.
• Формат/язык/метки времени — по требованиям эквайера.
• GDPR/PCI проверка: без лишних PII/PAN.
• SLA: подано не позже T–1, подтверждение отправки зафиксировано.
• Итоговый вывод (что просите) сформулирован явно.

13) Шаблон титульного листа (пример)

Case ID: CB-2025-001234

Reason Code: (схема/PSP)

Transaction: payment_id / psp_txn_id / arn / дата-время / сумма / валюта

Summary: (1–2 абзаца позиции)

Evidence List: E1—3DS (ECI/CAVV/dsTransID), E2—Device/IP, E3—Session Logs, E4—Wallet Ledger, E5—ToS, E6—Support Tickets

Timeline: t0—Auth, t1—Game, t2—Withdrawal, t3—CB, t4—Representment

14) Ретроспектива и улучшения (после каждого кейса)

Обновить правила риска (если проиграли из-за конкретного паттерна).
Дополнить шаблоны (новые формулировки и примеры).
Пересмотреть роутинг/3DS политику по BIN/эмитенту, если всплеск по сегменту.
Обучить саппорт/финансы на реальных кейсах (best/worst).

15) Резюме

1. автоматический сбор ключевых артефактов (3DS, логи, лейджер),

2. четкий шаблон сторителлинга под причину,

3. строгая дисциплина дедлайнов и качества пакета,

4. метрики win rate и обратная связь в риск-правила и роутинг.

Так вы повышаете долю выигранных кейсов, снижаете стоимость споров и защищаете конверсию без лишних блокировок честных клиентов.