3D-Secure-Tests: 3DS1 vs. 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.
3DS1 vs. 3DS2 in einem Absatz
3DS1 ist der ursprüngliche Browser-Redirect-Ablauf: Der Kunde verlässt Ihre Seite, authentifiziert sich auf der Seite des Kartenausstellers und wird mit einem Ergebnis zurückgeleitet. 3DS2 ersetzt die Umleitung durch ein SDK oder Device-Fingerprinting: Der Kartenaussteller erhält zusätzliche Geräte- und Transaktionsdaten und kann reibungslos zustimmen (ohne Nutzerinteraktion) oder eine Challenge ausgeben (ein Modal innerhalb der Seite oder als Fallback eine Umleitung in Browsern, die das SDK nicht unterstützen). Die meisten Zahlungs-Gateways unterstützen 3DS1 weiterhin für ältere Integrationen, deshalb deckt ein echter Testplan beides ab.
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:
- Reibungsloser Erfolg — die Authentifizierung gelingt ohne Nutzerinteraktion. Das häufigste 3DS2-Ergebnis.
- Challenge — der Kunde muss sich authentifizieren (OTP, Freigabe in der App). Behandeln Sie sowohl Erfolg als auch Fehlschlag/Abbruch.
- Nicht registriert / nicht unterstützt — die Karte nimmt nicht teil. Je nach Konfiguration Ihres Zahlungs-Gateways führen Sie die Transaktion fort oder lassen sie fehlschlagen.
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:
| Kartennummer | Was sie auslöst |
|---|---|
| 4000 0025 0000 3155 | Erfordert 3D-Secure-Authentifizierung |
| 4000 0027 6000 3184 | 3DS erforderlich, damit die Zahlung gelingt |
| 4000 0000 0000 3055 | Unterstützt 3D Secure 2 |
| 4000 0000 0000 3220 | 3DS2 — der Challenge-Ablauf muss durchlaufen werden |
Diese Nummern sind ausschließlich für die Sandbox gedacht. Für andere Anbieter dokumentiert Adyen 4917 6100 0000 0000 für 3DS1-Szenarien sowie die generischen Erfolgskarten (4242…, 4111 1111 1111 1111) in der Sandbox. 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, wo es verfügbar ist, und testen Sie den Redirect-Fallback 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 ist an die Zahlungsabsicht gebunden; wenn Sie den Warenkorb zwischen Authentifizierung und Erfassung ändern, wird sie ungültig.
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:
- Nutzen Sie die Anbieterkarten für erfolgreiche, fehlgeschlagene und reibungslose authentifizierte Abläufe.
- Nutzen Sie unseren Kartengenerator für große Mengen strukturell gültiger Nummern in Last-, Fuzzing- und UI-Tests.
- Nutzen Sie den erweiterten Generator, wenn Sie jede Kombination eines bestimmten Musters brauchen.
- 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.