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 і зворотний зв'язок в ризик-правила і роутинг.

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