Ein Werkzeug zum Erzeugen von Kreditkartennummern liefert Nummern, die die strukturellen Regeln erfüllen, die ein Zahlungsformular prüft, sodass ein Kassenablauf ausgeübt werden kann, ohne dass je eine echte Karte im Spiel ist. Die Nummer ist kein Berechtigungsnachweis, sie hängt an keinem Konto, und sie autorisiert nichts – aber sie besteht die Formatprüfungen, die Präfixregeln des Herausgebers und die Prüfziffer, die ein Formular anwendet, bevor es etwas weiterleitet.
Dieser Leitfaden erklärt, was die Teile einer Kartennummer bedeuten, warum die Prüfziffer existiert und was sie nicht leistet, warum Sicherheitscode und Ablaufdatum im Testdatensatz mit der Nummer übereinstimmen müssen und wo die Grenze zwischen einer Testumgebung und einer Umgebung mit Karteninhaberdaten verläuft. Am Ende wissen Sie, was Sie in einem Test für Zahlungsformulare zusichern sollten und was aus Ihrem Repository vollständig herauszuhalten ist.
Was bedeuten die Teile einer Kartennummer?
Eine Kartennummer ist eine Ziffernfolge fester Länge mit drei Teilen. Die führenden Ziffern benennen Herausgeber und Netzwerk, die mittleren Ziffern benennen das einzelne Konto innerhalb dieses Herausgebers, und die letzte Ziffer ist ein Prüfwert, der aus allen anderen berechnet wird. Die Gesamtlänge unterscheidet sich nach Netzwerk und Kartenprodukt; ein Formular, das eine einzige Länge annimmt, weist gültige Eingaben zurück.
Die Herausgeberkennung ist das Präfix, und sie ist es, die ein Formular das richtige Logo anzeigen und die richtigen Regeln anwenden lässt, bevor eine Anfrage gesendet wird. Die Präfixe der großen Netzwerke belegen unterschiedliche Zahlenbereiche, und diese Bereiche sind veröffentlicht, damit ein System eine Nummer weiterleiten kann, ohne jemanden zu kontaktieren. Trägt eine erzeugte Nummer ein Präfix aus dem falschen Bereich, weist das Formular sie entweder rundheraus zurück oder beschriftet das Netzwerk in der Oberfläche falsch.
Der mittlere Abschnitt ist der Teil, den ein Generator erfindet. In einem synthetischen Datensatz steht kein Konto dahinter, und das ist der Punkt. In einer echten Karte verweist er auf ein bestimmtes Konto bei einem bestimmten Herausgeber – genau deshalb darf er niemals in einer Test-Fixture erscheinen.
Für jeden, der ein Werkzeug baut, hat das eine praktische Folge. Die sichersten synthetischen Nummern bleiben innerhalb der Zahlenbereiche, die die Netzwerke für Tests reservieren, weil diese Bereiche so festgelegt sind, dass dort kein echtes Konto existieren kann. Ein Werkzeug, das den gesamten Präfixraum durchstreift, kann irgendwann eine Kombination erzeugen, die jemandem gehört; eine Nummer, die jemandem gehört, ist keine Testdatei mehr, so harmlos sie auch entstanden sein mag.
Ein Hinweis zur Länge gehört noch dazu. Manche Netzwerke vergeben Nummern in zwei Längen, und eine Formularprüfung, die nur die häufigere kennt, lehnt die zweite Länge ab. Nehmen Sie beide in die Testmatrix auf, sobald das Netzwerk sie führt.
Warum gibt es die Prüfziffer und was beweist sie?
Die letzte Ziffer wird durch eine gewichtete Quersumme über die vorangehenden Ziffern berechnet, eine Regel, die üblicherweise als Luhn-Algorithmus bezeichnet wird. Ihr Zweck ist es, Übertragungsfehler zu fangen: eine einzelne falsch getippte Ziffer oder zwei vertauschte benachbarte Ziffern erzeugen fast immer eine Nummer, die die Prüfung nicht besteht. Der Beitrag zum Luhn-Algorithmus arbeitet die Rechnung Schritt für Schritt durch.
Was die Prüfziffer beweist, ist eng umrissen, und ein Missverständnis an dieser Stelle erzeugt echte Fehler. Sie beweist, dass die Ziffern in sich stimmig sind. Sie beweist nichts darüber, ob das Konto existiert, ob die Karte aktiv ist, ob Guthaben vorhanden ist oder ob die Nummer irgendjemandem gehört. Ein Formular, das eine bestandene Prüfziffer als Nachweis für irgendetwas jenseits der Arithmetik behandelt, nimmt jede wohlgeformte falsch getippte Nummer an, die ein Nutzer produzieren kann.
Genau darin liegt der Nutzen einer erzeugten Nummer im Test. Sie trägt exakt die Eigenschaft, die ein Formular prüft – die innere Stimmigkeit – und keine der Eigenschaften, die ein Formular nicht prüfen kann. In der Lücke zwischen diesen beiden Mengen wohnen die meisten Fehler in Zahlungsformularen.
Ebenso erklärt das, warum Platzhalterwerte scheitern. Ein Feld, das mit einer wiederholten Ziffer oder einer kurzen aufsteigenden Folge gefüllt ist, besteht die Prüfziffer nicht und erreicht deshalb nie die Codepfade, die Sie tatsächlich testen wollen. Eine brauchbare Testnummer ist eine gültige Nummer.
Ein zweiter Irrtum betrifft die Richtung. Die Prüfziffer erkennt zufällige Tippfehler, aber sie erkennt keine Vertauschung, die die Summe unverändert lässt, und erst recht keine absichtlich konstruierte Nummer. Sie ist eine Schicht zur Fehlererkennung und keine Integritätsgarantie.
Warum müssen Sicherheitscode und Ablaufdatum zur Nummer passen?
Ein Kartendatensatz ist ein kleiner Satz von Feldern, die einander einschränken, und ein Zahlungsformular nimmt Kombinationen an, die kein Herausgeber je ausgeben würde. Die Länge des Sicherheitscodes hängt vom Netzwerk ab; ein dreistelliger Code an einem Netzwerk, das vier verwendet, ist eine Unstimmigkeit. Das Ablaufdatum muss für die meisten Abläufe in der Zukunft liegen, und der Monat muss innerhalb der zwölf Kalendermonate liegen.
Ob die Karte ein Debit- oder ein Kreditprodukt ist, beeinflusst in manchen Abläufen zusätzlich das Verhalten. Einige Kassen behandeln beide gleich, andere wenden unterschiedliche Regeln an; eine Testsuite, die nur einen Produkttyp ausübt, entdeckt den Unterschied nicht. Ein Werkzeug, das beide erzeugen kann und dabei Netzwerke passend zu den Präfixen wählt, liefert Ihnen die Vielfalt, um diese Pfade zu finden.
Die Herausgeberkennung und die Netzwerkmarke in der Oberfläche stehen in derselben Beziehung. Zeigt das Formular den Namen des einen Netzwerks, während das Präfix zu einem anderen gehört, ist diese Unstimmigkeit ein Testfall für sich – und ein Fehler, über den ein manueller Tester selten stolpert, weil er die Nummern tippt, die er kennt.
Ein weiteres Feld verdient Aufmerksamkeit: der Name auf der Karte. Er wird selten geprüft, aber er wird angezeigt, gespeichert und weitergegeben. Legen Sie für Tests synthetische Namen fest und halten Sie sie von den Namen echter Personen getrennt, damit ein späterer Export nicht versehentlich einen Personenbezug herstellt.
Sind offizielle Testkarten besser als erzeugte?
Zahlungsanbieter veröffentlichen Testkartennummern für ihre Sandbox-Umgebungen, und diese Nummern sind für einen bestimmten Zweck die richtige Wahl: das Verhalten des Anbieters selbst auszuüben. Eine veröffentlichte Testnummer ist an dokumentierte Ergebnisse gebunden – eine erfolgreiche Belastung, eine abgelehnte Belastung, ein bestimmter Fehlercode – und das Nachstellen dieser Ergebnisse hängt daran, genau diese Nummer zu verwenden.
Erzeugte Nummern dienen einem anderen Zweck. Sie sind für die Teile des Stapels gedacht, die Ihnen gehören: Ihre clientseitige Prüfung, Ihre Präfixerkennung, Ihre Formatierung, Ihre Fehlermeldungen, Ihre Speicherung und Ihr Umgang mit ungewöhnlichen Längen. Eine Sandbox hat kein dokumentiertes Ergebnis für eine Nummer, die sie nie gesehen hat; erzeugte Nummern sind deshalb für alles gedacht, was geschieht, bevor die Anfrage Ihre Anwendung verlässt.
Beide Ansätze ergänzen sich gut. Verwenden Sie erzeugte Nummern für die breite Matrix der Prüffälle und einen kleinen Satz veröffentlichter Anbieternummern für die wenigen Integrationstests, die auf Anbieterantworten prüfen. Der Beitrag zu den Stripe-Testkarten behandelt die zweite Gruppe, und die Checkliste für Zahlungsformulare behandelt die erste.
Unabhängig davon, was Sie verwenden, halten Sie die Nummern im Testcode und aus den Fixtures heraus, die einen echten Endpunkt erreichen. Eine Sandbox-Nummer, die versehentlich an ein Produktionsgateway gesendet wird, wird zurückgewiesen, aber sich auf die Zurückweisung als Sicherheitsnetz zu verlassen, ist keine Kontrolle.
Eine weitere Eigenschaft lohnt sich einzuplanen: ein Ablaufdatum, das nie veraltet. Eine Fixture mit fest eingetragenem Ablaufdatum beschreibt eines Tages eine Karte, die im Vormonat abgelaufen ist, und der Test beginnt aus einem Grund zu scheitern, der nichts mit der geprüften Änderung zu tun hat. Ein Werkzeug, das den Ablauf relativ zum aktuellen Datum berechnet, hält die Fixture unbegrenzt gültig und entfernt eine ganze Klasse verwirrender Fehlschläge aus der Suite.
Was bedeutet PCI DSS für ein Unternehmen ohne echte Karten?
Der Payment Card Industry Data Security Standard regelt, wie Karteninhaberdaten gespeichert, verarbeitet und übertragen werden. Seine zentrale Regel ist einfach zu formulieren und leicht zu unterschätzen: Eine Testumgebung darf keine echten Kartennummern enthalten. Nicht in einer Fixture, nicht in einem Startwertskript, nicht in einem Kommentar und nicht in einem Protokoll.
Der Grund ist, dass eine Kartennummer zusammen mit einem Namen und einem Ablaufdatum geschützte Daten ist, unabhängig von der Umgebung, in der sie liegt. Eine Produktionszeile nach Staging zu kopieren, schafft einen neuen Ort mit Karteninhaberdaten – meist mit schwächeren Zugriffskontrollen und einer längeren Sicherungshistorie. Der Beitrag zu PCI DSS und Testdaten untersucht die Folgen genauer.
Für ein Team, das keine echten Karten besitzt, ist die Einhaltung vergleichsweise einfach. Wenn jede Nummer in der Umgebung synthetisch ist und keine echte Karte ankommen kann, beantwortet sich die Frage nach der Reichweite weitgehend von selbst. Die Disziplin, die verlangt wird, besteht darin, es dabei zu belassen: niemals eine echte Nummer in einen Fehlerbericht einfügen, niemals eine laufende Kasse abfotografieren und niemals einen Produktionsauszug importieren, damit Testdaten realistischer aussehen.
Das organisatorische Versagensmuster ist meist Absicht und nicht Nachlässigkeit. Jemand muss einen Produktionsfehler nachstellen, importiert dafür einen Ausschnitt der Produktion und lässt den Ausschnitt liegen. Eine Regel, wonach Testdaten erzeugt und nicht kopiert werden, ist leicht einzuhalten, solange sie nie gelockert wurde.
Praktisch hilft eine einfache Kontrolle. Suchen Sie in der Testdatenablage nach Ziffernfolgen der geschützten Länge, und lassen Sie diese Suche in der Pipeline laufen. Sie findet kopierte Zeilen schneller, als es jede Vereinbarung tut.
Welche Fälle für Zahlungsformulare lohnen sich?
Die Fälle, die echte Fehler fangen, sind die an den Grenzen. Testen Sie eine Nummer mit einer Ziffer weniger und einer Ziffer mehr als die erwartete Länge je unterstütztem Netzwerk und prüfen Sie, dass das Formular beide mit einer handlungsfähigen Meldung zurückweist. Testen Sie ein Präfix, das zu einem Netzwerk gehört, das Ihre Kasse nicht annimmt, und stellen Sie fest, dass die Zurückweisung klar und nicht allgemein ausfällt.
Testen Sie die Prüfziffer ausdrücklich, indem Sie eine gültige Nummer nehmen, eine Ziffer in der Mitte verändern und prüfen, dass das Formular sie zurückweist. Dieser Fall ist wertvoll, weil er Formulare unterscheidet, die die Quersumme tatsächlich berechnen, von solchen, die nur Ziffern zählen – und die zweite Art ist häufiger, als sie sein sollte.
Testen Sie Formatierung und Einfügen. Nutzer fügen Nummern mit Leerzeichen, mit Bindestrichen und mit einem führenden oder abschließenden Leerzeichen ein, und ein Feld, das diese Zeichen unverändert speichert, scheitert weiter unten im Stapel. Testen Sie das Feld für den Sicherheitscode gegen die erwartete Länge des Netzwerks und testen Sie ein Ablaufdatum für den Vormonat und für den laufenden Monat, weil in der Grenze zwischen beiden die Zählfehler um eins wohnen. Der Beitrag zum Format der Kartennummer listet die strukturellen Regeln, auf denen all das aufbaut.
Testen Sie anschließend, was nach einem Fehlschlag geschieht. Ein Nutzer, der eine Ziffer falsch tippt, sollte sie berichtigen können, ohne das ganze Formular neu auszufüllen, und die Meldung sollte die übrigen Felder nicht leeren. Dieses Verhalten wird selten zugesichert und häufig gebrochen. Der Kreditkartenbereich dieser Site ist darauf ausgelegt, Nummern über die unterstützten Netzwerke mit der richtigen Länge und einer gültigen Prüfziffer zu erzeugen, sodass sich eine Matrix solcher Fälle zusammenstellen lässt, ohne für jeden eine Fixture von Hand zu schreiben.
Ergänzen Sie zwei Fälle, die oft fehlen: eine leer abgeschickte Nummer und eine Nummer, die nur aus Leerzeichen besteht. Beide erreichen in vielen Formularen einen anderen Codepfad als eine falsch formatierte Nummer.
Was eine erzeugte Kartennummer ist und was nicht
Eine erzeugte Kartennummer ist ein synthetischer Testdatensatz. Sie hat ein wohlgeformtes Präfix, eine korrekte Länge für ihr Netzwerk und eine gültige Prüfziffer, und sie ist darauf ausgelegt, Software auszuüben. Sie ist kein Zahlungsnachweis, sie wird von keiner Bank und keinem Netzwerk ausgegeben, sie hängt an keinem Konto, und sie kann nicht verwendet werden, um einen Kauf zu tätigen, eine Transaktion zu autorisieren oder eine echte Verifizierung zu bestehen.
Sie darf nicht verwendet werden, um Waren oder Leistungen zu erlangen, um ein laufendes Zahlungssystem mit Transaktionsabsicht zu prüfen, um sich als Karteninhaber auszugeben oder um eine Kontrolle zu umgehen, die dem Schutz echter Konten dient. Sie existiert, damit Ihre eigenen Formulare, Parser und Prüfregeln getestet werden können, und für nichts anderes.
Wird eine Kartennummer in einem Datensatz mit einem Namen, einer Adresse und einem Geburtsdatum verbunden, ist der gesamte Datensatz synthetisch. Korrekte Struktur und innere Stimmigkeit sind die Eigenschaften, die ihn brauchbar machen; sie sind keine Aussage über irgendetwas Echtes, und kein Teil eines solchen Datensatzes sollte je als Finanzangaben einer Person dargestellt werden.