Test-Kartennummern 2026 — Braintree, Stripe, PayPal, Square

Aktuelle Test- und Dummy-Kreditkartennummern für Braintree, Stripe, PayPal und Square. Nach Marke und Erfolg-/Fehlermuster sortiert, mit Ein-Klick-Kopieren für schnelle Zahlungstests.

Zuletzt aktualisiert: 2026-09-03

[[ labels.stripe_hint ]]

Service	[[ labels.col_number ]]	[[ labels.col_brand ]]	[[ labels.col_behavior ]]
[[ card.service ]]	[[ formatNumber(card.number) ]]	[[ card.brand ]] [[ labels['subtype_' + card.subtype] ]]	[[ behaviorLabel(card.behavior) ]]

Was sind Test-Kreditkartennummern?

Wenn Sie eine Zahlungsfunktion entwickeln, müssen Sie Ergebnisse wie „erfolgreich", „unzureichendes Guthaben" oder „gestohlene Karte" nachbilden können, ohne eine echte Karte zu verwenden. Dafür stellt jeder große Zahlungsdienstleister feste Kartennummern bereit, die serverseitig fest mit bestimmten Ergebnissen verknüpft sind. Diese Seite sammelt die aktuellen Testnummern von Stripe, PayPal, Square und Braintree, sortiert nach Marke und Ergebnis, sodass Sie genau das finden, was Sie brauchen, und es mit einem Klick kopieren können.

Diese Nummern haben ausschließlich in einer Sandbox-Umgebung Bedeutung. Solange Sie sie mit einem Test-API-Schlüssel kombinieren, entsteht keine echte Belastung — kombinieren Sie sie hingegen mit einem Live-Schlüssel, wird die Transaktion schlicht abgelehnt, da Produktionssysteme diese Nummern nicht als echte Karten erkennen. Wechseln Sie Schlüssel und Nummern deshalb immer gemeinsam, und beachten Sie, dass Anbieter ihre Testnummern gelegentlich aktualisieren — prüfen Sie im Zweifelsfall die aktuelle Dokumentation des jeweiligen Anbieters.

So verwenden Sie diese Liste

Registerkarte des Zahlungsdienstes wählen Wählen Sie den Anbieter, den Sie integrieren (Stripe, PayPal, Square oder Braintree), um die Tabelle auf dessen Nummern einzugrenzen.
Nach dem gewünschten Ergebnis filtern Mit den Filtern Erfolg, Fehler oder 3D Secure grenzen Sie das Szenario ein, das Sie gerade testen, etwa einen Fehlerbehandlungspfad.
Kartennummer kopieren Klicken Sie neben einer Zeile auf Kopieren, um die Nummer in die Zwischenablage zu legen und direkt in Ihr Zahlungsformular einzufügen.
CVC und Ablaufdatum ausfüllen Für den CVC funktioniert jede Ziffernfolge (4 Stellen bei Amex), für das Ablaufdatum jedes zukünftige Datum — exakte Werte sind nicht nötig.

Tipps für die Nutzung

Im Testmodus von Stripe werden jede 3-stellige CVC (4 Stellen bei Amex), jedes zukünftige Ablaufdatum und jede 5-stellige Postleitzahl akzeptiert. Es fallen keine echten Gebühren an, solange du Testschlüssel verwendest.
Alle Testkartennummern sind so konzipiert, dass sie die Luhn-Prüfung (Kartennummer-Validierungsalgorithmus) bestehen und daher nicht von der Frontend-Validierung abgewiesen werden.
Für 3D Secure (3DS)-Tests sind dedizierte Karten erforderlich. 4000002500003155 löst den Authentifizierungsdialog aus, 4000000000003220 wird für den 3DS-2-Ablauf verwendet.
Die Verwendung von Testkartennummern in der Produktion führt zu abgelehnten Transaktionen. Verwende Testschlüssel immer zusammen mit Testkartennummern. Bei Stripe beginnen Testschlüssel mit sk_test_.

Typische Anwendungsfälle

Neue Checkout-Integration überprüfen

Direkt nach dem Einbinden eines Zahlungsformulars bestätigt eine erfolgreiche Testnummer, dass Schlüssel und Anfragestruktur korrekt sind, bevor Sie weiter forschen.

Fehlerbehandlung aufbauen

Mit Nummern für unzureichendes Guthaben, abgelaufene Karten oder CVC-Fehler prüfen Sie, ob jede Fehlermeldung dem Kunden verständlich angezeigt wird.

3D-Secure-Abläufe testen

Die eigens dafür vorgesehenen Nummern führen Sie durch den Authentifizierungsdialog bis zur Rückleitung in Ihre Anwendung — ein Schritt, der bei der Umsetzung leicht übersehen wird.

QA-Testpläne dokumentieren

Wenn Sie die Zuordnung von Nummer zu Ergebnis direkt in ein Testskript übernehmen, müssen Tester nicht bei jedem Durchlauf erneut danach suchen.

Fixtures für automatisierte Testsuiten erzeugen

Dieselben festen Nummern lassen sich als Fixtures in die CI übernehmen, damit Zahlungsabläufe bei jedem Build konsistent geprüft werden.

Glossar zum Testen von Zahlungen

Testschlüssel: Ein API-Schlüssel, der nur in der Sandbox gilt. Stripe-Testschlüssel beginnen mit sk_test_; damit ist garantiert, dass kein echtes Geld bewegt wird.
Sandbox: Eine vollständig von der Produktion getrennte Umgebung, in der Sie Erfolg und Misserfolg frei nachbilden können, ohne echte Beträge zu berühren.
Luhn-Prüfung: Eine Prüfsummenformel, die feststellt, ob die Ziffernfolge einer Kartennummer gültig ist. Sie erkennt Tippfehler, kann aber nicht bestätigen, dass die Karte tatsächlich existiert.
BIN / IIN: Die ersten sechs bis acht Ziffern einer Kartennummer, die die ausstellende Bank und das Kartennetzwerk identifizieren, noch bevor der Rest der Nummer geprüft wird.
CVC / CVV: Der dreistellige (bei Amex vierstellige) Sicherheitscode auf der Karte. In der Sandbox wird an dieser Stelle jede Ziffernfolge akzeptiert.
3D Secure: Ein zusätzlicher Identitätsnachweis während des Bezahlvorgangs. Eigens dafür vorgesehene Testnummern lösen diesen Dialog aus, damit Sie den gesamten Ablauf testen können.
Autorisierung: Eine vorläufige Reservierung auf einer Karte, mit der geprüft wird, ob genügend Guthaben vorhanden ist. Die eigentliche Abbuchung erfolgt erst in einem späteren Schritt, dem Einzug.

Häufige Fragen

Solange du sie mit Testschlüsseln (wie sk_test_) verwendest, entstehen keine echten Abbuchungen. Wenn du versehentlich einen Live-Schlüssel verwendest, wird die Transaktion auch mit Testnummern versucht — achte daher darauf, sie nicht zu verwechseln.

Bei Stripe funktionieren für den CVC beliebige Ziffern (3 für Visa/Mastercard, 4 für Amex), als Ablaufdatum jedes zukünftige Datum (z. B. 12/34) und als Postleitzahl jede 5-stellige Zahl. Die Sandbox-Umgebungen von PayPal, Square und Braintree prüfen diese Werte ebenfalls nicht streng.

Es handelt sich um eine Formel, die überprüft, ob die Ziffern und die Struktur einer Kartennummer gültig sind. Jede zweite Ziffer von rechts wird verdoppelt und alle Ziffern werden addiert; ist das Ergebnis ein Vielfaches von 10, gilt die Nummer als gültig. Sie erkennt die meisten Tippfehler, kann aber nicht prüfen, ob die Karte tatsächlich existiert.

"4242..." ist durch die Wiederholung leicht zu merken und wurde so konzipiert, dass es die Luhn-Prüfung besteht. Da Stripe diese Nummer jahrelang in der offiziellen Dokumentation verwendete, wurde sie zum De-facto-Standard unter Zahlungsentwicklern.

Übrigens – Der Luhn-Algorithmus – Der Hüter der Kartennummern seit 1954

Die „Prüfziffer" am Ende einer Kreditkartennummer wird durch einen Algorithmus validiert, den IBM-Ingenieur Hans Peter Luhn 1954 entwickelt hat. Jede zweite Ziffer von rechts wird verdoppelt, alle Ziffern werden summiert, und das Ergebnis muss durch 10 teilbar sein. Dieser einfache Algorithmus wird heute noch von Visa, Mastercard, Amex und anderen großen Marken verwendet und erkennt die meisten Tippfehler zuverlässig.

Die Luhn-Prüfung dient jedoch ausschließlich der Erkennung von Ziffernfehlern — sie prüft nicht, ob die Karte tatsächlich existiert. Die Verwendung im clientseitigen Formular-Validierung ist lediglich eine UX-Verbesserung (sofortige Fehlerrückmeldung) und verhindert keinen Betrug. Die eigentliche Autorisierung muss immer serverseitig über ein Zahlungs-Gateway erfolgen.

Testkartennummern sind feste Nummern, die jeder Zahlungsdienst absichtlich so gestaltet hat, dass sie die Luhn-Prüfung bestehen. Stripes 4242424242424242 zum Beispiel ist leicht zu merken und besteht die Luhn-Validierung. Die Nummer selbst hat keine inhärente Bedeutung — sie ist lediglich einem Verhalten (z. B. „Erfolg" oder „Fehler") im Stripe-System zugeordnet.

Alle Wissenstexte ansehen