Stripe Testkarten sind Karten, die nicht existieren und trotzdem bei jeder Zahlung im Sandbox-Modus ein anderes, vorher festgelegtes Ergebnis auslösen. Sie sind damit mehr als Beispieldaten: Sie sind ein Regelsystem, mit dem sich Erfolg, Ablehnung, fehlende Deckung und ein abgebrochener Authentifizierungsschritt gezielt herbeiführen lassen. Wer sie kennt, kann einen Checkout vollständig durchtesten, bevor die erste echte Zahlung eintrifft.
Dieser Beitrag erklärt, wie solche Karten funktionieren, warum der Blick in die Anbieterdokumentation unverzichtbar ist und wie man daraus eine Testsuite baut, die nicht bei jeder Änderung der Dokumentation zerbricht.
Was eine Anbieter-Testkarte ist
Eine Anbieter-Testkarte ist eine Ziffernfolge, die in einer Nachschlagetabelle des Sandbox-Systems steht. Sendet ein Formular diese Nummer, schlägt der Sandbox nach, welches Ergebnis hinterlegt ist, und antwortet entsprechend. Dabei wird keine Bank kontaktiert, kein Konto belastet und keine Autorisierungsanfrage an ein Netzwerk weitergeleitet.
Diese Konstruktion ist der Grund, warum Testkarten im Sandbox-Modus so starke Werkzeuge sind. Der Anbieter kann Verhalten erzeugen, das im echten Betrieb kaum gezielt herbeizuführen wäre: eine abgelehnte Zahlung wegen fehlender Deckung zum gewünschten Zeitpunkt, eine erzwungene Zusatzauthentifizierung oder einen technischen Fehler mitten in der Verarbeitung. Jedes dieser Ergebnisse ist ein Codepfad, der in der Produktion existiert und der ohne Simulation praktisch nie getestet würde.
Wichtig ist die Umgebungsgrenze. Testkarten wirken ausschließlich in der Sandbox. Gegen einen Produktivschlüssel gesendet, sind sie nichts weiter als eine Ziffernfolge ohne Konto; das Gateway lehnt ab, und der Versuch erscheint im Dashboard. Diese Trennung ist nicht optional, sondern Teil des Vertrags mit dem Anbieter.
Warum veröffentlichen Zahlungsdienstleister eigene Testnummern?
Weil ihre Sandboxes ihre eigene Nachschlagetabelle haben. Eine Nummer, die bei einem Anbieter einen bestimmten Ablehnungsgrund auslöst, kann bei einem anderen unbekannt sein. Es gibt keine anbieterübergreifende Liste von Testkarten mit garantiertem Verhalten, und genau deshalb veröffentlicht jeder Dienstleister seine eigene Übersicht samt Beschreibung des jeweiligen Ergebnisses.
Zusätzlich existieren allgemeine Bereiche, die die Netzwerke für Dokumentation und Sandbox-Nutzung reservieren. Diese Bereiche sind nicht an einen Anbieter gebunden, lösen aber auch kein definiertes Ergebnis aus, weil die Nachschlagetabelle fehlt. Sie sind nützlich für Formulartests und unbrauchbar für Verhaltenstests, und diese Unterscheidung erklärt, warum in manchen Anleitungen beide Arten durcheinander auftauchen.
Die praktische Konsequenz lautet: Verlassen Sie sich nicht auf auswendig gelernte Nummern. Halten Sie fest, aus welcher Version der Anbieterdokumentation eine Nummer stammt, und prüfen Sie die Übersicht, bevor Sie einen Testfall darauf aufbauen. Die übrigen Netzwerkbereiche beschreibt der Netzwerkvergleich.
Die eine Testkarte, die fast jeder Entwickler benutzt
Fast jede Einführung in einen Zahlungsanbieter beginnt mit derselben Nummer, geschrieben als 4242 4242 4242 4242. Sie liegt im Visa-Bereich, erfüllt die Prüfsumme und ist in der Sandbox mit dem Ergebnis erfolgreich verknüpft.
Ein vollständiges Formular braucht dazu nur zwei weitere Angaben: ein beliebiges Ablaufdatum in der Zukunft und einen beliebigen Sicherheitscode mit drei Stellen. Der Sandbox prüft die Struktur und antwortet mit Erfolg.
Diese Nummer hat drei Eigenschaften, die in Erinnerung bleiben sollten. Sie ist kein gültiges Konto, sie ist kein Geheimnis, und sie funktioniert nur in der Sandbox. Dass sie so weit verbreitet ist, macht sie außerdem unbrauchbar als Kennzeichen für echte Fehler: Findet man sie in einem Produktionsprotokoll, ist der wahrscheinlichste Grund ein Testlauf in der falschen Umgebung.
Wie simuliert man eine Ablehnung?
Erfolgsfälle sind einfach, weil sie alle gleich aussehen. Die interessanten Codepfade liegen auf der Ablehnungsseite, und die Anbieterdokumentation listet für jeden Grund eine eigene Nummer. Üblich sind diese Kategorien:
- Eine allgemeine Ablehnung. Das Formular muss eine verständliche Meldung zeigen und darf nicht abstürzen.
- Der Hinweis, den Herausgeber zu kontaktieren. Der Vorgang ist für diese Karte endgültig gescheitert, und der Nutzer sollte nicht zum erneuten Absenden gedrängt werden.
- Fehlende Deckung. Diese Ablehnung ist behebbar, weil der Kunde eine andere Karte verwenden kann.
- Eine abgelaufene Karte. Hiermit lässt sich prüfen, ob die Datumsprüfung im eigenen Formular mit der des Gateways übereinstimmt.
- Ein Verarbeitungsfehler. Dieser Fall ist meist vorübergehend und die richtige Antwort ist ein erneuter Versuch.
- Eine Sperrung wegen Betrugsverdacht. Der Vorgang gehört angehalten, nicht wiederholt.
Der Unterschied zwischen behebbar und endgültig ist der wichtigste Punkt dieser Liste. Nur bei behebbaren Ablehnungen darf die Oberfläche einen erneuten Versuch anbieten. Wer alle Ablehnungen gleich behandelt, schickt Kunden in eine Schleife, aus der sie nicht herauskommen.
Authentifizierung und 3-D Secure testen
Sobald eine Zahlung eine zusätzliche Authentifizierung erfordert, entstehen eigene Zustände, die sich getrennt testen lassen. Die Sandboxes stellen dafür Karten bereit, die die Authentifizierung stets bestehen, stets verfehlen oder ganz ohne Rückfrage durchlaufen.
Die Testaufgabe besteht nicht darin, die drei Varianten zu sehen, sondern die Randfälle zu prüfen. Was passiert, wenn der Kunde die Rückfrage abbricht? Bleibt die Bestellung dauerhaft in einem unfertigen Zustand stehen? Entsteht bei einem zweiten Versuch eine zweite Bestellung, obwohl der Kunde die erste bereits abgeschickt hat? Diese Fragen haben mit Zahlungslogik wenig zu tun und sehr viel mit Zustandsverwaltung, und sie sind der Grund, warum Authentifizierungstests mehr Zeit verdienen, als man ihnen üblicherweise gibt.
Für Entwickler: Szenariolisten schlagen eine einzelne Magienummer
Die zuverlässigste Struktur für Zahlungstests ist keine Liste von Nummern, sondern eine Liste von Ergebnissen. Ein erwarteter Ausgang lässt sich als Satz von Zuständen beschreiben, die der Checkout erreichen können soll: autorisiert, ablehnbar, endgültig abgelehnt, Authentifizierung erforderlich, Authentifizierung fehlgeschlagen, abgebrochen, Zeitüberschreitung.
Zu jedem Zustand gehört eine Karte, und daneben gehört in dasselbe Repository eine kurze Notiz, aus welcher Version der Anbieterdokumentation die Zuordnung stammt. Ohne diese Notiz verliert der Test seine Grundlage, sobald der Anbieter seine Liste ändert, denn die Karte funktioniert weiterhin, löst aber ein anderes Ergebnis aus, und der Fehler sieht wie ein Regressionsfehler in der eigenen Anwendung aus.
Die Sandbox-Zugangsdaten gehören ausschließlich in die Testumgebung. Der häufigste Unfall in diesem Bereich ist ein Produktivschlüssel in einer Entwicklungskonfiguration, und die Folge ist nicht nur ein fehlgeschlagener Test, sondern ein echter Zahlungsversuch.
Karten ohne Anbieterkonto erzeugen
Für Formulartests, Lasttests und Datenbankbefüllungen braucht man oft Nummern, die gar keine bestimmte Antwort auslösen sollen. Hier ist der Kartennummern-Generator die passende Quelle: Er erzeugt Nummern nach den öffentlichen Nummerierungsregeln mehrerer Netzwerke und liefert Ablaufdaten und Platzhalter-Codes gleich mit. Damit lässt sich ein Checkout vollständig befüllen, ohne ein Anbieterkonto anzulegen und ohne Werte aus der Dokumentation abzuschreiben.
Die beiden Quellen ergänzen sich. Erzeugte Nummern üben die Formularlogik und die Erkennung aus, Anbieterkarten üben die Ergebnisbehandlung. Wer nur das eine hat, kennt am Ende entweder die halbe Oberfläche oder die halbe Fachlogik.
Nächste Schritte
Beginnen Sie mit der Erfolgsnummer, um den Grundpfad zu belegen, und fügen Sie danach gezielt einen behebbaren und einen endgültigen Ablehnungsfall hinzu. Halten Sie die Zuordnung zwischen Karte und erwartetem Ergebnis neben dem Test fest, und notieren Sie die Dokumentationsversion. Wenn Sie anschließend die übrigen Prüfschritte durchgehen möchten, führt die Checkliste für Zahlungsformulare durch den Rest.