Stripe Testkarten

So benutzt du eine Stripe-Testkarte

Drei Schritte. Testkarten gehören zu Test-API-Schlüsseln, deshalb kann hier nichts eine echte Karte oder einen echten Kunden berühren.

1. Auf Testschlüssel umstellen. Nimm deine veröffentlichbaren und geheimen Test-API-Schlüssel oder eine Sandbox. Echte Kartendaten haben dort nichts zu suchen: Stripes Rahmenvertrag verbietet es, im Live-Modus mit echten Zahlungsdaten zu testen. Umgekehrt lehnt der Live-Modus Testnummern ab — Stripe führt dafür einen eigenen Ablehnungscode, testmode_decline.
2. Die Karte für das gewünschte Ergebnis wählen. 4242 4242 4242 4242 für eine schlichte erfolgreiche Zahlung. Für deine Fehlerbehandlung nimmst du die Karte, deren Zeile den gewünschten Ablehnungscode nennt, dazu eine beliebige dreistellige CVC und ein Datum in der Zukunft wie 12/34.
3. Im Servercode die PaymentMethod verwenden. Stripe rät davon ab, Kartennummern direkt in API-Aufrufen oder serverseitigem Code zu verwenden, auch in Testumgebungen — sonst ist dein Code beim Livegang womöglich nicht PCI-konform. Nimm ein Token wie pm_card_visa; die Spalte PaymentMethod nennt es für jede Karte, die eines hat.

Zahlungen aus Deutschland testen: DE-Karte, SEPA-Lastschrift, girocard

Für einen Shop, der in Deutschland kassiert, zählen drei Stellen der Tabelle mehr als 4242 4242 4242 4242 — und Stripe dokumentiert sie an drei verschiedenen Orten.

• Die deutsche Karte, 4000 0027 6000 0016 (pm_card_de), steht auf dieser Seite am Anfang der Gruppe „nach Land“. Sie simuliert eine erfolgreiche Zahlung mit einer in Deutschland ausgestellten Karte. Was sich ändert, ist das Ausstellerland, und danach berechnet Stripe grenzüberschreitende Gebühren — für Karten, deren Ausstellerland nicht die USA ist, laut Stripe auch in Testumgebungen. Was die Karte nicht testet, ist die Authentifizierung: Die Vorschriften zur starken Kundenauthentifizierung verlangen für Online-Zahlungen im Europäischen Wirtschaftsraum 3D Secure, aber die Karten aus Stripes Abschnitt Europa und Naher Osten simulieren eine Zahlung, die ohne Authentifizierung erfolgreich ist. Für den Challenge-Ablauf ist die Gruppe 3D Secure zuständig.
• Die deutschen SEPA-Test-IBANs führen die Tabelle der lokalen Zahlungsmethoden an: DE89370400440532013000 für eine Lastschrift, die durchgeht, DE62370400440532013001 für eine, die fehlschlägt, DE35370400440532013002 für eine sofortige Zahlungsanfechtung, DE65370400440002222227 für unzureichende Deckung, dazu die Varianten DE08370400440532013003 und DE78370400440532013004, die erst nach mindestens drei Minuten entscheiden. Gibst du einen dieser Testwerte ein, validiert das Payment Element die IBAN und zeigt das Mandat an. Stripe veröffentlicht neun Szenarien pro Land; die Tabelle führt die sechs Kernszenarien, die beiden Limit-Fälle und bank_account_unusable stehen bei Stripe.
• girocard steht in Stripes Testkarten-Liste nicht. Die Pflicht zur Wahl der Kartenmarke aus der Verordnung (EU) 2015/751 betrifft Co-Badge-girocards laut Stripe nur bei Zahlungen vor Ort; online geht es um Karten mit Cartes-Bancaires-Co-Badge. Wundere dich trotzdem nicht über eine Netzwerkauswahl im Test-Checkout: In Sandboxes ist Cartes Bancaires für Online-Zahlungen immer aktiviert, deshalb kann der Selektor auf Stripes gehosteten Oberflächen auftauchen, auch wenn du Cartes Bancaires nie eingeschaltet hast. Die Co-Branding-Karte Cartes Bancaires/Visa steht in der Markengruppe.

Zwei Dinge, die diese Zeilen nicht zeigen und die du vor dem Livegang wissen solltest. Eine SEPA-Lastschrift entscheidet sich im Test nach Minuten; im Live-Modus rät Stripe, mindestens sechs Werktage zu warten, bevor du eine Zahlung als erfolgreich betrachtest. Und die Kundin kann eine Lastschrift bis zu acht Wochen danach ohne Angabe von Gründen über ihre Bank anfechten — solche Anfechtungen werden automatisch anerkannt; danach und bis zu 13 Monate nach dem Einzug nur noch, wenn die Lastschrift als nicht autorisiert gilt. Plane die Auslieferung entsprechend: Das Ereignis payment_intent.succeeded ist bei der Lastschrift nicht das letzte Wort.

Welche Karte welchen Fehler auslöst — und was dein Webhook sieht

Eine fehlgeschlagene Zahlung gut zu behandeln heißt, drei Dinge gleichzeitig im Kopf zu haben: den error.code, den dein API-Aufruf wirft, den decline_code, den der Aussteller mitschickt, und das Ereignis, das später an deinem Webhook-Endpunkt ankommt. Stripe dokumentiert die drei auf drei verschiedenen Seiten, deshalb ist die meiste Integration gegen eine davon geschrieben und von den anderen beiden überrascht. Hier steht dieselbe Information als eine Zeile pro Ergebnis.

Aus dem Lesen als eine Tabelle folgen zwei Gewohnheiten. Erstens: card_declined ist kein Grund, sondern eine Kategorie — der Grund steht im decline_code. Von den acht Ablehnungen oben in der Tabelle tragen fünf einen; die drei anderen liefern einen eigenen error.code. Eine Fehlerbehandlung, die nur auf error.code schaut, kann unzureichende Deckung und eine gestohlene Karte nicht auseinanderhalten. Dabei sollen verlorene und gestohlene Karten laut Stripe gegenüber dem Kunden gar nicht genannt, sondern als generic_decline gemeldet werden — während der Kunde, dessen Konto nur gerade leer ist, einen hilfreichen Hinweis verdient.

Zweitens tauchen manche Ergebnisse in der Antwort gar nicht auf. Eine zur Prüfung eingereihte Zahlung, eine Anfechtung drei Wochen später, eine asynchrone Rückerstattung, die von erfolgreich auf fehlgeschlagen springt — nichts davon ist im Moment des API-Aufrufs sichtbar. Es kommt als Ereignis, oder es kommt gar nicht, weil der Endpunkt nie gebaut wurde. Genau diesen Fehlerfall solltest du gezielt testen: Karte auslösen, dann nachsehen, was dein System mit dem Ereignis gemacht hat.

Zwei Fußnoten, die nicht in die Tabelle passen. Stripe überspringt die CVC- und die Postleitzahlprüfung, wenn du diese Felder nicht mitschickst — die Karten für eine fehlschlagende Prüfung gehen also still durch, solange dein Formular die Felder nicht erfasst. Und für von Radar blockierte Zahlungen nennt Stripe generic_decline, dessen Beschreibung ausdrücklich den Fall einschließt, dass Stripe-Radar bzw. Adaptive Acceptance die Zahlung blockiert haben: Der Kunde soll nicht erfahren, dass er als verdächtig eingestuft wurde. Und weil der Status auf Kartenebene aus einem Test laut Stripe spätere Tests mit derselben Karte beeinflussen kann, nimmst du für jedes unabhängige End-to-End-Szenario eine eigene Testkarte.

3D Secure testen

3D Secure ist der Authentifizierungsschritt, den die Regeln zur starken Kundenauthentifizierung für die meisten Online-Kartenzahlungen im EWR verlangen — und die Stelle, an der eine funktionierende Integration am häufigsten umfällt, weil der Normalfall sie nie sieht. Eine Zahlung, die eine Authentifizierung braucht, schlägt weder fehl noch gelingt sie: Der PaymentIntent kommt mit dem Status requires_action zurück, und dein Frontend muss an Stripe.js übergeben, damit der Kunde die Abfrage abschließen kann.

Neun Karten der Tabelle decken die Zweige ab, und die Unterscheidung, die am meisten Zeit spart, ist erforderlich gegen unterstützt:

• 4000 0000 0000 3220 — Authentifizierung erforderlich, sie gelingt. Das ist die Karte, gegen die du baust. Mit ihr merkst du, ob dein Client den Bestätigungsschritt wirklich aufruft oder requires_action still als Fehler behandelt.
• 4000 0000 0000 3055 — 3D Secure wird unterstützt, standardmäßig aber nicht angefordert. Nützlich, um zu prüfen, dass du die Authentifizierung nicht versehentlich zur Pflicht gemacht hast.
• 4000 0084 0000 1629 und 4000 0084 0000 1280 — die beiden schlechten Enden: Der Kunde authentifiziert sich und der Aussteller lehnt trotzdem ab, oder die Abfrage selbst schlägt fehl. Beide kommen als card_declined zurück; eine Fehlerbehandlung, die eine abgeschlossene Abfrage für eine abgeschlossene Zahlung hält, zeigt eine Erfolgsseite für eine Zahlung, die nie stattgefunden hat.
• 4000 0025 0000 3155 und 4000 0027 6000 3184 — die Fälle mit gespeicherter Karte. Die erste verlangt Authentifizierung für Off-Session-Zahlungen, bis sie für künftige Zahlungen eingerichtet ist; die zweite verlangt sie immer. Wenn du später abbuchen willst, ohne dass der Kunde dabei ist, entscheiden diese beiden über eine funktionierende Verlängerung oder ein totes Abo.

Eine Falle: Nur die Karten dieser Gruppe testen 3D Secure wirklich. Andere Testkarten können es auslösen, aber Stripe gibt dann attempt_acknowledged zurück und überspringt die zusätzlichen Schritte — deine Challenge-Oberfläche erscheint nie, und du schließt fälschlich, dass sie funktioniert. Die deutsche Karte und die anderen europäischen Karten der Gruppe „nach Land“ gehen ohnehin ohne Authentifizierung durch. Und 3D-Secure-Weiterleitungen finden für Zahlungen, die direkt im Stripe-Dashboard angelegt werden, nicht statt: Steuere den Test über dein eigenes Frontend oder einen API-Aufruf.

Stripe-Testkarten nach Land

Stripe führt eine eigene Liste von Testkarten nach Land: 64 Karten aus 58 Ländern, jede simuliert eine erfolgreiche Zahlung mit einer Karte aus diesem Land. Sie sind die letzte Gruppe der Tabelle, und auf dieser Seite steht Deutschland darin an erster Stelle. Die PaymentMethods folgen dem Ländercode — pm_card_de, pm_card_at, pm_card_ch — mit drei Ausnahmen: Die mexikanische Carnet-Karte und die saudische Karte haben keine PaymentMethod, und die japanische JCB-Karte nutzt pm_card_jcb, dieselbe wie die JCB-Karte der Markengruppe. Die Zeile für die Vereinigten Staaten ist 4242 4242 4242 4242 selbst, mit eigener pm_card_us.

Diese Karten ändern das Ausstellerland, und genau dafür sind sie da: Stripe berechnet grenzüberschreitende Gebühren nach dem Land des Kartenausstellers, auch in Testumgebungen. Lass sie also durch alles laufen, was die Gebühr oder das Land der Karte ausliest — etwa eine Abrechnung, die zwischen EWR- und Auslandskarten unterscheidet. Authentifizierung testen sie nicht: Die Karten aus Europa und dem Nahen Osten gehen ohne 3D Secure durch.

Um zu simulieren, wo der Kunde sitzt, statt woher seine Karte kommt, dokumentiert Stripe E-Mail-Adressen im Standortformat für Checkout-Sitzungen, Zahlungslinks und Preistabellen: Häng +location_XX an den lokalen Teil, etwa test+location_DE@example.com, und übergib die Adresse als customer_email einer Checkout-Sitzung oder als prefilled_email eines Zahlungslinks. So siehst du, was eine Kundin in Deutschland im Checkout angezeigt bekommt.

Unter der Kartentabelle stehen die Testwerte, die Stripe für drei lokale Methoden veröffentlicht: SEPA-IBANs für Deutschland, Frankreich und Spanien, Konbini für Japan und Boleto für Brasilien. Sie entscheiden sich anders als Karten. Eine SEPA-Lastschrift wartet in processing, bevor sie gelingt oder fehlschlägt, ein Konbini- oder Boleto-Gutschein wartet in requires_action, bis er bezahlt ist oder abläuft — jede Zeile nennt deshalb die ganze Abfolge von Ereignissen, die dein Webhook bekommt, nicht nur eines.

Rückerstattungen, Anfechtungen und alles, was später kommt

Rückerstattungen sind im Live-Modus asynchron: Eine Rückerstattung kann scheinbar gelingen und später fehlschlagen, oder erst ausstehen und später gelingen. Fast jede Testsuite verpasst das, weil Rückerstattungen mit gewöhnlichen Testkarten sofort erfolgreich sind und ihren Status danach nie ändern. Zwei Karten holen das echte Verhalten zurück: 4000 0000 0000 7726 lässt die Rückerstattung erst ausstehen und später gelingen, 4000 0000 0000 5126 meldet sie erst als erfolgreich und lässt sie später scheitern. Beide senden danach ein Ereignis — genau der Codepfad, den du geschrieben haben willst, bevor ein Kunde am Telefon nach Geld fragt, das nie zurückkam.

Anfechtungen laufen genauso, nur in Zeitlupe. Die Zahlung gelingt ganz normal, Tage später erscheint eine Rückbuchung, und charge.dispute.created ist die einzige Nachricht, die du bekommst. 4000 0000 0000 0259 löst eine Anfechtung wegen Betrugs aus, 4000 0000 0000 2685 „Produkt nicht erhalten“, und 4000 0000 0000 1976 eine Anfrage statt einer vollen Rückbuchung — ein Unterschied, der sich lohnt, weil eine Anfrage oft ohne Eskalation geschlossen werden kann und eine Rückbuchung nicht. 4000 0000 0000 5423 erzeugt stattdessen eine frühzeitige Betrugswarnung: das Netzwerk kündigt eine wahrscheinliche Anfechtung an, solange eine freiwillige Rückerstattung noch möglich ist.

Um auch den Ausgang zu simulieren, antwortest du auf die Anfechtung mit den Beweiswerten, die Stripe für Tests reserviert: winning_evidence schließt sie als gewonnen, losing_evidence als verloren, und escalate_inquiry_evidence macht aus einer Anfrage eine Rückbuchung. Über die API übergibst du den Wert als uncategorized_text. Für die SEPA-Lastschrift gibt es mit DE35370400440532013002 eine eigene Test-IBAN, die sofort nach dem Erfolg eine Zahlungsanfechtung erzeugt.

Als Letztes aus dieser Gruppe: 4000 0000 0000 0077 bucht das Geld direkt auf dein verfügbares statt auf dein ausstehendes Guthaben. Das ist kein Zahlungstest, sondern ein Buchhaltungstest — nützlich, wenn nachgelagert etwas Auszahlungen abgleicht und du nicht erst eine Abwicklungsfrist abwarten willst, um zu sehen, ob es funktioniert.

Die Fixtures als JSON oder CSV herunterladen

Eine Tabelle, die du von Hand abschreiben musst, schreibst du falsch ab. Die beiden Download-Knöpfe oben auf der Seite liefern dieselben 119 Karten als maschinenlesbare Dateien, im Browser aus genau den Daten erzeugt, aus denen diese Seite gerendert wird — was du herunterlädst, kann also nicht von dem abweichen, was du gerade gelesen hast.

Das JSON ist ein Objekt mit source, checked, count und einem Array cards. Jede Karte trägt eine stabile id, auf die du dich in einem Testnamen beziehen kannst, die Ziffern, die Marke, die Gruppe, eine einzeilige Beschreibung, die Regeln für CVC und Ablaufdatum, die vier Felder des Abgleichs — payment_method, error_code, decline_code und webhook_event — und country, den ISO-Code des Ausstellerlands für die Karten der Gruppe nach Land. Felder, die nicht zutreffen, sind null statt zu fehlen, damit ein Parser nie auf fehlende Schlüssel prüfen muss.

Das CSV enthält dieselben zwölf Spalten mit Anführungszeichen nach RFC 4180 — es öffnet sich in einer Tabellenkalkulation und lädt in pandas ohne Konvertierungsargument. Beide Dateien bleiben englisch, in jeder Sprachversion dieser Seite dieselben. Die Testwerte der lokalen Zahlungsmethoden sind zum Kopieren da, nicht zum Herunterladen: Keine der beiden Dateien enthält sie.

Beide Downloads folgen dem gesetzten Filter. Grenz die Tabelle auf die Ablehnungen ein, drück „JSON herunterladen“, und du bekommst zehn Zeilen statt 119 — meist genau das, was ein parametrisierter Test will:

test.each(fixtures.cards.filter(c => c.group === 'decline'))(
  '$id surfaces $decline_code',
  async ({ payment_method, error_code, decline_code }) => { /* … */ },
);

Die Dateien tragen die Quell-URL und das Prüfdatum, denn einer Kartenliste ohne Datum kannst du in sechs Monaten nicht mehr trauen. Ändert Stripe eine Nummer, ist die ehrliche Korrektur ein erneuter Blick in die Quelle, nicht eine veraltete Kopie im Repository.

Was du eigentlich baust

Niemand schlägt Testkarten zum Spaß nach. Du bist hier, weil du einen Checkout verdrahtest, und der Checkout ist ein Teil von etwas Größerem: ein Katalog, ein Preis, den der Kunde nicht ändern kann, eine Sitzung, die irgendwo mit einem Geheimnis erzeugt wird, ein Webhook, der entscheidet, ob die Bestellung als bezahlt gilt, und alles, was passiert, nachdem das Geld angekommen ist.

Das Teil, das am häufigsten schiefgeht, ist nicht die Karte, sondern der Preis. Eine statische Website, die ihre Preise im HTML hält und einen Betrag an einen Checkout-Endpunkt schickt, vertraut dem Browser die Zahl an — und der Browser ist nicht vertrauenswürdig. Das ist eine ganze Klasse von Fehlern, die keine Testkarte je findet, denn eine manipulierte Zahlung geht wunderbar durch.

Clize baut genau deshalb auf Stripe Checkout und legt den Preis auf die Serverseite: Ein gehosteter Shop berechnet jeden Warenkorb gegen die _catalog.json, die mit der Website ausgeliefert wird, und ignoriert den Betrag, den der Client behauptet. Wenn das die Form deines Problems ist, gibt es für die Katalogdatei einen Generator und einen Validator (auf Englisch). Und wenn nur ein Kunde einen Betrag bezahlen soll, liefert clize pay link --amount 49 eine echte Stripe-Checkout-URL ohne eigenes Stripe-Konto — diese Zahlung ist echtes Geld, also halte sie weit weg von den Nummern auf dieser Seite.

$ npm i -g @clize/clize && clize login
$ clize pay link --amount 49 --for "Rechnung 1042"