3-D Secure 2. 0 i SCA

1) Dlaczego operator iGaming 3DS2 i czym jest SCA

3-D Secure 2. x (EMV 3DS) - protokół uwierzytelniania posiadacza karty w handlu elektronicznym.
SCA (Strong Customer Authentication) jest wymogiem regulacyjnym (PSD2/UK), który wymaga weryfikacji dwóch czynników w wielu scenariuszach.

• Przeniesienie odpowiedzialności: przy udanym uwierzytelnieniu ryzyko oszustwa przechodzi na emitenta.
• Powyżej konwersji vs 3DS1: zbieranie 100 + elementów danych pozwala bezstratnie bez wyzwań.
• Natywne skrypty: SDK dla iOS/Android, in-app, oddzielone i poza pasmem potwierdzenia.

2) Role i komponenty (EMV 3DS)

Serwer 3DS (z Tobą lub PSP): generuje żądania do schematu, agreguje dane urządzenia, zarządza wersjami 2. 1/2. 2/2. 3.
Serwer katalogowy (DS): router schematu (Visa/Mastercard/AmEx itp.).
Access Control Server (ACS): serwer emitenta; podejmuje decyzję: beztroska lub wyzwanie.
SDK/Metoda: zbieranie sygnałów urządzenia (odciski palców), web-SDK/iframe i mobile-SDK.

3) Typowe strumienie UX

3. 1 Bez tarcia (bez wyzwania)

1. Handlowiec/PSP → DS: AReq z danymi 3DS (urządzenie, historia, sygnały ryzyka).
2. DS/ACS → ARes (frictionless) - uwierzytelniony bez interwencji użytkownika.
3. Następny → Auth.

Kiedy działa: niskie ryzyko, biała lista (Trusted Beneficial), HDL, dane jakości.

3. 2 Wyzwanie (z wyzwaniem)

1. ARes wymaga CReq/CRes (OTP, potwierdzenie push w banku, biometria).
2. Po sukcesie, autoryzacji →, zmiana odpowiedzialności jest zapisywana.

3. 3 Niezwiązany z produkcją/poza pasmem

Potwierdzenie w aplikacji bankowej bez przekierowania. Przydatne w scenariuszach mobilnych.

3. 4 3RI (zainicjowany wnioskodawca 3DS)

Używany do MIT (transakcje zainicjowane przez handlowców) - subskrypcja, przekwalifikowanie. Na każdej powtórce nie ma SCA, ale wymagane jest ważne odniesienie do początkowego CIT.

4) SCA: w przypadku gdy jest to obowiązkowe i ważne

Wymagane: większość transakcji handlu elektronicznego w EOG/Wielkiej Brytanii, jeżeli emitent i nabywca znajdują się w strefie SCA.
Poza zasięgiem: MOTO (poczta/telefon), niektóre kanały korporacyjne, trasy międzysferowe (TRA emitenta może mieć zastosowanie).

4. 1 Wyjątki

TRA (analiza ryzyka transakcji): niski poziom ryzyka dostawcy/banku (potwierdzony metodami oszustw).
LVP (Low-Value Payments): niewielkie kwoty, z progami emitenta i licznikami.
Whitelist (Trusted Beneficial): Odbiorca na białej liście klienta u emitenta.
Secure Corporate/Merchant Initiated (MIT): kolejne umorzenia poza SCA, jeśli istnieje początkowy CIT z SCA i poprawne odniesienia.

5) Znakowanie transakcji i flagi dla iGaming

CIT (Transakcja zainicjowana przez klienta) - początkowe umorzenie, zwykle wymaga SCA (lub wygaśnięcia).
MIT COF powtarzające się/nieplanowane: kolejne odpisy; nie wymagają SCA, jeśli istnieje link do oryginalnego CIT (linki/identyfikatory między handlowcami).
Poprawne wskaźniki w żądaniach PSP/schematu mają kluczowe znaczenie dla zmiany odpowiedzialności i pominięcia SCA na replikatach.

6) Dane wpływające na roztwór ACS

• Urządzenie/przeglądarka: agent użytkownika, akceptuje nagłówki, ekran, timezon, język.
• Dane konta: wiek konta, ostatnia data hasła, liczba nieudanych loginów.
• Dane transakcji: MCC/kategoria, kwota/waluta, poprzednie próby, prędkość.
• Wysyłka/rozliczenie: adres, historia odbiorcy.
• Wskaźnik wykonania metody 3DS: czy metoda 3DS (odcisk palca) ma czas na wypracowanie.
• Im bogatszy kontekst, tym większa szansa na beztroskie.

7) Przepływy integracji orkiestry płatniczej

7. 1 Sekwencja (web/mobile)

1. Zainicjuj usługę 3DS (serwer 3DS I/ACS) → odbierz ARES.
2. Jeśli wyzwanie → uruchom CReq/CRes przez SDK/iframe.
3. Auth → sukces (autoryzacja) z wynikiem 3DS (ECI, CAVV/kryptogram, dsTransID).
4. Webhook PSP → orkiestrator → Ledger/DWH (bez PAN).

7. 2 Miękki spadek i retrai

Autoryzacja bez SCA może zwrócić „miękki spadek (kod)” → powtórzyć płatność z SCA.
Orkestrator trzyma samochód państwowy prób: bez SCA → miękki spadek → 3DS2 → Auth.

7. 3 Multi-PSP

Sprawdź obsługę wersji 3DS (2. 1/2. 2/2. 3), aplikacja-SDK, oddzielone od produkcji.
Smart-routing: jeśli ACS ulegnie degradacji u niektórych emitentów, należy użyć ścieżki backupu (jeśli pozwalają na to zasady/systemy).

8) Wzory UX, które zwiększają konwersję

Native/SDK w aplikacjach mobilnych: mniej przekierowań, większa kompletność.
Wstępne zbieranie danych (e-mail, adres, sygnały behawioralne) do 3DS.
Przezroczyste ekrany oczekujące i przezroczyste teksty (lokalizacja według języka/regionu).
Timeouts z miękkim powrotem do płatności i powtórzyć wyzwanie.
Whitelisting prompt: zaoferować klientowi dodanie handlowca do zaufanych banków (jeśli są dostępne).

9) Błędy i skrajne przypadki

Timeout/Niedostępny ACS → poprawne kody i powtórzenie (lub wpadka według zasad).
Obniżka wersji: jeśli 2. 2/2. 3 niedostępne, wałek do kompatybilnej wersji.
Metoda częściowa: jeśli metoda 3DS nie została ukończona, nadal wysyłaj AReq - lepsze dane częściowe niż zero.
Przepływy mieszane: jednocześnie weryfikacja adresu 3DS + AVS - prawidłowo mapować statusy.
Obciążenie zwrotne po 3DS: Spór z artefaktami (INE, CAVV, ARes/CRes refs).

10) Dokumenty i artefakty do przechowywania

Identyfikatory transakcji 3DS (dsTransID, DSServerTransID).
Wyniki uwierzytelniania (statusy ECI, CAVV/AVV, ARes/CRes).
Dzienniki SDK (bez PII/PAN), znaczniki czasu i kody błędów.
MIT łączy do początkowego CIT dla subskrypcji/powtórzeń.
Zasady obsługi wyłączeń miękkich i TRA.

11) Metrics & Goals (iGaming KPI)

Konwersja

Szybkość zakończenia 3DS.
Udział beztroskich wyzwań vs (docelowy - bez tarcia).
Wskaźnik porzucenia na ekranach 3DS.

Ryzyko

Wskaźnik oszustw po zmianie odpowiedzialności (poniżej - lepiej).
Udział miękkiego spadku i sukces kolejnych przekładów z 3DS.

Technika

Czas 3DS p95 (inicjacja → wynik).
Błędy SDK/iframe, timeouts ACS.

12) 3DS2 + lista kontrolna startowa SCA

• Podłączony serwer 3DS (wersja 2. 1/2. 2/2. 3), fasola testowa wypracowana.
• Web SDK/Mobile SDK zintegrowane (w-app + skrypty webview).
• Włączone jest gromadzenie danych de-vice/browser (metoda 3DS).
• Oznakowanie CIT/MIT/COF jest prawidłowe; jest przechowywany link do początkowego CIT.
• Nić miękkiego spadku → powtórzenie z SCA jest realizowane w orkiestrze.
• Ekspozycje (TRA/LVP/whitelist) są konfigurowane, a przyczyny/wyniki są rejestrowane.
• Multi-PSP: zweryfikowane wersje 3DS i ścieżka awaryjna.
• Дуборда KPI: frictionless%, challenge success%, abandon, soft-decline.
• Polityka zatrzymywania artefaktów 3DS i odtwarzanie sporów są gotowe.
• Zaplanowano testy wskazówek A/B UX (lokalizacja, teksty, timeouts).

13) Związek z PCI DSS i tokenizacja

3DS2 nie zastępuje PCI DSS: chodzi o uwierzytelnianie, a PCI dotyczy ochrony danych.
w przypadku systemu PAN-safe: wprowadzanie karty w hostowanych polach/iframe; Orkiestra widzi tylko żetony i artefakty 3DS (INE/CAVV).
W przypadku COF/MIT użyj żetonów sieciowych lub żetonów skarbca w celu ograniczenia oszustw i zwiększenia autoryzacji.

14) FAQ krótkie

Czy zawsze muszę robić 3DS? W strefie SCA, tak, jeśli nie ma ważnego wygaśnięcia/wyjątku. Emitent może wymagać zakwestionowania.
Jeśli bank się zepsuł? Użyj zasad retray/timeout i, jeśli to możliwe, innej trasy.
Czy 3DS da wzrost konwersji? Prawidłowo skonfigurowany 3DS2 z bogatymi danymi zwiększa odsetek bezstratnych i zmniejsza oszustwa/obciążenia zwrotne.
Co jest najważniejsze dla sukcesu? Bogate dane kontekstowe, prawidłowe flagi CIT/MIT/COF, szybkie przetwarzanie UX i kompetentne przetwarzanie miękkiego spadku.

15) Podsumowanie

Dla iGaming, 3DS2 + SCA nie jest „obowiązkowym bólem”, ale narzędziem wzrostu: bardziej beztroskie, mniej oszustw, przeniesienie odpowiedzialności na emitenta, stabilna monetyzacja subskrypcji i powtarzające się odpisy. Ułożyć odpowiednie flagi (CIT/MIT/COF), wspierać fragmenty zgodnie z zasadami, zapewnić bezpieczne wejście i zbudować orkiestrę z inteligentnych retras i obserwowalności - wtedy uwierzytelnienie stanie się sojusznikiem, a nie hamulcem konwersji.