Test Kreditkartennummern: Was sie sind und wo sie gelten

Test Kreditkartennummern sind Ziffernfolgen, die jede strukturelle Regel einer echten Karte erfüllen – ein plausibles Netzwerkpräfix, eine zulässige Länge und eine abschließende Prüfziffer, die rechnerisch aufgeht – und die dennoch zu keinem Konto irgendwo auf der Welt gehören. Sie existieren, damit Checkout-Formulare, Staging-Systeme und automatisierte Testläufe geübt werden können, ohne echtes Geld zu bewegen und ohne eine echte Zahlungsreferenz an eine Stelle zu kopieren, an die sie nicht gehört. Dieser Beitrag erklärt, woher solche Nummern kommen, in welchen Umgebungen sie sicher sind und welche Fehler aus einem harmlosen Test still und leise einen Abbuchungsversuch machen.

Was eine Test-Kreditkartennummer tatsächlich ist

Eine Kartennummer ist keine zufällige Zeichenkette. Von links nach rechts gelesen besteht sie aus drei Teilen: einem Herausgeberpräfix, das dem Routingsystem sagt, zu welchem Netzwerk und welchem Kartenherausgeber die Karte gehört; den Kontoziffern, die der Herausgeber vergibt; und einer abschließenden Prüfziffer, die aus allem davor berechnet wird.

Eine Testnummer behält den ersten und den letzten dieser drei Teile und erfindet den mittleren. Das Präfix stammt aus einem veröffentlichten Bereich des jeweiligen Netzwerks, damit sich die Markenerkennung genauso verhält wie im Produktivbetrieb. Der Kontoteil wird mit beliebigen Ziffern gefüllt, und die Prüfziffer wird passend dazu berechnet. In der fertigen Zeichenfolge verweist nichts auf eine Person, ein Guthaben oder die Buchhaltung eines Herausgebers.

Die praktische Folge: Gültig bedeutet in diesem Zusammenhang wohlgeformt. Es ist eine Aussage über Arithmetik und Länge, nicht über Eigentum oder Status.

Warum gibt es Testkartennummern überhaupt?

Jede Zahlungsschnittstelle hat zwei Pflichten, die einander entgegenwirken. Sie muss Tippfehler, abgeschnittene Eingaben und erfundene Ziffern zurückweisen, und sie muss jede Karte akzeptieren, die ein echter Kunde besitzen könnte. Um die erste Pflicht zu belegen, braucht man absichtlich kaputte Eingaben; um die zweite zu belegen, braucht man Eingaben, die völlig gewöhnlich aussehen.

Echte Karten taugen für die zweite Rolle nicht. Wer eine lebende Nummer in ein Staging-Formular tippt, kopiert eine funktionierende Zahlungsreferenz in eine Umgebung, die selten so streng geprüft wird wie die Produktion, und ein einziger versehentlicher Absendeversuch wird zu einer echten Abbuchung. Deshalb reservieren die Netzwerke eigene Bereiche für Dokumentation und Sandbox-Nutzung, Zahlungsdienstleister veröffentlichen eine kurze Liste von Nummern, die ihre eigenen Sandboxes kennen, und alles Übrige ist synthetisch.

In diese letzte Kategorie gehört erzeugter Datenbestand. Ein Erzeuger produziert Nummern bei Bedarf nach denselben öffentlichen Nummerierungsregeln, sodass sich für jedes Netzwerk und jede Menge ein Paket bilden lässt, ohne jemanden nach einem Konto zu fragen.

Lässt sich mit einer Testnummer jemals Geld abbuchen?

Nein – und zu verstehen, warum, hält Teams aus Schwierigkeiten heraus. Eine erzeugte Nummer besteht eine Formatprüfung und eine Prüfsumme. An beidem ist keine Bank beteiligt. Sobald ein Zahlungsformular mit einem echten Gateway verbunden ist, schickt das Gateway eine Autorisierungsanfrage an den Herausgeber des Präfixes in der Nummer, die Anfrage findet kein passendes Konto, und der Versuch scheitert.

Dieses Scheitern ist trotzdem ein Ereignis. Es erscheint im Gateway-Dashboard, es kann gegen Betrugsschwellen zählen, und in manchen Konfigurationen hinterlässt es eine Prüfspur, in der Ihr Team namentlich auftaucht. Die ehrliche Regel lautet deshalb nicht, dass erzeugte Nummern überall harmlos sind, sondern dass sie in Umgebungen harmlos sind, die nichts autorisieren sollen.

Jede Nummer, die der Erzeuger auf dieser Seite ausgibt, ist eine Zeichenkette, die eine Prüfroutine akzeptiert und die kein Herausgeber jemals ausgegeben hat. Sie ist strukturell korrekt, sie wurde nie einem echten Konto zugeordnet, und sie darf niemals auf einen Live-Endpunkt gerichtet werden.

Wo Testnummern sicher eingesetzt werden

Entscheidend ist, ob ein System die Nummer lediglich parst oder tatsächlich versucht, sie zu belasten. Ungefähr in der Reihenfolge abnehmender Sicherheit:

• Unit-Tests, die eine Längenregel, eine Prüfsumme oder einen Zweig der Netzwerkerkennung prüfen.
• Frontend-Demos, in denen ein Formular lokal validiert und danach verworfen wird.
• Staging-Umgebungen, die an den Sandbox-Modus eines Dienstleisters angebunden sind.
• Das Befüllen von Datenbanken für eine Bestellhistorie oder ein Administrationspanel.
• Lasttests gegen eigene Endpunkte, sofern der Zahlungsschritt gestubbt ist.
• Manuelle Qualitätssicherung des Checkouts, mit nachgebildetem oder in der Sandbox ausgeführtem Zahlungsschritt.

Die Liste ist in dem Moment nicht mehr sicher, in dem ein echter Gateway-Schlüssel in der Konfiguration steht. Wenn Ihre Staging-Umgebung Produktivschlüssel teilt – und das tun viele –, dann ist eine erzeugte Nummer keine Testdatei mehr, sondern ein Abbuchungsversuch.

Nummern auswählen, die reproduzierbar sind

Zufällige Pakete sind für eine Demo bequem und für eine Regressionstest-Suite schmerzhaft. Wenn ein Test, der gestern fehlschlug, gegen eine frisch erzeugte Nummer lief, beweist ein erneuter Lauf heute sehr wenig, weil die Eingabe nicht mehr dieselbe ist.

Behandeln Sie ein erzeugtes Paket wie eine Referenzdatei: Wählen Sie Netzwerk und Menge, die Sie brauchen, erzeugen Sie einmal, und bewahren Sie genau diese Menge neben dem Test auf, der sie verbraucht. Ändert sich eine Regel – sagen wir, eine Längenbeschränkung wird verschärft –, zeigt Ihnen der gespeicherte Satz genau, welche Ihrer Vorlagen nicht mehr bestehen.

Zwei Gewohnheiten machen das Leben damit deutlich leichter. Geben Sie jedem Vorlagensatz einen kurzen beschreibenden Namen statt eines Datums, und halten Sie fest, welches Netzwerk jede Nummer beansprucht, damit ein Fehlerbericht Ihnen sagt, welchen Erkennungszweig Sie untersuchen müssen.

Für Entwickler: Fixture-Daten, die sich anständig verhalten

Ein paar Details entscheiden darüber, ob ein Satz Testnummern nützlich ist oder nur im Repository herumliegt.

Erstens: Machen Sie die Daten lesbar. Eine Nummer, die ein Mensch prüfen soll, gehört so gruppiert, wie sie auf der Karte steht, auch wenn der Code die Trennzeichen vor dem Prüfen entfernt; die Gruppierung ist Dokumentation. Bauformen und Prüflogik behandelt der Leitfaden zum Kartenformat sowie die Ausführung zum Luhn Algorithmus, also die Prüfung, die die letzte Ziffer erfüllen muss.

Zweitens: Decken Sie die Grenzen bewusst ab. Ein Vorlagensatz, der nur sechzehnstellige Visa-Nummern enthält, übt den Zweig für fünfzehnstellige American-Express-Nummern nicht aus und erreicht nie den Code, der eine siebzehnstellige Eingabe zurückweist. Nehmen Sie eine Nummer pro Längenregel auf, die Sie zu unterstützen glauben.

Drittens: Halten Sie sichtbar, dass die Daten nie ausgegeben wurden. Ein Kommentar neben der Vorlage oder eine Namenskonvention mit dem Wort synthetisch verhindert, dass ein künftiger Betreuer einen der Werte für einen Handtest gegen ein echtes Konto ausleiht.

Schließlich: Entscheiden Sie, was Ihre Suite tut, wenn die Daten falsch sind. Ein Prüfsummenfehler gehört als fehlerhafte Eingabe gemeldet und nicht als abgelehnte Zahlung; wer beides vermischt, versteckt echte Defekte hinter Umgebungsfehlern.

Ein Paket im Kartenwerkzeug erzeugen

Der Kartennummern-Generator auf dieser Seite erzeugt genau diese Art von Daten. Sie wählen ein Netzwerk oder lassen die Wahl zufällig, Sie wählen, wie viele Karten Sie brauchen, und das Werkzeug liefert Nummern mit passenden Ablaufdaten und Platzhalter-Sicherheitscodes, die Sie einzeln oder alle auf einmal kopieren können. Wenn Sie bereits einen Teil einer Nummer besitzen, füllt der Vervollständigungsmodus die unbekannten Ziffern, statt von vorn zu erzeugen. Das ist nützlich, wenn ein Fehlerbericht einen Teilwert enthält.

Weil die Ausgabe durchgängig synthetisch ist, lässt sich das Paket gefahrlos in eine Vorlagendatei einfügen, und genau darum geht es beim Gedanken der Reproduzierbarkeit. Die Hinweise zur Konformität erklären, warum ein synthetischer Wert einem maskierten echten Wert vorzuziehen ist, selbst in einer Staging-Datenbank, zu der niemand außerhalb des Teams Zugang hat.

Nächste Schritte

Erzeugen Sie ein kleines Paket, legen Sie es neben den Test, der es verwendet, und fügen Sie eine absichtlich kaputte Nummer hinzu, damit auch der Fehlerpfad abgedeckt ist. Wenn Sie verstehen müssen, warum eine bestimmte Zeichenfolge akzeptiert oder abgelehnt wird, beginnen Sie mit den Formatregeln für Kartennummern, und greifen Sie zum Netzwerkvergleich, wenn Sie eine Nummer pro Marke brauchen.