Eine Kreditkartennummer prüfen klingt nach einer einzelnen Zeile Code und ist in Wahrheit eine Abfolge von fünf Entscheidungen, deren Reihenfolge über die Qualität des Ergebnisses entscheidet. Wer sie falsch ordnet, weist gültige Karten ab, meldet Fehler, die keine sind, und verbirgt echte Defekte hinter Umgebungsfehlern. Wer sie richtig ordnet, erhält ein Formular, das genau die Eingaben zurückweist, die ohnehin niemals funktionieren würden.
Dieser Beitrag beschreibt, wozu die Prüfung dient, in welcher Reihenfolge die Schritte laufen, warum die Prüfung im Browser allein nicht genügt und welche Sätze in einer Fehlermeldung stehen dürfen und welche nicht.
Wozu Prüfung überhaupt dient
Die Prüfung einer Kartennummer hat genau einen Zweck: Sie soll Eingaben abfangen, die technisch nicht funktionieren können, und das möglichst früh und möglichst freundlich. Sie ist Tippfehlerschutz, damit der Nutzer nicht erst nach dem Absenden von einer Ablehnung erfährt, deren Ursache eine vertauschte Ziffer war.
Sie ist ausdrücklich nicht Betrugsabwehr. Betrugsprüfung arbeitet mit Verhaltensmustern, Gerätekennzeichen, Adressabgleich und Risikomodellen; eine Formatprüfung kann dazu nichts beitragen. Sie ist auch kein Eigentumsnachweis. Dass jemand eine Nummer kennt, sagt nichts darüber, ob er sie verwenden darf. Und sie ist kein Ersatz für die Autorisierung, denn nur der Herausgeber kann sagen, ob ein Konto existiert und gedeckt ist.
Wer diese Grenze nicht zieht, baut Prüfungen, die immer strenger werden, weil sie versuchen, eine Aufgabe zu erfüllen, für die sie nicht gedacht sind. Das Ergebnis sind Formulare, die echten Kunden im Weg stehen und Betrug trotzdem durchlassen.
Welche Prüfungen sollten zuerst laufen?
Die Reihenfolge ist keine Geschmacksfrage, sondern folgt daraus, was jede Prüfung voraussetzt. Die belastbare Abfolge lautet:
- Anwesenheit. Ein leeres Feld ist kein Formatfehler, sondern eine fehlende Angabe, und die Meldung sollte das auch sagen.
- Zeichensatz. Definieren Sie ausdrücklich, welche Trennzeichen toleriert werden, entfernen Sie diese und weisen Sie alles Übrige zurück. Dieser Schritt muss vor der Längenprüfung laufen, sonst zählt ein Leerzeichen als Ziffer.
- Länge. Prüfen Sie gegen den Bereich des erkannten Netzwerks und nicht gegen eine feste Zahl wie sechzehn.
- Präfix. Ordnen Sie die Nummer einem veröffentlichten Bereich zu. Schlägt das fehl, wissen Sie nicht, welche Länge überhaupt zulässig wäre.
- Prüfsumme. Der Luhn Algorithmus kommt zuletzt, weil er am teuersten ist und weil sein Ergebnis nur dann aussagekräftig ist, wenn die Eingabe bereits strukturell plausibel ist.
Die häufigste Fehlordnung besteht darin, mit der Prüfsumme zu beginnen, weil sie leicht zu implementieren ist. Das führt zu einer Meldung, die auf fehlerhafte Eingabe hindeutet, während der eigentliche Grund ein Buchstabe oder ein Leerzeichen mitten in der Zeichenfolge ist.
Reicht die Prüfung im Browser?
Nein. Eine Prüfung im Browser ist eine Höflichkeit gegenüber dem Nutzer und keine Kontrolle. Sie läuft auf einem Gerät, das der Nutzer kontrolliert, in einem Programm, das der Nutzer ändern kann, und sie wird umgangen, sobald jemand die Anfrage direkt sendet.
Der Server muss dieselbe Abfolge unabhängig durchlaufen, mit denselben Regeln und demselben Ergebnis. Zwei Implementierungen derselben Logik sind ein bekannter Wartungsaufwand, aber der alternative Weg, die Serverprüfung dem Browser zu überlassen, ist keine Prüfung.
Dazwischen liegt eine dritte Instanz, die oft vergessen wird: Der Zahlungsdienstleister prüft die Daten ebenfalls und lehnt ab, was seine eigenen Regeln verletzt. Diese Ablehnung erreicht die Anwendung als Fehlerantwort ohne Bezug zur Formulareingabe, und wer sie nicht ausdrücklich behandelt, zeigt dem Nutzer eine allgemeine Fehlermeldung für ein Feld, das er noch korrigieren könnte.
Was sollte eine Fehlermeldung sagen?
Eine gute Fehlermeldung nennt die Ursache und den nächsten Schritt. Eine schlechte Meldung nennt ein Urteil. Die brauchbare Aufteilung:
- Feld leer. Hier geht es um eine fehlende Angabe, und der Ton sollte freundlich bleiben. Das ist kein Fehler, sondern ein offener Punkt.
- Zu kurz oder zu lang. Nennen Sie die erwartete Länge, und zwar bezogen auf die Eingabe des Nutzers. Eine Meldung, die sechzehn Ziffern verlangt, ohne den erkannten Bereich zu berücksichtigen, ist schlicht falsch.
- Nicht unterstützte Zeichen. Sagen Sie, welche Zeichen zulässig sind. Das erledigt die meisten Fälle sofort, weil die Ursache meist ein kopierter Bindestrich ist.
- Kein passender Bereich. Formulieren Sie, dass die Nummer nicht erkannt wurde, und lassen Sie offen, ob der Nutzer sich vertippt hat oder ob das Netzwerk nicht unterstützt wird.
- Prüfsumme fehlgeschlagen. Sagen Sie, dass die Nummer falsch aussieht, und bitten Sie um Kontrolle der Ziffern.
Was in keiner Meldung stehen darf, ist ein Urteil über die Karte. Eine Aussage, die Karte sei ungültig oder nicht vorhanden, ist für die Anwendung nicht überprüfbar und für den Nutzer beunruhigend. Sie ist außerdem häufig falsch, weil die Prüfung nur die Zeichenfolge kennt.
Eine bestandene Prüfung ist keine genehmigte Zahlung
Dieser Satz hat eine präzise technische Bedeutung. Eine Nummer, die alle fünf Stufen besteht, ist strukturell gültig und wurde niemals ausgegeben. Sie sieht wie eine Karte aus, gehört zu keinem Konto und wird von jedem echten Gateway abgelehnt.
Daraus folgt für Testumgebungen eine angenehme Eigenschaft: Es lassen sich beliebig viele vollständig plausible Testwerte herstellen. Der Kartennummern-Generator liefert genau solche Werte je Netzwerk, und die Formatregeln erklären, welche Teile einer Nummer dabei frei gewählt werden dürfen.
Daraus folgt aber auch eine Verwechslungsgefahr. Wer in der Staging-Umgebung nur gegen erzeugte Nummern testet, hat den Pfad der genehmigten Zahlung nie gesehen. Die Sandbox eines Dienstleisters gehört daher ergänzend dazu, wie im Beitrag zu den Testkarten des Anbieters beschrieben.
Für Entwickler: Reihenfolge, Normalisierung und die Tests, auf die es ankommt
Zwei Eigenschaften sollten ausdrücklich testgetrieben sein: die Normalisierung und die Reihenfolge.
Für die Normalisierung gehört je ein Testfall auf die führende Null, auf ein Leerzeichen mitten in der Zeichenfolge, auf einen Bindestrich an beliebiger Stelle und auf einen Buchstaben, der nicht stillschweigend verschwinden darf. Der Fall mit dem Buchstaben ist der wichtigste, weil eine zu großzügige Bereinigung aus einem Tippfehler einen scheinbar gültigen Wert macht.
Für die Reihenfolge gehört je ein Testfall darauf, dass eine zu kurze Zeichenfolge mit korrekter Prüfsumme dennoch abgelehnt wird und dass eine Zeichenfolge mit unbekanntem Präfix die Längenprüfung nicht fälschlich besteht. Beide Fälle lassen sich mit erzeugten Werten leicht konstruieren.
Schließlich gehört ein Testfall darauf, dass die Fehlermeldungen sich unterscheiden. Wer drei verschiedene Ursachen auf dieselbe Meldung abbildet, hat diese Funktion nicht wirklich implementiert und wird es erst merken, wenn Supportfälle eintreffen.
An erzeugten Nummern üben
Der praktische Einstieg ist, ein Paket mit verschiedenen Netzwerken zu erzeugen und die Prüfung daran zu beobachten. Der Kartennummern-Generator gibt das Netzwerk zu jeder Nummer an, sodass sich die erwartete Länge direkt danebenstellen lässt. Ändern Sie anschließend eine Ziffer und sehen Sie zu, wie die Prüfsumme scheitert; entfernen Sie eine Ziffer, und beobachten Sie, wie die Längenprüfung vor der Prüfsumme greift. Damit haben Sie alle fünf Stufen einmal von Hand durchlaufen und kennen das Verhalten, das Ihre Tests festschreiben sollen.
Wie die Prüfung sich in den gesamten Abnahmeprozess einfügt, beschreibt die Checkliste für Zahlungsformulare.
Nächste Schritte
Schreiben Sie die fünf Stufen in Ihrer gewünschten Reihenfolge auf, bevor Sie Code schreiben, und legen Sie zu jeder Stufe einen Testfall an, der genau an dieser Stufe scheitert. Damit ist die Prüfung abgeschlossen und jede spätere Änderung wird sichtbar, sobald sie das Verhalten verschiebt.