3DS 2.2: Frictionless, Challenge — und das Engineering dazwischen

3-D Secure 2.2 teilt die Authentifizierung in zwei Pfade. Frictionless: Der Issuer vertraut den mitgesendeten Risikodaten und genehmigt still — der Kunde sieht nie eine Challenge. Challenge: Der Issuer will Beweise; der Kunde durchläuft OTP oder Biometrie. Der Conversion-Unterschied ist enorm — die eigentliche Produktfrage lautet also: Wer entscheidet, welcher Pfad zündet?

Die naive Antwort ist „immer Challenge“ (sicher, conversion-tödlich) oder „nie“ (schnell, Haftung in die falsche Richtung). Die richtige Antwort ist adaptiv: erst die Transaktion bewerten und die Challenge nur anfordern, wenn das Risiko sie rechtfertigt. Der vertraute Stammkunde auf bekanntem Gerät gleitet durch; der Mitternachts-Erstkauf vom frischen Gerät steigt hoch.

Das Engineering darunter ist der Ort, an dem die meisten Integrationen still brechen. Das ACS leitet den Kunden mit einem Callback zurück — und ACS-Implementierungen wiederholen Callbacks. Ist Ihr Handler nicht idempotent, wird ein doppelter Callback zur doppelten Abbuchung. Die Lösung ist ein zusammengesetzter Idempotenzschlüssel auf (Intent, Authentifizierungstransaktion): Der erste Callback gewinnt, jede Wiederholung erhält dasselbe gespeicherte Ergebnis.

Dazu der Fehler-Zoo: Der Kunde bricht mitten in der Challenge ab, die Bank läuft in den Timeout, der Redirect kommt nie an. Jedes davon muss die Zahlung in einen expliziten „ungeklärt“-Zustand parken, den später ein Abgleichslauf auflöst — niemals raten. Und scheitert die 3DS-Initiierung bei einem Acquirer, kann ein Pre-3DS-Failover den Versuch zu einer anderen Bank umleiten, bevor der Kunde etwas merkt.

Richtig gebaut ist 3DS keine Conversion-Steuer mehr, sondern ein Präzisionsinstrument: Reibung genau dort, wo der Betrug wohnt — unsichtbar überall sonst.