Eine Checkliste Zahlungsformular testen beginnt fast immer bei den Feldern und sollte bei den Zuständen beginnen. Feldprüfungen sind schnell geschrieben und decken den leichten Teil ab; ob eine abgelehnte Zahlung den Kunden in eine Sackgasse schickt oder ob ein doppelter Klick zwei Bestellungen erzeugt, entscheidet sich in der Zustandsverwaltung und wird von Feldtests nie berührt.
Dieser Beitrag beschreibt die Zustände, die ein Checkout erreichen kann, die drei Arten von Ablehnungen, die Pfade für Wiederholung und Erstattung und zum Abschluss eine Checkliste mit fünfzehn Prüfschritten, die vor dem Start abgearbeitet sein sollte.
Mit den Zuständen beginnen, nicht mit den Feldern
Jeder Checkout hat eine überschaubare Zahl von Zuständen, und die vollständige Liste lässt sich in wenigen Minuten aufschreiben. Sie umfasst mindestens: wartend auf Zahlung, autorisiert aber nicht erfasst, erfasst, ablehnbar, endgültig abgelehnt, Authentifizierung ausstehend, Authentifizierung fehlgeschlagen, abgebrochen, vollständig erstattet, teilweise erstattet und bestritten.
Diese Liste ist der Ausgangspunkt, weil sie die Fragen sichtbar macht, die ein Feldtest nicht stellt. Was sieht der Kunde in jedem dieser Zustände? Was steht in der Datenbank? Welche Benachrichtigung wurde verschickt? Und vor allem: Wie kommt jemand aus diesem Zustand heraus, wenn er es möchte?
Der Nutzen dieser Aufzählung liegt in ihrer Vollständigkeit. Solange die Liste unvollständig ist, sind die fehlenden Fälle nicht falsch implementiert, sondern überhaupt nicht implementiert, und niemand kann das bemerken, weil niemand nach ihnen sucht.
Wie sollte der Ablehnungspfad aussehen?
Ablehnungen sind nicht gleich. Es gibt drei Gruppen, und jede verlangt eine andere Antwort.
Die behebbare Ablehnung. Typischerweise fehlende Deckung. Der Kunde kann eine andere Karte verwenden, also darf das Formular nicht zurückgesetzt werden. Adresse und Kontaktdaten müssen erhalten bleiben, damit der zweite Versuch nicht zu einer Neueingabe wird. Eine Meldung, die auf ein leeres Formular trifft, ist der klassische Fehler in diesem Pfad.
Die endgültige Ablehnung. Typischerweise verbunden mit dem Hinweis, den Herausgeber zu kontaktieren. Ein erneuter Versuch mit derselben Karte kann nicht gelingen. Die Oberfläche sollte deshalb keinen Wiederholungsweg anbieten und stattdessen klar sagen, was der Kunde tun kann.
Der Verarbeitungsfehler. Häufig vorübergehend und ohne Bezug zur Karte. Hier ist ein erneuter Versuch sinnvoll, und die Meldung sollte deutlich machen, dass das Problem nicht bei den Eingaben liegt.
Bei jeder dieser Gruppen sind drei Dinge zu prüfen: die Meldung, die der Nutzer sieht, der Zustand, der in der Datenbank entsteht, und die Frage, ob ein Wiederholungsweg angeboten wird. Die dritte Frage wird am häufigsten ausgelassen, und sie ist die einzige, die für den Kunden unmittelbar zählt.
Haben Sie den Wiederholungspfad getestet?
Der Wiederholungspfad ist der Ort, an dem aus einem funktionierenden Checkout ein doppelt belasteter Kunde wird. Die Fälle, die geprüft werden müssen:
- Der Zahlungsbutton wird zweimal gedrückt, schnell hintereinander.
- Die Verbindung bricht ab, nachdem die Anfrage gesendet wurde, aber bevor die Antwort eintrifft.
- Der Kunde bricht ab, kehrt zum Warenkorb zurück und versucht es erneut.
- Die Authentifizierung gelingt, die Erfassung schlägt fehl, und der Kunde versucht es mit einer anderen Karte.
In allen vier Fällen gilt dieselbe Erwartung: Es darf höchstens eine Bestellung entstehen, und es darf höchstens ein Zahlungsversuch unternommen werden.
Der naheliegende Schutz, den Button nach dem ersten Klick zu deaktivieren, reicht nicht aus. Wenn der erste Aufruf den Server bereits erreicht und der zweite Aufruf auf einem anderen Weg abgesetzt wird, hilft keine Oberflächenlogik. Der belastbare Schutz ist ein Kennzeichen, das je Zahlungsversuch einmal vergeben wird und das der Zahlungsaufruf auswertet. Kommt dasselbe Kennzeichen ein zweites Mal an, muss er das ursprüngliche Ergebnis zurückgeben, statt eine neue Zahlung auszulösen.
Erstattungen, Rückbuchungen und Teilerfassungen
Diese Vorgänge finden nach der Zahlung statt, und sie sind im Checkout häufig nicht vorgesehen, obwohl sie die Buchhaltung betreffen.
Die vollständige Erstattung ist der einfache Fall. Die teilweise Erstattung ist der Fall, der Fehler erzeugt, weil der Betrag offenbar frei gewählt werden kann. Eine zweite teilweise Erstattung darf in der Summe nicht über den ursprünglichen Betrag hinausgehen, und diese Grenze muss die Anwendung prüfen und nicht der Kunde selbst.
Die Rücknahme einer Autorisierung vor der Erfassung ist der Fall, in dem in der Kundenansicht ein Abbruch entstehen sollte und keine Zahlung. Erscheint in diesem Zustand eine Belastung, ist die Kundenansicht falsch und wird Support kosten.
Die Teilerfassung schließlich ist üblich in Branchen, in denen ein endgültiger Betrag erst nach der Leistung feststeht. Der freigegebene und nicht erfasste Differenzbetrag ist für den Kunden eine Reservierung und muss in der Oberfläche als solche erscheinen. Der typische Fehler in diesem Bereich ist keine Zahlungslogik, sondern eine falsch gezählte Summe irgendwo in der Anzeige.
Die Checkliste
Die folgenden fünfzehn Punkte decken den Checkout vor und nach der ersten echten Zahlung ab. Sie sind bewusst als Zustände und Verhalten formuliert und nicht als Felder.
- Eine erfolgreiche Zahlung je unterstütztem Netzwerk durchgeführt und in der Datenbank geprüft.
- Eine behebbare Ablehnung erzeugt, anschließend eine andere Karte verwendet und die Zahlung erfolgreich abgeschlossen.
- Eine endgültige Ablehnung erzeugt und bestätigt, dass kein Wiederholungsweg angeboten wird und die Erklärung verständlich ist.
- Einen vorübergehenden Verarbeitungsfehler erzeugt und bestätigt, dass ein späterer Versuch gelingt.
- Den Zahlungsbutton doppelt gedrückt und geprüft, dass nur eine Bestellung entstanden ist.
- Die Verbindung nach dem Absenden unterbrochen und geprüft, dass die Bestellung wiederherstellbar ist und nicht als verwaister Datensatz liegen bleibt.
- Den Checkout abgebrochen und geprüft, dass die Bestellung in einem für den Support erklärbaren Zustand ist.
- Die Authentifizierung einmal bestanden, einmal verfehlt und einmal abgebrochen.
- Eine Karte mit Ablaufmonat gleich dem aktuellen Monat abgeschickt, am ersten und am letzten Tag des Monats.
- Eine Karte mit einem Sicherheitscode abgeschickt, dessen Länge nicht zum erkannten Netzwerk passt.
- Die automatische Vervollständigung des Browsers mit einer hinterlegten Karte verwendet und anschließend ein Feld geändert.
- Eine vollständige Erstattung, eine teilweise Erstattung und eine zweite teilweise Erstattung durchgeführt.
- Die Sitzung während der Eingabe ablaufen lassen und danach abgeschickt.
- Über eine sehr langsame Verbindung zweimal abgeschickt und geprüft, dass die später abgesetzte Anfrage das Ergebnis nicht überschreibt.
- Das Formular ausschließlich per Tastatur ausgefüllt und mit einem Bildschirmleser bestätigt, dass Fehlermeldungen vorgelesen werden.
Wer diese Liste abarbeitet, hat mehr Fälle abgedeckt als mit jeder Sammlung von Feldtests. Die Prüfwerte selbst lassen sich dabei vollständig synthetisch halten; der Kartennummern-Generator liefert passende Kombinationen aus Nummer, Ablaufdatum und Sicherheitscode.
Für Entwickler: Zustandsmatrix und Idempotenzprüfung
Die Zustandsmatrix ist die kompakte Form der Liste oben. Zeilen sind die Zustände, Spalten sind die Sichten: Kundenansicht, Administrationsansicht, gespeicherter Datensatz und versendete Benachrichtigung. Jede leere Zelle ist entweder ein Defekt oder ein bewusst nicht unterstützter Fall, und beides sollte man wissen.
Zweitens gehört der Zahlungsendpunkt auf Idempotenz geprüft. Drei Eigenschaften sind zu belegen: Das Kennzeichen ist je Zahlungsversuch eindeutig und nicht je Netzwerkaufruf, es wird mit dem Vorgang zusammen gespeichert, und ein wiederholter Aufruf gibt das ursprüngliche Ergebnis zurück, statt einen neuen Vorgang zu beginnen.
Drittens verdient der Zeitüberschreitungsfall Aufmerksamkeit. Lässt der Client nach einer festgelegten Zeit die Anfrage fallen, kann der Server den Vorgang bereits abgeschlossen haben. Dem Kunden in diesem Zustand einen Fehler zu zeigen, während sein Konto belastet wurde, ist der schlimmste Ausgang des gesamten Ablaufs.
Viertens: Prüfen Sie, was nicht gespeichert werden darf. Die Kartennummer gehört maskiert dargestellt, der Sicherheitscode darf in keinem Protokoll auftauchen, und die Regeln dazu stehen im Beitrag zum Sicherheitscode. Das Ablaufdatum braucht keine Sonderbehandlung beim Speichern, aber eine beim Prüfen, und die Grenzfälle beschreibt der Beitrag zum Ablaufdatum. Zuletzt gehört jede nicht vorgesehene Antwort des Dienstleisters in einem definierten Zweig behandelt, damit ein unbekannter Fehler nicht als Erfolg durchgereicht wird.
Woher die Nummern für die Checkliste kommen
Zwei Quellen ergänzen sich. Die Testkarten eines Zahlungsdienstleisters erzeugen definierte Ergebnisse wie Ablehnung oder ausstehende Authentifizierung und sind daher für die Zustandspfade unverzichtbar; sie funktionieren nur in der Sandbox des jeweiligen Anbieters. Erzeugte Nummern sind dagegen überall verwendbar und decken Formularlogik, Netzwerkerkennung und Grenzfälle ab.
Für die Checkliste oben brauchen Sie beides. Die Szenarien zu Ablehnung und Authentifizierung stammen aus der Dokumentation des Anbieters, die Feld- und Grenzfälle aus dem Werkzeug auf dieser Seite. Wie sich die beiden Quellen ergänzen, beschreibt der Beitrag zu den Anbieter-Testkarten.
Nächste Schritte
Kopieren Sie die fünfzehn Punkte in Ihr Vorgehen zur Abnahme und tragen Sie zu jedem Punkt ein, wer ihn durchgeführt hat. Reine Feldtests wurden damit abgelöst, und die Fälle, die in der Praxis tatsächlich Geld kosten, stehen nun auf der Liste.