3-D Secure 2. 0 și SCA

1) De ce operatorul iGaming 3DS2 și ce este SCA

3-D Secure 2. x (EMV 3DS) - protocolul de autentificare al titularului cardului în comerțul electronic.
SCA (Strong Customer Authentication) este o cerință de reglementare (PSD2/UK) care necesită verificarea cu doi factori într-o serie de scenarii.

• Schimbarea răspunderii: prin autentificarea cu succes, riscul de fraudă trece la emitent.
• Conversia de mai sus vs 3DS1: colectarea elementelor de date 100 + permite fără frecare fără provocare.
• script-uri native: SDK pentru iOS/Android, în aplicație, decuplat și în afara benzii de confirmare.

2) Roluri și componente (EMV 3DS)

3DS Server (cu tine sau PSP): generează cereri la diagramă, agregează datele dispozitivului, gestionează versiunile 2. 1/2. 2/2. 3.
Directory Server (DS): router schemă (Visa/Mastercard/AmEx, etc.).
Server de control acces (ACS): server emitent; ia o decizie: fără frecare sau provocare.
SDK/Metodă: colectarea semnalelor dispozitivului (amprentare), web-SDK/iframe și mobile-SDK.

3) fluxuri tipice UX

3. 1 Fără frecare (fără provocare)

1. Comerciant/PSP → DS: AReq cu date 3DS (dispozitiv, istoric, semnale de risc).
2. DS/ACS → ARes (fără frecare) - autentificat fără intervenția utilizatorului.
3. Următorul → Auth.

Când funcționează: risc scăzut, lista albă (Trusted Benefical), HDL, date de calitate.

3. 2 Provocare (cu provocare)

1. ARes necesită CReq/CRes (OTP, confirmare push la bancă, biometrie).
2. După succes, → de autorizare, schimbarea răspunderii este salvată.

3. 3 Decuplat/Out-of-Band

Confirmarea în cererea băncii fără redirecționare. Util în scenariile mobile.

3. 4 3RI (3DS Requestor inițiat)

Folosit pentru MIT (tranzacții inițiate de comercianți) - abonament, retray. Nu există SCA pe fiecare reluare, dar este necesară o referință validă la CIT-ul inițial.

4) SCA: dacă este obligatoriu și dacă este valabil

Obligatoriu: majoritatea tranzacțiilor de comerț electronic în SEE/UK dacă emitentul și achizitorul se află în zona SCA.
Out-of-scope: MOTO (e-mail/telefon), unele canale corporative, rute inter-zone (TRA emitentului se poate aplica).

4. 1 Excepţii

TRA (Analiza riscului tranzacției): risc scăzut de furnizor/bancar (confirmat prin valori de fraudă).
LVP (Low-Value Payments): sume mici, cu praguri de emitent și contoare.
Lista albă (Benefic de încredere): Destinatarul din lista albă a clientului la emitent.
Secure Corporate/Merchant Initiated (MIT): write-off-uri ulterioare în afara SCA dacă există un CIT inițial cu SCA și referințe corecte.

5) Marcarea tranzacțiilor și steaguri pentru iGaming

CIT (Client iniţiat tranzacţie) - iniţială write-off, de obicei, necesită SCA (sau expirarea).
COF recurent/neprogramat MIT: reduceri ulterioare; nu necesită SCA dacă există o legătură cu CIT-ul original (link-uri/identificatori inter-comerciant).
Indicatorii corecți din cererile PSP/schemă sunt esențiali pentru schimbarea răspunderii și sărirea SCA pe replici.

6) Date care afectează soluția ACS

• Dispozitiv/Browser: utilizator-agent, acceptă anteturi, ecran, fus orar, limbă.
• Datele contului: vârsta contului, ultima dată a parolei, numărul de conectări nereușite.
• Date tranzacție: MCC/categorie, sumă/monedă, încercări anterioare, viteză.
• Expediere/facturare: potrivire adresă, istoricul destinatarului.
• 3DS metoda de finalizare indicator: 3DS Metoda (amprentă digitală) au timp pentru a lucra afară.
• Cu cât contextul este mai bogat, cu atât sunt mai mari șansele de a rămâne fără fricțiuni.

7) fluxurile de integrare orchestrator de plată

7. 1 Secvență (web/mobil)

1. Inițiați 3DS (3DS Server ↔ DS/ACS) → primiți ARe.
2. Dacă provocarea → rula CReq/CRes prin SDK/iframe.
3. Auth → succes (autorizare) cu rezultat 3DS (ICE, CAVV/criptogramă, dsTransID).
4. Webhook PSP → orchestrator → Ledger/DWH (fără PAN).

7. 2 Soft-declin și retrai

Autorizarea fără SCA poate returna „soft-declin (cod)” → repeta plata cu SCA.
Orkestrator deține mașina de stat a încercărilor: nu SCA soft-declin Auth.

7. 3 Multi-PSP

Verificați suportul pentru versiunile 3DS (2. 1/2. 2/2. 3), app-SDK, decuplat.
Rutare inteligentă: dacă ACS se degradează la unii emitenți, utilizați o cale de rezervă (dacă politicile/schemele permit).

8) Modele UX care stimulează conversia

Nativ/SDK în aplicațiile mobile: mai puține redirecționări, o completitudine mai mare.
Pre-colecta date (e-mail, adresa, semnale comportamentale) până la 3DS.
Ecrane de așteptare transparente și texte clare (localizare după limbă/regiune).
Timeouts cu soft return to payment și repetați provocarea.
Whitelisting prompt: oferiți clientului să adauge comerciant la cele de încredere ale băncii (acolo unde sunt disponibile).

9) Erori și cazuri extreme

Timeout/Indisponibil ACS → coduri corecte și repetarea (sau rezervă prin politică).
Versiunea downgrade: dacă 2. 2/2. 3 nu este disponibil, rollback la versiunea compatibilă.
Metoda parțială: dacă metoda 3DS nu a fost finalizată, trimiteți totuși AReq - date parțiale mai bune decât zero.
Fluxuri mixte: simultan 3DS + verificarea adresei AVS - statusuri de hartă corectă.
Chargeback după 3DS: Dispută cu artefacte (ICE, CAVV, ARes/CRes refs).

10) Documente și artefacte pentru a păstra

ID-uri de tranzacție 3DS (dsTransID, threeDSServerTransID).
Rezultatele autentificării (ICE, CAVV/AVV, stările ARes/CRes).
Jurnalele SDK (fără PII/PAN), marcajele de timp și codurile de eroare.
Link-uri MIT la CIT inițial pentru abonamente/repetări.
Soft-declin și TRA politici de manipulare excepție.

11) Măsurători și obiective (KPI-uri iGaming)

Conversie

3DS rata de finalizare.
Ponderea frictionless vs challenge (țintă - ↑ fără fricțiuni).
Rata de abandon pe ecranele 3DS.

Risc

Rata de fraudă după schimbarea răspunderii (mai jos - mai bine).
Ponderea declinului moale și a succesului retroactivelor ulterioare cu 3DS.

Tehnica

Timpul 3DS p95 (rezultatul → de iniţiere).
SDK/iframe erori, ACS timeout.

12) 3DS2 + lista de start SCA

• 3DS Server conectat (versiunea 2. 1/2. 2/2. 3), fasole de testare a lucrat.
• Web SDK/Mobile SDK integrat (în aplicație + scripturi webview).
• Colectarea datelor de vice/browser este activată (metoda 3DS).

Marcajele CIT/MIT/COF sunt corecte; un link către CIT-ul inițial este stocat.

• Fir soft-declin → repetarea cu SCA este implementat în orchestrator.
• Expunerile (TRA/LVP/whitelist) sunt configurate și motivele/rezultatele sunt înregistrate.
• Multi-PSP: versiuni 3DS și cale de rezervă verificate.
• Дэшборды KPI: frictionless%, provocare succes%, abandon, soft-declin.
• Politicile de păstrare a artefactelor 3DS și playbookurile de dispute sunt gata.

Testele de aluzie A/B UX (localizare, texte, timeout) sunt programate.

13) Relația cu PCI DSS și tokenization

3DS2 nu înlocuiește PCI DSS: este vorba despre autentificare, iar PCI este despre protecția datelor.
Pentru PAN-safe: introducerea cardului in campurile gazduite/iframe; orchestratorul vede doar jetoane și artefacte 3DS (ICE/CAVV).
Pentru COF/MIT, utilizați token-uri de rețea sau token-uri pentru a reduce frauda și pentru a crește autorizația.

14) Întrebări frecvente scurt

Trebuie să fac mereu 3DS? Într-o zonă SCA, da, dacă nu există o expirare/excepție valabilă. Emitentul poate solicita o provocare.
Dacă banca s-a stricat? Utilizați politici de retractare/timeout și, dacă este posibil, o altă rută.
Va da 3DS o creștere a conversiei? O 3DS2 configurată corespunzător cu date bogate crește proporția de frictionless și reduce frauda/chargebacks.
Ce este cel mai important pentru succes? Date contextuale bogate, steaguri CIT/MIT/COF corecte, UX rapid și procesare soft-declin competentă.

15) Rezumat

Pentru iGaming, 3DS2 + SCA nu este o „durere obligatorie”, ci un instrument de creștere: mai multă fraudă, mai puțină fraudă, transferul responsabilității către emitent, monetizarea stabilă a abonamentelor și scrierea repetată. Așezați steagurile potrivite (CIT/MIT/COF), sprijiniți extrase conform regulilor, furnizați o intrare pan-sigură și construiți un orchestrator cu retrase inteligente și observabilitate - apoi autentificarea va deveni un aliat, nu o frână de conversie.