3D-Secure-Tests: So funktioniert 3DS2 und Testkarten für jeden Ablauf

3D Secure (3DS) ist die Authentifizierungsschicht, die die Fraud-Haftung von Händlern auf die Kartenaussteller verlagert. Sie ist gleichzeitig der Teil des Checkout-Tests, der am häufigsten bricht, weil Umleitungen, iframes, mobile SDKs und asynchrone Ergebnisse mitspielen. Dieser Leitfaden zeigt, was Sie testen sollten, welche Testkarten welchen Ablauf auslösen und welche Bugs immer wieder durchrutschen.

Von 3DS1 zu 3DS2 in einem Absatz

3DS1 war der ursprüngliche Browser-Redirect-Ablauf: Der Kunde verließ Ihre Seite, authentifizierte sich auf der Seite des Kartenausstellers und wurde mit einem Ergebnis zurückgeleitet. Visa, Mastercard und American Express haben 3DS1 (3-D Secure 1.0.2) im Oktober 2022 abgeschaltet, und die letzten regionalen Verlängerungen endeten 2023; Testpläne müssen heute daher nur noch EMV 3DS (3DS2) abdecken. 3DS2 übermittelt dem Kartenaussteller deutlich mehr Geräte- und Transaktionsdaten, sodass er reibungslos zustimmen (ohne Nutzerinteraktion) oder eine Challenge ausgeben kann. Es gibt zwei Kanäle: einen Browser-Ablauf, der Gerätedaten über ein verstecktes 3DS-Method-iframe erfasst und die Challenge in einem iframe (oder über eine vom Anbieter gehostete Umleitung) anzeigt, und einen App-Ablauf, der in nativen Mobile-Apps das 3DS-SDK verwendet.

Die drei Ergebnisse, die Sie behandeln müssen

Jede 3DS-Transaktion endet auf eine von drei Arten, und alle drei brauchen explizite UI-Zustände:

1. Reibungsloser Erfolg — die Authentifizierung gelingt ohne Nutzerinteraktion. Das häufigste 3DS2-Ergebnis.
2. Challenge — der Kunde muss sich authentifizieren (OTP, Freigabe in der App). Behandeln Sie sowohl Erfolg als auch Fehlschlag/Abbruch.
3. Nicht registriert / nicht unterstützt — die Karte oder der Kartenaussteller nimmt nicht teil. Entweder findet gar keine Authentifizierung statt, oder das Kartennetzwerk antwortet stellvertretend für den Aussteller mit einem Attempt (Authentifizierungsversuch). Je nach Konfiguration Ihres Zahlungs-Gateways führen Sie die Transaktion fort oder lassen sie fehlschlagen.

Technisch ist jedes Ergebnis ein transStatus-Wert: Y (authentifiziert), A (Versuch; verlagert die Haftung in der Regel trotzdem auf den Kartenaussteller), N (nicht authentifiziert), R (abgelehnt; nicht autorisieren), U (nicht verfügbar, ein technischer Fehler ohne Haftungsverlagerung). C und D bedeuten, dass eine Challenge bzw. eine entkoppelte Authentifizierung noch läuft.

Die Fehlerpfade sind der Punkt, an dem Checkouts brechen: Eine abgebrochene Challenge ist nicht dasselbe wie eine Ablehnung, und Nutzer, die das Modal schließen, müssen es erneut versuchen können, ohne den ganzen Warenkorb neu aufzubauen.

Stripe-Testkarten für 3DS-Abläufe

Stripe dokumentiert eigene Testnummern für das Authentifizierungsverhalten:

Diese Nummern sind ausschließlich für die Sandbox gedacht. Für andere Anbieter dokumentiert Adyen 4917 6100 0000 0000 (Visa mit 3DS2-Registrierung; Ablaufdatum 03/2030, CVC 737) für Challenge-Abläufe sowie 4111 1111 1111 1111 unter seinen allgemeinen Visa-Testkarten. Prüfen Sie immer die aktuelle Anbieter-Dokumentation — das Verhalten von Testkarten ändert sich ohne Ankündigung.

Eine ausführlichere Liste finden Sie in unserer Referenz der Testkartennummern.

Checkliste für die Sandbox-Einrichtung

• Aktivieren Sie 3DS im Dashboard des Zahlungs-Gateways, nicht nur im API-Aufruf. Viele Gateways haben einen Kontoschalter, der die Authentifizierung im Testmodus stillschweigend deaktiviert.
• Verwenden Sie das 3DS2-SDK in nativen Apps, und testen Sie den Browser-Ablauf (iframe und jede Umleitung, die Ihr Anbieter nutzt) separat.
• Setzen Sie Rücksprung-URLs für jede Umgebung auf die Whitelist, auch für lokale Dev-Tunnel.
• Testen Sie auf echten Mobilgeräten, nicht nur mit schmalen Desktop-Viewports. In-App-Browser (Instagram, TikTok, Banking-Apps) verhalten sich anders als Safari und Chrome.
• Halten Sie das Challenge-Fenster responsiv. Eine Challenge in einem iframe mit fester Höhe ist ein klassischer Conversion-Killer.

Bugs, die durchrutschen

• Warenkorb geht bei der Umleitung verloren. Speichern Sie die Bestellung, bevor Sie die Authentifizierung starten, nicht danach.
• Zurück-Taste des Nutzers wird nicht behandelt. Browser stellen die Seite aus der bfcache wieder her; Ihr JS muss den Zahlungsstatus neu abfragen, statt einen frischen Ladevorgang anzunehmen.
• Doppelte Übermittlung. Nutzer klicken zweimal auf „Bezahlen“, während die Challenge offen ist. Verwenden Sie Idempotenzschlüssel für die Autorisierungsanfrage.
• Erfolg nach der Challenge wird angenommen. Das Authentifizierungsergebnis ist ein separates Signal; die Autorisierung kann danach trotzdem abgelehnt werden.
• Asynchrone Webhooks werden ignoriert. Manche 3DS2-Abläufe schließen asynchron ab. Wenn Sie nur auf die Umleitung hören, verpassen Sie Ergebnisse.
• Falscher Betrag oder falsche Währung. Die Authentifizierung gilt für den Betrag und die Währung, die Sie übermittelt haben; ändert sich der Warenkorb, authentifizieren Sie erneut (bei Stripe bedeutet eine Betragsänderung an einem PaymentIntent, dass er erneut bestätigt werden muss).

Wie Sie ohne echte Karten testen

Sie brauchen keine echte Karte, um 3DS zu testen. Testkarten des Anbieters plus generierte Daten decken die gesamte Matrix ab:

1. Nutzen Sie die Anbieterkarten für erfolgreiche, fehlgeschlagene und reibungslose authentifizierte Abläufe.
2. Nutzen Sie unseren Kartengenerator für große Mengen strukturell gültiger Nummern in Last-, Fuzzing- und UI-Tests.
3. Nutzen Sie den erweiterten Generator, wenn Sie jede Kombination eines bestimmten Musters brauchen.
4. Validieren Sie jede Testnummer mit dem Luhn-Validator.

Zusammenfassung

Beim 3DS-Testing geht es überwiegend darum, die unschönen Pfade abzudecken: abgebrochene Challenges, fehlgeschlagene Authentifizierung, asynchrone Ergebnisse und mobile Browser. Testkarten der Anbieter lösen jeden Ablauf gezielt aus, und ein generierter Datensatz füllt die Lücken. Behandeln Sie die Authentifizierung als eigene Zustandsmaschine neben der Autorisierung, dann vermeiden Sie die Mehrheit der Produktionsvorfälle.