3-D Secure 2. 0 і SCA

1) Навіщо iGaming-оператору 3DS2 і що таке SCA

3-D Secure 2. x (EMV 3DS) - протокол автентифікації власника картки в e-commerce.
SCA (Strong Customer Authentication) - регуляторна вимога (PSD2/UK), що зобов'язує проводити двофакторну перевірку в ряді сценаріїв.

• Liability shift: при успішній автентифікації ризик шахрайства переходить до емітента.
• Вище конверсія vs 3DS1: збір 100 + data-елементів дозволяє frictionless без челенджу.
• Нативні сценарії: SDK для iOS/Android, in-app, decoupled і out-of-band підтвердження.

2) Ролі та компоненти (EMV 3DS)

3DS Server (у вас або у PSP): формує запити в схему, агрегує дані девайса, управляє версіями 2. 1/2. 2/2. 3.
Directory Server (DS): роутер схем (Visa/Mastercard/AmEx та ін.).
Access Control Server (ACS): сервер емітента; приймає рішення: frictionless или challenge.
SDK/Method: збір девайс-сигналів (fingerprinting), web-SDK/iframe і mobile-SDK.

3) Типові UX-потоки

3. 1 Frictionless (без челенджу)

1. Merchant/PSP → DS: AReq з 3DS-даними (девайс, історія, ризик-сигнали).
2. DS/ACS → ARes (frictionless): автентифікація пройдена без участі користувача.
3. Далі → авторизація (Auth).

Коли спрацьовує: низький ризик, whitelist (Trusted Beneficiary), ЛВП, якісні дані.

3. 2 Challenge (з челленджем)

1. ARes вимагає CReq/CRes (OTP, пуш-підтвердження в банку, біометрія).
2. Після успіху → авторизація, liability shift збережений.

3. 3 Decoupled / Out-of-Band

Підтвердження в додатку банку без редиректу. Корисно в мобайл-сценаріях.

3. 4 3RI (3DS Requestor Initiated)

Використовується для MIT (мерчант-ініційованих транзакцій) - підписки, ретраї. Немає SCA на кожному повторі, але потрібне коректне посилання на initial CIT.

4) SCA: де обов'язковий і де діє

Обов'язковий: більшість e-commerce транзакцій в EEA/UK, якщо емітент і еквайр в зоні SCA.
Поза зоною/Out-of-scope: MOTO (пошта/телефон), деякі корпоративні канали, міжзонові маршрути (може застосовуватися TRA емітента).

4. 1 Винятки (Exemptions)

TRA (Transaction Risk Analysis): низький ризик провайдера/банку (підтверджується метриками фроду).
LVP (Low-Value Payments): невеликі суми, з порогами і лічильниками емітента.
Whitelist (Trusted Beneficiary): одержувач в білому списку клієнта у емітента.
Secure Corporate / Merchant Initiated (MIT): наступні списання поза SCA, якщо є initial CIT зі SCA і коректні посилання.

5) Маркування транзакцій і прапори для iGaming

CIT (Customer Initiated Transaction): первинне списання, зазвичай вимагає SCA (або exemption).
MIT Recurring / Unscheduled COF: наступні списання; не вимагають SCA при наявності зв'язки з початковим CIT (міжмерчантські посилання/ідентифікатори).
Коректні індикатори в запитах до PSP/схеми критичні для liability shift і пропуску SCA на повторах.

6) Дані, що впливають на рішення ACS

• Device/Browser: user-agent, accept headers, screen, timezone, language.
• Account data: вік аккаунта, дата останнього пароля, кількість неуспішних входів.
• Transaction data: МСС/категорія, сума/валюта, попередні спроби, velocity.
• Shipping/Billing: збіг адрес, історія одержувача.
• 3DS method completion indicator: чи встиг відпрацювати 3DS Method (фінгерпринт).
• Чим багатший контекст - тим вище шанс frictionless.

7) Потоки інтеграції з оркестратором платежів

7. 1 Послідовність (web/mobile)

1. Initiate 3DS (3DS Server ↔ DS/ACS) → отримати ARes.
2. Якщо challenge → відпрацювати CReq/CRes через SDK/iframe.
3. Успіх → Auth (авторизація) із зазначенням результату 3DS (ECI, CAVV/cryptogram, dsTransID).
4. Webhook PSP → оркестратор → Ledger/DWH (без PAN).

7. 2 Soft-decline і ретраї

Авторизація без SCA може повернутися'soft-decline (code)'→ повторити платіж з SCA.
Оркестратор тримає state-машину спроб: no SCA → soft-decline → 3DS2 → Auth.

7. 3 Multi-PSP

Перевіряйте підтримку версій 3DS (2. 1/2. 2/2. 3), app-SDK, decoupled.
Smart-routing: при деградації ACS у частини емітентів використовуйте резервний шлях (якщо політика/схеми дозволяють).

8) UX-патерни, що підвищують конверсію

Native/SDK в мобільних додатках: менше редиректів, вище завершеність.
Pre-collect даних (e-mail, адреса, поведінкові сигнали) до 3DS.
Прозорі екрани очікування і зрозумілі тексти (локалізація по мові/регіону).
Таймаути з м'яким поверненням до оплати і повтором челенджа.
Whitelisting промпт: пропонуйте клієнту додати мерчанта в довірені у банку (де доступно).

9) Помилки і крайні випадки

Timeout/Unavailable ACS → коректні коди і повтор (або fallback по політиці).
Version downgrade: якщо 2. 2/2. 3 недоступна, відкат до сумісної версії.
Partial method: якщо 3DS Method не завершився, все одно відправляйте AReq - краще часткові дані, ніж нуль.
Mixed flows: одночасно 3DS + адресна верифікація AVS - коректно маппіте статуси.
Chargeback після 3DS: заперечуйте з артефактами (ECI, CAVV, ARes/CRes refs).

10) Документи та артефакти, які потрібно зберігати

Ідентифікатори транзакцій 3DS (dsTransID, threeDSServerTransID).
Результати аутентифікації (ECI, CAVV/AVV, ARes/CRes статуси).
Логи SDK (без PII/PAN), таймстемпи і коди помилок.
Посилання MIT на initial CIT для підписок/повторів.
Політики обробки soft-decline і TRA-винятків.

11) Метрики та цілі (KPI для iGaming)

Конверсія

3DS completion rate (частка успішно завершили автентифікацію).
Частка frictionless vs challenge (мета - ↑ frictionless).
Abandonment rate на 3DS-екранах.

Ризик

Фрод-рейт після liability shift (нижче - краще).
Частка soft-decline і успішність наступних ретраїв з 3DS.

Техніка

Час 3DS p95 (ініціація → результат).
Помилки SDK/iframe, таймаути ACS.

12) Чек-лист запуску 3DS2 + SCA

• 3DS Server підключений (версії 2. 1/2. 2/2. 3), тест-бінс відпрацьовані.
• Веб-SDK/мобайл-SDK інтегровані (in-app + webview сценарії).
• Збір de-vice/browser data включений (3DS Method).
• Маркування CIT/MIT/COF коректні; зберігається посилання на initial CIT.
• Потік soft-decline → повтор з SCA реалізований в оркестраторі.
• Exemptions (TRA/LVP/whitelist) налаштовані і логуються причини/результати.
• Мульти-PSP: версії 3DS і fallback-шлях перевірені.
• Дешборди KPI: frictionless %, challenge success %, abandon, soft-decline.
• Політики зберігання артефактів 3DS і dispute-плейбуки готові.
• A/B-тести підказок UX (локалізація, тексти, таймаути) заплановані.

13) Взаємозв'язок з PCI DSS і токенізацією

3DS2 не замінює PCI DSS: він про автентифікацію, а PCI - про захист даних.
Для PAN-safe: введення карти в hosted fields/iframe; оркестратор бачить тільки токени і 3DS-артефакти (ECI/CAVV).
Для COF/MIT використовуйте network tokens або vault-токени, щоб зменшити фрод і підвищити авторизацію.

14) FAQ коротко

Чи потрібно завжди робити 3DS? У зоні SCA - так, якщо немає коректного exemption/виключення. Емітент може зажадати челендж.
Якщо банк зламався? Використовуйте політики ретраїв/таймаутів і, при можливості, інший маршрут.
Чи дасть 3DS зростання конверсії? Правильно налаштований 3DS2 з багатими даними підвищує частку frictionless і знижує фрод/чарджбеки.
Що найкритичніше для успіху? Багаті контекстні дані, коректні прапори CIT/MIT/COF, швидкий UX і грамотна обробка soft-decline.

15) Резюме

Для iGaming 3DS2 + SCA - це не «обов'язковий біль», а інструмент зростання: більше frictionless, менше фроду, перенесення відповідальності на емітента, стабільна монетизація підписок і повторних списань. Закладайте правильні прапори (CIT/MIT/COF), підтримуйте exemptions за правилами, забезпечте пан-безпечне введення і будуйте оркестратор з розумними ретраями і спостережуваністю - тоді автентифікація стане союзником, а не гальмом конверсії.