3-D Secure 2. 0 und SCA

1) Warum iGaming-Betreiber 3DS2 und was SCA ist

3-D Secure 2. x (EMV 3DS) ist das Authentifizierungsprotokoll des Karteninhabers im E-Commerce.
SCA (Strong Customer Authentication) ist eine regulatorische Anforderung (PSD2/UK), die eine Zwei-Faktor-Überprüfung in einer Reihe von Szenarien vorschreibt.

• Liability shift: Bei erfolgreicher Authentifizierung geht das Betrugsrisiko auf den Emittenten über.
• Höhere Konversion vs 3DS1: Das Sammeln von 100 + Data-Elementen ermöglicht eine frictionless ohne Herausforderung.
• Native Szenarien: SDK für iOS/Android, In-App, Decoupled und Out-of-Band-Bestätigung.

2) Rollen und Komponenten (EMV 3DS)

3DS Server (bei Ihnen oder bei PSP): bildet die Abfragen ins Schema, aggregiert die Daten dewysa, verwaltet die Versionen 2. 1/2. 2/2. 3.
Directory Server (DS): Router-Systeme (Visa/Mastercard/AmEx, etc.).
Access Control Server (ACS): Server des Emittenten; trifft die Entscheidung: frictionless oder challenge.
SDK/Method: Erfassung von Gerätesignalen (Fingerprinting), Web-SDK/Iframe und Mobile-SDK.

3) Typische UX-Streams

3. 1 Frictionless (keine Herausforderung)

1. Merchant/PSP → DS: AReq mit 3DS-Daten (Gerät, Historie, Risikosignale).
2. DS/ACS → ARes (frictionless): Authentifizierung ohne Benutzereingriff bestanden.
3. Als nächstes → die Autorisierung (Auth).

Wenn es ausgelöst wird: geringes Risiko, Whitelist (Trusted Beneficiary), HDL, qualitative Daten.

3. 2 Challenge (mit Challenge)

1. ARes erfordert CReq/CRes (OTP, Push-Bestätigung in der Bank, Biometrie).
2. Nach dem Erfolg der → Autorisierung wird die Liability Shift beibehalten.

3. 3 Decoupled / Out-of-Band

Bestätigung in der Bank-App ohne Umleitung. Nützlich in mobilen Szenarien.

3. 4 3RI (3DS Requestor Initiated)

Verwendet für MIT (Merchant-Initiated Transactions) - Abonnements, Retrays. Kein SCA bei jeder Wiederholung, aber ein korrekter Verweis auf den initialen CIT ist erforderlich.

4) SCA: wo verpflichtend und wo gültig

Obligatorisch: die meisten E-Commerce-Transaktionen im EWR/UK, wenn Emittent und Acquirer im SCA-Bereich sind.
Off-Zone/Out-of-Scope: MOTO (Mail/Telefon), einige Unternehmenskanäle, Interzonenrouten (Emittenten-TRA kann angewendet werden).

4. 1 Ausnahmen (Exemplare)

TRA (Transaction Risk Analysis): geringes Risiko des Anbieters/der Bank (bestätigt durch Betrugsmetriken).
LVP (Low-Value Payments): kleine Beträge mit Schwellenwerten und Zählern des Emittenten.
Whitelist (Trusted Beneficiary): Empfänger auf der Whitelist des Kunden beim Emittenten.
Secure Corporate/Merchant Initiated (MIT): nachträgliche Abbuchungen außerhalb von SCA, wenn es ein initiales CIT mit SCA und korrekte Referenzen gibt.

5) Transaktionskennzeichnung und Flags für iGaming

CIT (Customer Initiated Transaction): Primäre Abschreibung, erfordert in der Regel SCA (oder Ausweisung).
MIT Recurring/Unscheduled COF: nachträgliche Abschreibungen; kein SCA erforderlich, wenn eine Verknüpfung mit dem ursprünglichen CIT (Interdimensional References/Identifiers) besteht.
Korrekte Indikatoren in PSP/Schema-Anfragen sind entscheidend für die Liability Shift und das Überspringen von SCA bei Wiederholungen.

6) Daten, die die ACS-Entscheidung beeinflussen

• Device/Browser: user-agent, accept headers, screen, timezone, language.
• Kontodaten: Alter des Kontos, Datum des letzten Passworts, Anzahl der fehlgeschlagenen Anmeldungen.
• Transaktionsdaten: MCC/Kategorie, Betrag/Währung, vorherige Versuche, Velocity.
• Versand/Billing: Adressübereinstimmung, Empfängerverlauf.
• 3DS Method Completion Indicator: Hat die 3DS Method (Fingerprint) funktioniert?
• Je reicher der Kontext ist, desto höher ist die Chance auf Frictionless.

7) Integrationsströme mit Payment Orchestrator

7. 1 Sequenz (web/mobile)

1. Initiate 3DS (3DS Server ↔ DS/ACS) → ARes.
2. Wenn die Herausforderung →, CReq/CRes über SDK/iframe auszuarbeiten.
3. Erfolg → Auth (Autorisierung) mit Angabe des 3DS-Ergebnisses (ECI, CAVV/cryptogram, dsTransID).
4. Webhook PSP → Orchestrator → Ledger/DWH (ohne PAN).

7. 2 Soft-decline und Retrays

Autorisierung ohne SCA kann 'soft-decline (code)' zurückkehren → die Zahlung mit SCA wiederholen.
Der Orchestrator hält die State-Maschine der Versuche: no SCA → soft-decline → 3DS2 → Auth.

7. 3 Multi-PSP

Überprüfen Sie die Unterstützung für 3DS-Versionen (2. 1/2. 2/2. 3), app-SDK, decoupled.
Smart-Routing: Wenn ACS bei einem Teil der Emittenten abgebaut wird, verwenden Sie einen Backup-Pfad (wenn die Richtlinien/Schemata dies zulassen).

8) Konversionssteigernde UX-Muster

Native/SDK in mobilen Anwendungen: weniger Umleitungen, höhere Vollständigkeit.
Pre-collect Daten (E-Mail, Adresse, Verhaltenssignale) bis 3DS.
Transparente Erwartungsbildschirme und verständliche Texte (Lokalisierung nach Sprache/Region).
Timeouts mit sanfter Rückkehr zur Zahlung und Wiederholung der Herausforderung.
Whitelisting prompt: Bieten Sie dem Kunden an, das Merchant zu den Trusts der Bank hinzuzufügen (wo verfügbar).

9) Fehler und Extremfälle

Timeout/Unavailable ACS → korrekte Codes und Wiederholung (oder Fallback auf Politik).
Version downgrade: wenn 2. 2/2. 3 nicht verfügbar, Rollback zur kompatiblen Version.
Partielle Methode: Wenn die 3DS-Methode nicht beendet ist, senden Sie trotzdem AReq - besser Teildaten als Null.
Mixed flows: gleichzeitig 3DS + addressable verification AVS - korrekte Mappite-Zustände.
Chargeback nach 3DS: mit Artefakten (ECI, CAVV, ARes/CRes refs) bestreiten.

10) Dokumente und Artefakte, die aufbewahrt werden müssen

3DS Transaktions-IDs (dsTransID, threeDSServerTransID).
Authentifizierungsergebnisse (ECI, CAVV/AVV, ARes/CRes-Status).
SDK-Protokolle (ohne PII/PAN), Zeitstempel und Fehlercodes.
MIT-Links zum Initial CIT für Abonnements/Wiederholungen.
Richtlinien für die Verarbeitung von Soft-Decline- und TRA-Ausnahmen.

11) Metriken und Ziele (KPIs für iGaming)

Konversion

3DS-Abschlussrate (Anteil der erfolgreich abgeschlossenen Authentifizierung).
Der Anteil von frictionless vs challenge (das Ziel ist ↑ frictionless).
Abandonment Rate auf 3DS-Bildschirmen.

Risiken

Freud Rate nach Liability Shift (unten ist besser).
Soft-Decline-Anteil und Erfolg nachfolgender Retraits mit 3DS.

Technik

Zeit 3DS p95 (Initiation → Ergebnis).
SDK/iframe-Fehler, ACS-Timeouts.

12) Checkliste für den Start von 3DS2 + SCA

• 3DS Server angeschlossen (Version 2). 1/2. 2/2. 3), Test-Verband wird ausgearbeitet.
• Web-SDKs/Mobile-SDKs sind integriert (In-App + Webview-Skripte).
• Sammlung von De-Vice/Browser-Daten aktiviert (3DS-Methode).
• Die CIT/MIT/COF-Kennzeichnungen sind korrekt. wird ein Verweis auf den initialen CIT gespeichert.
• Der Soft-Decline-Stream → die Wiederholung mit SCA werden im Orchestrator implementiert.
• Exemptions (TRA/LVP/whitelist) werden konfiguriert und Ursachen/Ergebnisse protokolliert.
• Multi-PSP: 3DS-Versionen und Fallback-Pfad geprüft.
• Дэшборды KPI: frictionless %, challenge success %, abandon, soft-decline.
• 3DS-Artefakt-Aufbewahrungsrichtlinien und Dispute-Playbooks sind bereit.
• A/B-Tests der UX-Hinweise (Lokalisierung, Texte, Timeouts) sind geplant.

13) Vernetzung mit PCI DSS und Tokenisierung

3DS2 ersetzt PCI DSS nicht: Es geht um Authentifizierung und PCI um Datenschutz.
Für PAN-safe: Eingabe der Karte in hosted fields/iframe; Der Orchestrator sieht nur Token und 3DS-Artefakte (ECI/CAVV).
Verwenden Sie für COF/MIT Netzwerk- oder Vault-Token, um den Betrug zu reduzieren und die Autorisierung zu erhöhen.

14) FAQ kurz

Muss ich immer 3DS machen? In der SCA-Zone ja, es sei denn, es gibt eine korrekte Erweiterung/Ausnahme. Der Emittent kann eine Challenge verlangen.
Wenn die Bank kaputt ist? Verwenden Sie Retray-/Timeout-Richtlinien und, wenn möglich, eine andere Route.
Wird 3DS die Konversionsrate erhöhen? Eine richtig konfigurierte 3DS2 mit reichen Daten erhöht den Anteil der Frictionless und reduziert den Betrug/Charjbacks.
Was ist am kritischsten für den Erfolg? Umfangreiche Kontextdaten, korrekte CIT/MIT/COF-Flags, schnelle UX und kompetente Soft-Decline-Verarbeitung.

15) Zusammenfassung

Für iGaming ist 3DS2 + SCA kein „obligatorischer Schmerz“, sondern ein Wachstumsinstrument: mehr Frictionless, weniger Betrug, Übertragung der Verantwortung auf den Emittenten, stabile Monetarisierung von Abonnements und wiederholten Abschreibungen. Setzen Sie die richtigen Flaggen (CIT/MIT/COF), unterstützen Sie Auszüge nach Regeln, sorgen Sie für pansichere Eingaben und bauen Sie einen Orchestrator mit smarten Retrays und Beobachtbarkeit auf - dann wird die Authentifizierung zum Verbündeten, nicht zur Konversionsbremse.