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: MCC/категория, сумма/валюта, предыдущие попытки, 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 по правилам, обеспечьте пан-безопасный ввод и стройте оркестратор с умными ретраями и наблюдаемостью — тогда аутентификация станет союзником, а не тормозом конверсии.