Wie würdest du einen Checkout- und Zahlungsflow end-to-end testen?

Deck den glücklichen Pfad ab, dann die geldspezifischen Risiken: abgelehnte und teilautorisierte Karten, Timeouts, bei denen die Belastung durchgeht, aber die Antwort verloren geht, doppelte Submits, Rückerstattungen und Teilerstattungen, Währung und Rundung, das Zusammenspiel von Steuer und Rabatt und Bestand, der sich mitten im Checkout ändert. Nutz die Sandbox-Testkarten des Anbieters und prüf, was das Backend aufgezeichnet hat, statt dem Bestätigungsbildschirm zu trauen.

Der glückliche Pfad kostet zehn Minuten; alles Wertvolle liegt in den Fehlermodi, denn das ist der Flow, in dem ein Bug direkt Geld kostet. Der Fall, den ich immer zuerst teste, ist die unterbrochene Transaktion: der Anbieter autorisiert die Belastung, dann kommt die Antwort nie zurück, läuft in ein Timeout, oder der Nutzer schließt den Tab. Existiert die Bestellung? Ist der Kunde belastet, ohne etwas dafür zu haben? Das ist das schlimmste Ergebnis im ganzen System und braucht Abgleichlogik, keine Hoffnung. Daneben: doppelt auf Absenden klicken und zurückgehen und erneut absenden, was idempotent sein sollte statt zweimal zu belasten. Dann die spezifischen Antworten des Anbieters über dessen Sandbox-Testkarten: Ablehnungen, unzureichende Deckung, abgelaufene Karte und eine Karte, die eine zusätzliche Authentifizierung auslöst, denn dieser Pfad hat seine eigene Weiterleitung und seine eigenen Bruchstellen. Dann die Geldarithmetik: Währungen mit abweichender Nachkommastellenzahl, Rundung bei einem prozentualen Rabatt, Steuer vor oder nach dem Rabatt, und ein Gutschein, der den Bestellwert übersteigt. Außerdem Bestand, der auf null geht, während der Kunde auf dem Zahlungsbildschirm sitzt. Und ich prüfe gegen die Datenbank und das Anbieter-Dashboard, nie gegen die Bestätigungsseite.