Weiter zum Inhalt
Konto erstellen
oder
anmelden
Das Logo der Stripe-Dokumentation
/
KI fragen
Konto erstellen
Anmelden
Jetzt starten
Zahlungen
Umsatz
Plattformen und Marktplätze
Geldmanagement
Entwicklerressourcen
Übersicht
Versionierung
Änderungsprotokoll
Aktualisieren Sie Ihre API-Version
Ihre SDK-Version aktualisieren
Essentials
SDKs
API
Tests
    Übersicht
    Tests
    Anwendungsszenarien für Tests
    Sandboxes
    Rendering von Apple Pay und Google Pay testen
Stripe-CLI
Beispiel-Projekte
Tools
Workbench
Entwickler-Dashboard
Stripe Shell
Stripe für Visual Studio Code
Funktionen
Arbeitsabläufe
Ereignisziele
Stripe-StatuswarnungenHochgeladene Dateien
KI-Lösungen
Agent-Toolkit
Model Context Protocol
Sicherheit und Datenschutz
Sicherheit
Stripebot-Webcrawler
Datenschutz
Extend Stripe
Erstellen Sie Stripe-Apps
Verwenden Sie Apps von Stripe
Partner
Partner-Ecosystem
Partner-Zertifizierung
StartseiteEntwicklerressourcenTesting

Testen

Zahlungen simulieren, um Ihre Integration zu testen.

Um Ihre Integration zu testen, simulieren Sie Transaktionen ohne Geldbewegungen mit speziellen Testwerten in einer Sandbox. Sie können über die Kontoauswahl oben rechts auf der Seite oder im Dashboard auf Ihre Sandboxes zugreifen.

Testkarten nehmen die Rolle gefälschter Kreditkarten an und ermöglichen es Ihnen, die folgenden Szenarien zu simulieren:

  • Erfolgreiche Zahlungen nach Kartenmarke oder Land
  • Kartenfehler aufgrund von Ablehnungen, Betrug oder ungültigen Daten
  • Anfechtungen und Rückerstattungen
  • Authentifizierung mit 3D Secure und PINs

Das Testen von Zahlungen ohne Karten funktioniert ähnlich. Bei Zahlungen ohne Karten handelt es sich um Zahlungsmethoden, die keine Kredit- oder Debitkarten sind. Stripe unterstützt verschiedene Zahlungsoptionen ohne Karte, wie Digital Wallets und Banküberweisungen. Jede Zahlungsmethode hat ihre eigenen spezifischen Werte.

Verwenden Sie keine Testumgebungen für Belastungstests Ihrer Integration, da Sie möglicherweise an Ratenbegrenzungen stoßen. Informationen zu Belastungstests Ihrer Integration finden Sie unter Belastungstests.

Verwendung von Testkarten

Jedes Mal, wenn Sie mit einer Testkarte arbeiten, verwenden Sie in allen API-Aufrufen Test-API-Schlüssel. Dies gilt unabhängig davon, ob Sie ein Zahlungsformular bereitstellen, um interaktive Tests durchzuführen, oder ob Sie Testcode schreiben.

Häufiger Fehler

Verwenden Sie keine echten Kartenangaben. Der Stripe-Rahmenvertrag verbietet das Testen im Live-Modus mit echten Angaben für Zahlungsmethoden. Verwenden Sie Ihre Test-API-Schlüssel und die unten aufgeführten Kartennummern.

Interaktives Testen

Verwenden Sie beim interaktiven Testen eine Kartennummer, z. B. 4242 4242 4242 4242. Geben Sie die Kartennummer im Dashboard oder in einem beliebigen Zahlungsformular ein.

  • Verwenden Sie ein gültiges Datum in der Zukunft, wie 12/34.
  • Verwenden Sie eine beliebige dreistellige Prüfziffer/CVC (vier Ziffern für American Express-Karten).
  • Verwenden Sie für andere Formularfelder einen beliebigen Wert.
Ein Beispiel für ein Zahlungsformular, das die Eingabe einer Testkartennummer zeigt. Die Kartennummer ist „4242 4242 4242 4242“, das Ablaufdatum ist „12/34“ und die Prüfziffer ist „567“. Andere Felder haben willkürliche Werte. Die E-Mail-Adresse lautet zum Beispiel „test@example.com“.

Formular interaktiv testen mit der Testkartennummer 4242 4242 4242 4242

Testcode verwenden

Verwenden Sie beim Schreiben von Testcode eine PaymentMethod wie pm_card_visa anstelle einer Kartennummer. Wir raten davon ab, Kartennummern direkt in API-Aufrufen oder serverseitigem Code zu verwenden, auch nicht in Testumgebungen. Wenn Sie diese verwenden, ist Ihr Code möglicherweise nicht PCI-konform, wenn Sie live gehen. Standardmäßig ist eine PaymentMethod nicht mit einem Kunden verknüpft.

Command Line
cURL
Stripe CLI
Ruby
Python
PHP
Java
Node.js
Go
.NET
No results
curl https://api.stripe.com/v1/payment_intents \ -u "
sk_test_BQokikJOvBiI2HlWgH4olfQ2
:"
\ -d amount=500 \ -d currency=gbp \ -d payment_method=pm_card_visa \ -d "payment_method_types[]"=card

Die meisten Integrationen verwenden keine Token mehr, aber wir stellen Test-Token wie tok_visa zur Verfügung, wenn Sie diese benötigen.

Wenn Sie bereit sind, Ihre Integration live zu schalten, ersetzen Sie Ihre für den Test zu veröffentlichenden und geheimen API-Schlüssel durch Live-Schlüssel. Sie können keine Live-Zahlungen verarbeiten, wenn Ihre Integration immer noch Ihre Test-API-Schlüssel verwendet.

Karten nach Marke

Verwenden Sie Testkarten aus der folgenden Liste, um eine erfolgreiche Zahlung für eine bestimmte Kartenmarke zu simulieren.

Vorsicht

Grenzüberschreitende Gebühren werden basierend auf dem Land des Kartenausstellers erhoben. Für Karten, deren Ausstellerland nicht die USA ist (z. B. JCB und UnionPay), fallen auch in Testumgebungen Gebühren für grenzüberschreitende Transaktionen an.

MarkeNummerPrüfziffer/CVCDatum
VisaBeliebige 3 ZiffernBeliebiges zukünftiges Datum
Visa (Debit)Beliebige 3 ZiffernBeliebiges zukünftiges Datum
MastercardBeliebige 3 ZiffernBeliebiges zukünftiges Datum
Mastercard (2er-Reihe)Beliebige 3 ZiffernBeliebiges zukünftiges Datum
Mastercard (Debit)Beliebige 3 ZiffernBeliebiges zukünftiges Datum
Mastercard (Prepaid)Beliebige 3 ZiffernBeliebiges zukünftiges Datum
American ExpressBeliebige 4 ZiffernBeliebiges zukünftiges Datum
American ExpressBeliebige 4 ZiffernBeliebiges zukünftiges Datum
DiscoverBeliebige 3 ZiffernBeliebiges zukünftiges Datum
DiscoverBeliebige 3 ZiffernBeliebiges zukünftiges Datum
Discover (Debit)Beliebige 3 ZiffernBeliebiges zukünftiges Datum
Diners ClubBeliebige 3 ZiffernBeliebiges zukünftiges Datum
Diners Club (14-stellige Kartennummer)Beliebige 3 ZiffernBeliebiges zukünftiges Datum
BCcard und DinaCardBeliebige 3 ZiffernBeliebiges zukünftiges Datum
JCBBeliebige 3 ZiffernBeliebiges zukünftiges Datum
UnionPayBeliebige 3 ZiffernBeliebiges zukünftiges Datum
UnionPay (Debit)Beliebige 3 ZiffernBeliebiges zukünftiges Datum
UnionPay (19-stellige Karte)Beliebige 3 ZiffernBeliebiges zukünftiges Datum

Die meisten Cartes Bancaires- und EFTPOS-Karten haben ein Co-Branding mit Visa oder Mastercard. Die Testkarten in der folgenden Tabelle simulieren erfolgreiche Zahlungen mit Co-Branding-Karten.

Marke/Co-MarkeNummerPrüfziffer/CVCDatum
Cartes Bancaires/VisaBeliebige 3 ZiffernBeliebiges zukünftiges Datum
Cartes Bancaires/MastercardBeliebige 3 ZiffernBeliebiges zukünftiges Datum
EFTPOS Australien/VisaBeliebige 3 ZiffernBeliebiges zukünftiges Datum
EFTPOS Australien/MastercardBeliebige 3 ZiffernBeliebiges zukünftiges Datum

Karten nach Land

Verwenden Sie Testkarten aus den folgenden Abschnitten, um erfolgreiche Zahlungen aus bestimmten Ländern zu simulieren.

LandNummerMarke
NORD-, MITTEL- UND SÜDAMERIKA
Vereinigte Staaten (US)Visa
Argentinien (AR)Visa
Brasilien (BR)Visa
Kanada (CA)Visa
Chile (CL)Visa
Kolumbien (CO)Visa
Costa Rica (CR)Visa
Ecuador (EC)Visa
Mexico (MX)Visa
Mexico (MX)Carnet
Panama (PA)Visa
Paraguay (PY)Visa
Peru (PE)Visa
Uruguay (UY)Visa
EUROPA und NAHER OSTEN

Sicherheitshinweis

Die Vorgaben der starken Kundenauthentifizierung erfordern eine Authentifizierung mit 3D Secure für Online-Zahlungen innerhalb des Europäischen Wirtschaftsraums. Die Testkarten in diesem Bereich simulieren eine Zahlung, die ohne Authentifizierung erfolgreich ist. Wir empfehlen auch, Szenarien mit Authentifizierung unter Verwendung von 3D Secure-Testkarten zu testen.

Vereinigte Arabische Emirate (AE)Visa
Vereinigte Arabische Emirate (AE)Mastercard
Österreich (AT)Visa
Belgien (BE)Visa
Bulgarien (BG)Visa
Belarus (BY)Visa
Kroatien (HR)Visa
Zypern (CY)Visa
Tschechische Republik (CZ)Visa
Dänemark (DK)Visa
Estland (EE)Visa
Finnland (FI)Visa
Frankreich (FR)Visa
Deutschland (DE)Visa
Gibraltar (GI)Visa
Griechenland (GR)Visa
Ungarn (HU)Visa
Irland (IE)Visa
Italien (IT)Visa
Lettland (LV)Visa
Liechtenstein (LI)Visa
Litauen (LT)Visa
Luxemburg (LU)Visa
Malta (MT)Visa
Niederlande (NL)Visa
Norwegen (NO)Visa
Polen (PL)Visa
Portugal (PT)Visa
Rumänien (RO)Visa
Saudi-Arabien (SA)Visa
Slowenien (SI)Visa
Slowakei (SK)Visa
Spanien (ES)Visa
Schweden (SE)Visa
Schweiz (CH)Visa
Vereinigtes Königreich (GB)Visa
Vereinigtes Königreich (GB)Visa (Debit)
Vereinigtes Königreich (GB)Mastercard
ASIEN-PAZIFIK

Regionale Aspekte
Indien

Informationen zum Testen von Abonnements, die Mandate und Benachrichtigungen vor Durchführung der Lastschrift erfordern, finden Sie unter Wiederkehrende Zahlungen in Indien.

Australien (AU)Visa
China (CN)Visa
Hongkong (HK)Visa
Indien (IN)Visa
Japan (JP)Visa
Japan (JP)JCB
Malaysia (MY)Visa
Neuseeland (NZ)Visa
Singapur (SG)Visa
Taiwan (TW)Visa
Thailand (TH)Visa (Kredit)
Thailand (TH)Visa (Debit)

HSA- und FSA-Testkarten

Im Folgenden finden Sie Karten für die Simulation von Transaktionen mit Health Savings Accounts (HSA) und Flexible Spending Accounts (FSA). Diese Konten werden häufig für medizinische Ausgaben verwendet. Durch Tests mit ihnen wird die ordnungsgemäße Abwicklung von Transaktionen im Gesundheitswesen in Ihrer Anwendung sichergestellt.

Marke/TypNummerPrüfziffer/CVCDatum
Visa FSABeliebige 3 ZiffernBeliebiges zukünftiges Datum
Visa HSABeliebige 3 ZiffernBeliebiges zukünftiges Datum
Mastercard FSABeliebige 3 ZiffernBeliebiges zukünftiges Datum

Abgelehnte Zahlungen

Testen Sie mithilfe von Testkarten aus diesem Bereich die Logik Ihrer Integration für den Umgang mit Fehlern, indem Sie Zahlungen simulieren, die aus verschiedenen Gründen vom Aussteller abgelehnt werden. Die Verwendung einer dieser Karten führt zu einem Kartenfehler mit dem angegebenen Fehlercode und dem Ablehnungscode.

Häufiger Fehler

Um eine falsche CVC zu simulieren, müssen Sie eine beliebige dreistellige Prüfziffer angeben. Wenn Sie keine CVC bereitstellen, führt Stripe die CVC-Prüfung nicht durch, sodass diese auch nicht fehlschlagen kann.

BeschreibungNummerFehlercodeAblehnungscode
Allgemeine Ablehnungcard_declinedgeneric_decline
Abgelehnte Zahlung aufgrund unzureichender Deckungcard_declinedinsufficient_funds
Abgelehnte Zahlung aufgrund von verlorener Kartecard_declinedlost_card
Abgelehnte Zahlung aufgrund von gestohlener Kartecard_declinedstolen_card
Abgelehnte Zahlung aufgrund von abgelaufener Karteexpired_cardn. z.
Abgelehnte Zahlung aufgrund falscher Prüfziffer/CVCincorrect_cvcn. z.
Abgelehnte Zahlung aufgrund eines Bearbeitungsfehlersprocessing_errorn. z.
Abgelehnte Zahlung aufgrund von falscher Nummerincorrect_numbern. z.
Abgelehnte Zahlung wegen überschrittenem Geschwindigkeitsgrenzwertcard_declinedcard_velocity_exceeded

Die Karten in der vorherigen Tabelle können keinem Kundenobjekt beigefügt werden. Um eine abgelehnte Zahlung mit einer erfolgreich beigefügten Karte zu simulieren, verwenden Sie die nächste Tabelle.

BeschreibungNummerDetails
Abgelehnte Zahlung nach dem BeifügenDiese Karte konnte erfolgreich einem Kunden-Objekt beigefügt werden. Die Versuche, den Kunden zu belasten, schlagen jedoch fehl.

Betrugsprävention

Stripes Betrugspräventionssystem Radar kann Zahlungen blockieren, wenn sie eine hohe Risikostufe aufweisen oder Verifizierungsprüfungen nicht bestehen. Sie können die Karten in diesem Bereich verwenden, um Ihre Radar-Einstellungen zu testen. Außerdem können sie verwendet werden, um zu testen, wie Ihre Integration auf blockierte Zahlungen reagiert.

Jede Karte simuliert bestimmte Risikofaktoren. Ihre Radar-Einstellungen bestimmen darüber, welche Risikofaktoren dazu führen, dass eine Zahlung blockiert wird. Blockierte Zahlungen führen zu Kartenfehlern mit einem Betrugs-Fehlercode.

Häufiger Fehler

Um eine fehlgeschlagene CVC-Prüfung zu simulieren, müssen Sie eine beliebige dreistellige Prüfziffer/CVC angeben. Um eine fehlgeschlagene Überprüfung der Postleitzahl zu simulieren, müssen Sie eine beliebige Postleitzahl angeben. Wenn Sie diese Werte nicht angeben, führt Radar die entsprechenden Prüfungen nicht durch, sodass sie auch nicht fehlschlagen können.

BeschreibungNummerDetails

Immer blockiert

Die Zahlung hat die „höchste“ Risikostufe

Wird immer von Radar blockiert.

Höchstes Risiko

Die Zahlung hat die „höchste“ Risikostufe

Könnte je nach Ihren Einstellungen von Radar blockiert werden.

Erhöhtes Risiko

Die Zahlung weist die Risikostufe „erhöht“ auf

Wenn Sie Radar for Fraud Teams verwenden, könnte sie von Radar in die Überprüfungswarteschlange gestellt werden.

CVC-Prüfung schlägt fehl

Wenn Sie eine Prüfziffer/CVC angeben, schlägt deren Überprüfung fehl.

Könnte je nach Ihren Einstellungen von Radar blockiert werden.

Überprüfung der Postleitzahl schlägt fehl

Wenn Sie eine Postleitzahl angeben, schlägt deren Überprüfung fehl.

Könnte je nach Ihren Einstellungen von Radar blockiert werden.

CVC-Prüfung schlägt mit erhöhtem Risiko fehl

Wenn Sie eine Prüfziffer angeben, schlägt die Prüfung mit der Risikostufe „erhöht“ fehl

Könnte je nach Ihren Einstellungen von Radar blockiert werden.

Postleitzahlprüfung schlägt mit erhöhtem Risiko fehl

Wenn Sie eine Postleitzahl angeben, schlägt die Postleitzahlprüfung mit der Risikostufe „erhöht“ fehl

Könnte je nach Ihren Einstellungen von Radar blockiert werden.

Überprüfung der Zeile1 schlägt fehl

Die Überprüfung der Adresszeile 1 schlägt fehl.

Die Zahlung ist erfolgreich, es sei denn, Sie blockieren sie mit einer benutzerdefinierten Radar-Regel.

Adressprüfungen schlagen fehl

Sowohl die Prüfung der Postleitzahl der Adresse als auch die Prüfung der Adresszeile 1 schlagen fehl.

Könnte je nach Ihren Einstellungen von Radar blockiert werden.

Adresse nicht verfügbar

Sowohl die Prüfung der Postleitzahl der Adresse als auch die Prüfung der Adresszeile 1 sind nicht verfügbar.

Die Zahlung ist erfolgreich, es sei denn, Sie blockieren sie mit einer benutzerdefinierten Radar-Regel.

Ungültige Daten

Geben Sie ungültige Details an, um Fehler aufgrund ungültiger Daten zu testen. Dafür benötigen Sie keine spezielle Testkarte. Jeder ungültige Wert funktioniert. Beispiel:

  • invalid_expiry_month: Einen ungültigen Monat verwenden (z. B. 13).
  • invalid_expiry_year: Verwenden Sie ein Jahr, das bis zu 50 Jahre in der Vergangenheit liegt, z. B. 95.
  • invalid_cvc: Verwenden Sie eine zweistellige Zahl (z. B. 99).
  • incorrect_number: Verwenden Sie eine Kartennummer, bei der die Luhn-Prüfung fehlschlägt, z. B. .

Angefochtene Zahlungen

To simulate a disputed transaction, use the test cards in this section. Then, to simulate winning or losing the dispute, provide winning or losing evidence.

BeschreibungNummerDetails
BetrügerischBei den Standardeinstellungen des Kontos ist die Zahlung erfolgreich, wird aber als betrügerisch angefochten. Diese Art der Zahlungsanfechtung ist nach der 3D Secure-Authentifizierung geschützt.
Nicht erhaltenBei den Standardeinstellungen des Kontos ist die Zahlung erfolgreich, wird jedoch angefochten, da das Produkt nicht erhalten wurde. Diese Art der Zahlungsanfechtung ist nach der 3D Secure-Authentifizierung nicht geschützt.
AnfrageMit den Standard-Kontoeinstellungen ist die Zahlung erfolgreich, wird aber als Anfrage angefochten.
WarnungBei Standard-Kontoeinstellungen ist die Abbuchung erfolgreich, es wird jedoch eine frühzeitige Betrugswarnung empfangen.
Mehrere ZahlungsanfechtungenBei den Standard-Kontoeinstellungen ist die Abbuchung erfolgreich, wird aber mehrmals angefochten.
Visa Compelling Evidence 3.0Beit den Standard-Kontoeinstellungen ist die Abbuchung erfolgreich, wird aber als eine für Visa Compelling Evidence 3.0 berechtigte Zahlungsanfechtung behandelt.
Visa-ComplianceBei den Standard-Kontoeinstellungen ist die Zahlung erfolgreich, wird aber als Visa-Compliance-Zahlungsanfechtung behandelt.

Beweis

Um eine gewonnene oder verlorene Zahlungsanfechtung zu simulieren, antworten Sie mit einem der Beweiswerte aus der nachfolgenden Tabelle.

  • Wenn Sie mit der API antworten, übergeben Sie den Wert aus der Tabelle als uncategorized_text.
  • Wenn Sie im Dashboard oder in In Connect eingebetteten Komponenten antworten, geben Sie den Wert aus der Tabelle in das Feld Zusätzliche Informationen ein. Klicken Sie dann auf Beweise übermitteln.
BeweisBeschreibung
winning_evidenceSchließt die Anfechtung als gewonnen und schreibt Ihrem Konto den Zahlungsbetrag und die entsprechenden Gebühren gut.
losing_evidenceSchließt die Anfechtung als verloren, ohne eine Gutschrift auf Ihr Konto durchzuführen. Bei Anfragen wird die Anfrage auf diese Weise ohne Eskalation geschlossen.
escalate_inquiry_evidenceEskaliert die Anfrage in eine Rückbuchung. Dadurch wird die Anfrage in eine vollständige Zahlungsanfechtung umgewandelt und Ihr Konto mit dem Betrag der angefochtenen Zahlung und den damit verbundenen Gebühren belastet.

Rückerstattungen

Rückerstattungen erfolgen im Live-Modus asynchron: Eine Rückerstattung kann scheinbar erfolgreich sein und später fehlschlagen, oder sie kann zunächst als ausstehend erscheinen und später erfolgreich sein. Verwenden Sie die Testkarten in diesem Bereich, um Rückerstattungen mit diesen Verhaltensweisen zu simulieren. (Bei allen anderen Testkarten sind Rückerstattungen sofort erfolgreich und der Status bleibt anschließend unverändert.)

BeschreibungNummerDetails
Asynchroner ErfolgDie Zahlung ist erfolgreich. Wenn Sie eine Rückerstattung veranlassen, ist der Status zunächst ausstehend. Einige Zeit später wechselt der Status zu erfolgreich und sendet das Ereignis refund.updated.
Asynchroner FehlerDie Zahlung ist erfolgreich. Wenn Sie eine Rückerstattung veranlassen, ist ihr Status zunächst erfolgreich. Einige Zeit später wechselt der Status zu fehlgeschlagen und sendet das Ereignis refund.failed.

Sie können eine Rückerstattung über eine Karte nur über das Dashboard stornieren. Im Live-Modus können Sie eine Karten-Rückerstattung innerhalb eines kurzen Zeitraums stornieren, der nicht näher spezifiziert ist. In Testumgebungen wird dieser Zeitraum, in dem Sie eine Karten-Rückerstattung stornieren können, mit 30 Minuten simuliert.

Verfügbarer Saldo

Verwenden Sie die Testkarten in diesem Abschnitt, um Geldmittel aus einer Testtransaktion direkt auf Ihr verfügbares Guthaben zu überweisen. Andere Testkarten senden Geld von einer erfolgreichen Zahlung an Ihr ausstehendes Guthaben.

BeschreibungNummerDetails
Umgehen Ihres ausstehenden SaldosDie US-Abbuchung ist erfolgreich, und die Geldmittel werden Ihrem verfügbaren Guthaben sofort hinzugefügt (unter Umgehung Ihres ausstehenden Saldos).
Umgehen Ihres ausstehenden SaldosDie internationale Abbuchung ist erfolgreich, und die Geldmittel werden Ihrem verfügbaren Guthaben sofort hinzugefügt (unter Umgehung Ihres ausstehenden Saldos).

Authentifizierung mit 3D Secure

3D Secure erfordert einen zusätzlichen Authentifizierungsschritt für Kreditkartentransaktionen. Mit den Testkarten in diesem Abschnitt können Sie simulieren, wie die Authentifizierung in verschiedenen Zahlungsabläufen ausgelöst wird.

Nur Karten in diesem Bereich testen Ihre 3D Secure-Integration effektiv, da sie definiertes 3DS-Verhalten simulieren, wie z. B. einen abfragebasierten Ablauf oder eine nicht unterstützte Karte. Andere Testkarten von Stripe lösen möglicherweise ebenfalls 3DS aus, wir geben jedoch dann attempt_acknowledged zurück und umgehen so die zusätzlichen Schritte, da 3DS-Tests bei diesen Karten nicht von Wichtigkeit sind.

Dashboard nicht unterstützt

3D Secure-Weiterleitungen erfolgen nicht für Zahlungen, die direkt im Stripe-Dashboard erstellt wurden. Verwenden Sie stattdessen das eigene Frontend Ihrer Integration oder einen API-Aufruf.

Authentifizierung und Einrichtung

Verwenden Sie die Testkarten in diesem Abschnitt, um Zahlungen mit Authentifizierung zu simulieren. Einige dieser Karten können auch für zukünftige Zahlungen eingerichtet werden oder wurden bereits entsprechend eingerichtet.

BeschreibungNummerDetails
Nur authentifizieren, wenn keine Einrichtung bestehtDiese Karte erfordert eine Authentifizierung für Off-Session-Zahlungen, es sei denn, Sie richten sie für zukünftige Zahlungen ein. Nach der Einrichtung ist für Off-Session-Zahlungen keine Authentifizierung mehr erforderlich. On-Session-Zahlungen mit dieser Karte müssen jedoch immer authentifiziert werden.
Immer authentifizierenDiese Karte erfordert eine Authentifizierung für alle Transaktionen, unabhängig davon, wie die Karte eingerichtet ist.
Bereits eingerichtetDiese Karte ist bereits für die Off-Session-Nutzung eingerichtet. Sie erfordert eine Authentifizierung für einmalige und andere On-Session-Zahlungen. Alle Off-Session-Zahlungen sind jedoch so erfolgreich, als wäre die Karte zuvor eingerichtet worden.
Unzureichende GeldmittelDiese Karte erfordert für Einmalzahlungen eine Authentifizierung. Alle Zahlungen werden mit dem Fehlercode insufficient_funds abgelehnt, auch nachdem sie erfolgreich authentifiziert oder zuvor eingerichtet wurden.

Support und Verfügbarkeit

Stripe fordert eine Authentifizierung an, wenn dies gesetzlich vorgeschrieben ist oder durch Ihre Radar-Regeln oder benutzerdefinierten Code ausgelöst wird. Auch wenn eine Authentifizierung angefordert wird, kann diese nicht immer durchgeführt werden – beispielsweise ist die Kundenkarte möglicherweise nicht registriert oder es tritt ein Fehler auf. Verwenden Sie die Testkarten in diesem Abschnitt, um diese Faktoren in verschiedenen Kombinationen zu simulieren.

Notiz

Alle 3DS-Referenzen verweisen auf 3D Secure 2.

3D Secure-NutzungErgebnisNummerDetails
3DS erforderlichOKDie 3D Secure-Authentifizierung muss abgeschlossen sein, damit die Zahlung erfolgreich durchgeführt werden kann. Standardmäßig fordern Ihre Radar-Regeln die 3D Secure-Authentifizierung für diese Karte an.
3DS erforderlichAbgelehnte ZahlungDie 3D Secure-Authentifizierung ist erforderlich, aber Zahlungen werden nach der Authentifizierung mit einem card_declined-Fehlercode abgelehnt. Standardmäßig fordern Ihre Radar-Regeln die 3DSecure-Authentifizierung für diese Karte an.
3DS erforderlichFehlerDie 3D Secure-Authentifizierung ist erforderlich, aber die 3D Secure-Lookup-Anforderung schlägt mit einem Verarbeitungsfehler fehl. Zahlungen werden mit einem card_declined-Fehlercode abgelehnt. Standardmäßig fordern Ihre Radar-Regeln die 3D Secure-Authentifizierung für diese Karte an.
3DS unterstütztOKDie 3D Secure-Authentifizierung kann weiterhin durchgeführt werden, ist aber nicht erforderlich. Standardmäßig fordern Ihre Radar-Regeln keine 3D Secure-Authentifizierung für diese Karte an.
3DS unterstütztFehlerDie 3D Secure-Authentifizierung kann weiterhin durchgeführt werden, ist aber nicht erforderlich. Der Versuch, 3D Secure durchzuführen, führt jedoch zu einem Verarbeitungsfehler. Standardmäßig fordern Ihre Radar-Regeln keine 3D Secure-Authentifizierung für diese Karte an.
3DS unterstütztAbgemeldet3D Secure wird für diese Karte unterstützt, die Karte ist jedoch nicht für 3D Secure registriert. Selbst wenn Ihre Radar-Regeln 3D Secure anfordern sollten, wird die Kundin/der Kunde nicht zur Authentifizierung dieser Karte aufgefordert, da Ihre standardmäßigen Radar-Regeln keine 3D Secure-Authentifizierung für die Karte anfordern.
3DS Nicht unterstützt3D Secure wird von dieser Karte nicht unterstützt und kann nicht aufgerufen werden. Der PaymentIntent oder SetupIntent wird ohne Authentifizierung fortgesetzt.

Mobile abfragebasierte Abläufe für 3D Secure

Bei einer mobilen Zahlung stehen mehrere abfragebasierte Authentifizierungsabläufe, bei denen die Kundinnen und Kunden mit Eingabeaufforderungen der Nutzeroberfläche interagieren müssen, zur Verfügung. Verwenden Sie die Testkarten in diesem Bereich, um einen bestimmten abfragebasierten Ablauf zu Testzwecken auszulösen. Diese Karten sind in browserbasierten Zahlungsformularen oder in API-Aufrufen unbrauchbar. In diesen Umgebungen funktionieren sie, lösen aber kein besonderes Verhalten aus. Da sie in API-Aufrufen nicht nützlich sind, stellen wir keine PaymentMethod oder Token-Werte für Tests zur Verfügung.

Abfragebasierter AblaufNummerDetails
Out-of-BandDie 3D Secure 2-Authentifizierung muss für alle Transaktionen abgeschlossen sein. Löst den abfragebasierten Ablauf mit Out-of-Band-Nutzeroberfläche aus.
Einmal-PasscodeDie 3D Secure 2-Authentifizierung muss für alle Transaktionen abgeschlossen sein. Löst den abfragebasierten Ablauf mit Einmal-Passcode-Nutzeroberfläche aus.
EinfachauswahlDie 3D Secure 2-Authentifizierung muss für alle Transaktionen abgeschlossen sein. Löst den abfragebasierten Ablauf mit Einfachauswahl-Nutzeroberfläche aus.
MehrfachauswahlDie 3D Secure 2-Authentifizierung muss für alle Transaktionen abgeschlossen sein. Löst den abfragebasierten Ablauf mit Mehrfachauswahl-Nutzeroberfläche aus.

Captcha-Abfrage

Um Betrug zu verhindern, zeigt Stripe den Nutzerinnen und Nutzern auf der Bezahlseite möglicherweise eine Captcha-Abfrage an. Anhand der untenstehenden Testkarten können Sie diesen Vorgang simulieren.

BeschreibungNummerDetails
Captcha-AbfrageDie Zahlung ist erfolgreich, wenn die Nutzer/innen die Captcha-Abfrage korrekt beantworten.
Captcha-AbfrageDie Zahlung ist erfolgreich, wenn die Nutzer/innen die Captcha-Abfrage korrekt beantworten.

Zahlungen mit PINs

Verwenden Sie die Testkarten in diesem Bereich, um erfolgreiche persönliche Zahlungen zu simulieren, bei denen eine PIN erforderlich ist. Es gibt viele andere Optionen zum Testen persönlicher Zahlungen, einschließlich eines simulierten Lesegeräts und physischer Testkarten. Weitere Informationen finden Sie unter Stripe-Terminal-Tests.

BeschreibungNummerDetails
Offline-PINDiese Karte simuliert eine Zahlung, bei der der/die Karteninhaber/in aufgefordert wird, eine Offline-PIN einzugeben. Für die resultierende Zahlung ist cardholder_verification_method auf offline_pin festgelegt.
Wiederholungsversuch mit Offline-PINSimuliert einen durch die starke Kundenauthentifizierung (SCA) ausgelösten Wiederholungsablauf, bei dem die anfängliche kontaktlose Zahlung eines Karteninhabers fehlschlägt und das Lesegerät den Nutzer dann auffordert, die Karte einzulegen und die seine Online-PIN einzugeben. Für die resultierende Zahlung ist cardholder_verification_method auf offline_pin festgelegt.
Online-PINDiese Karte simuliert eine Zahlung, bei der der/die Karteninhaber/in aufgefordert wird, eine Online-PIN einzugeben. Für die resultierende Zahlung ist cardholder_verification_method auf online_pin festgelegt.
Wiederholungsversuch mit Online-PINSimuliert einen durch die starke Kundenauthentifizierung (SCA) ausgelösten Wiederholungsablauf, bei dem die anfängliche kontaktlose Zahlung eines Karteninhabers fehlschlägt und das Lesegerät diesen dann auffordert, die Karte einzulegen und die zugehörige Online-PIN einzugeben. Für die resultierende Zahlung ist cardholder_verification_method auf online_pin festgelegt.

Ereignisziele

Um Ihren Webhook-Endpoint oder Ihr Ereignisziel zu testen, wählen Sie eine dieser beiden Optionen aus:

  1. Führen Sie Aktionen in einer Sandbox durch, die zulässige Ereignisse an Ihr Ereignisziel senden. Um beispielsweise das Ereignis charge.succeeded auszulösen, können Sie eine Testkarte, die eine erfolgreiche Zahlung erzeugt verwenden.
  2. Ereignisse mit der Stripe-CLI oder mit Stripe für Visual Studio Code auslösen.

Ratenbegrenzungen

Wenn Ihre Anfragen in Ihren Testumgebungen beginnen, 429 HTTP-Fehler zu erhalten, führen Sie sie seltener durch. Diese Fehler stammen von unserer Ratenbegrenzung, die in Testumgebungen strenger ist als im Live-Modus.

Wir raten davon ab, für Ihre Integration mit der Stripe-API Belastungstests in Testumgebungen durchzuführen. Da der Lastbegrenzer in Testumgebungen strenger ist, treten möglicherweise Fehler auf, die in der Produktion nicht auftreten würden. Einen alternativen Ansatz finden Sie unter Belastungstests.

Zahlungen ohne Karte

Jedes Mal, wenn Sie eine Zahlungsmethode ohne Karte testen, verwenden Sie in allen API-Aufrufen Test-API-Schlüssel. Dies gilt unabhängig davon, ob Sie ein Zahlungsformular bereitstellen, das Sie interaktiv testen können, oder ob Sie Testcode schreiben.

Für verschiedene Zahlungsmethoden werden unterschiedliche Testvorgänge durchgeführt:

Erfahren Sie, wie Sie Szenarien mit sofortigen Verifizierungen mithilfe von Financial Connections testen können.

Transaktions-E-Mails in einer Sandbox senden

Nachdem Sie die Bankkontodetails erfasst und ein Mandat akzeptiert haben, senden Sie die Mandatsbestätigung und die Verifizierungs-E-Mails mit Testeinzahlungen in einer Sandbox.

Wenn Ihre Domain {domain} und Ihr Nutzername {username} ist, verwenden Sie das folgende E-Mail-Format, um E-Mails für Testtransaktionen zu senden: {username}+test_email@{domain}.

Wenn Ihre Domain beispielsweise example.com und Ihr Nutzername Info lautet, verwenden Sie zum Testen von ACH Direct Debit-Zahlungen das Format info+test_email@example.com. Dieses Format stellt sicher, dass E-Mails korrekt weitergeleitet werden. Wenn Sie das Suffix +test_email nicht angeben, senden wir die E-Mail nicht.

Häufiger Fehler

Sie müssen Ihr Stripe-Konto aktivieren, bevor Sie diese E-Mails beim Testen auslösen können.

Testkontonummern

Stripe stellt mehrere Testkontonummern und dazugehörige Token zur Verfügung, um sicherzustellen, dass Ihre Integration für Bankkonten mit manueller Eingabe für den Einsatz in einer Produktionsumgebung bereit ist.

KontonummerTokenBankleitzahlVerhalten
000123456789pm_usBankAccount_success110000000Die Zahlung ist erfolgreich.
000111111113pm_usBankAccount_accountClosed110000000Die Zahlung schlägt fehl, weil das Konto geschlossen ist.
000000004954pm_usBankAccount_riskLevelHighest110000000Die Zahlung wird von Radar aufgrund eines hohen Betrugsrisikos blockiert.
000111111116pm_usBankAccount_noAccount110000000Die Zahlung schlägt fehl, weil kein Konto gefunden wird.
000222222227pm_usBankAccount_insufficientFunds110000000Die Zahlung schlägt aufgrund unzureichender Deckung fehl.
000333333335pm_usBankAccount_debitNotAuthorized110000000Die Zahlung schlägt fehl, weil die Lastschriften nicht autorisiert sind.
000444444440pm_usBankAccount_invalidCurrency110000000Die Zahlung schlägt aufgrund einer ungültigen Währung fehl.
000666666661pm_usBankAccount_failMicrodeposits110000000Die Zahlung sendet keine Testeinzahlungen.
000555555559pm_usBankAccount_dispute110000000Die Zahlung löst eine Zahlungsanfechtung aus.
000000000009pm_usBankAccount_processing110000000Die Zahlung bleibt auf unbestimmte Zeit in Bearbeitung. Dies ist hilfreich beim Testen von PaymentIntent-Stornierungen.
000777777771pm_usBankAccount_weeklyLimitExceeded110000000Die Zahlung schlägt aufgrund des Zahlungsbetrags fehl, wodurch das Konto sein wöchentliches Zahlungsvolumenlimit überschreitet.

Bevor Testtransaktionen abgeschlossen werden können, müssen Sie alle Testkonten verifizieren, auf denen die Zahlung automatisch erfolgreich war oder fehlschlagen ist. Verwenden Sie dazu die nachstehenden Test-Mikroeinzahlungsbeträge oder Beschreibungscodes.

Testen von Mikroeinzahlungen und Beschreibungscodes

Um verschiedene Szenarien zu imitieren, verwenden Sie diese Mikroeinzahlungsbeträge oder 0,01 Beschreibungscodewerte.

Testeinzahlungswerte0.01 BeschreibungscodewerteSzenario
32 und 45SM11AASimuliert die Verifizierung des Kontos.
10 und 11SM33CCSimuliert das Überschreiten der Anzahl zulässiger Verifizierungsversuche.
40 und 41SM44DDSimuliert ein Testeinzahlungs-Timeout.

Abwicklungsverhalten testen

Testtransaktionen werden sofort abgewickelt und Ihrem verfügbaren Testguthaben hinzugefügt. Dieses Verhalten unterscheidet sich vom Live-Modus, bei dem es mehrere Tage dauern kann, bis Transaktionen Ihrem verfügbaren Guthaben gutgeschrieben werden.

Link

Vorsicht

Speichern Sie keine echten Nutzerdaten in Link-Konten der Sandbox. Behandeln Sie sie so, als seien sie öffentlich verfügbar, da diese Testkonten an Ihren veröffentlichbaren Schlüssel gebunden sind.

Derzeit funktioniert Link nur mit Kreditkarten, Debitkarten und qualifizierten Käufen über US-Bankkonten. Link erfordert eine Domain-Registrierung.

Sie können Sandbox-Konten für Link mit jeder gültigen E-Mail-Adresse erstellen. Die folgende Tabelle zeigt die festen einmaligen Passcode-Werte, die Stripe für die Authentifizierung von Sandbox-Konten akzeptiert:

WertErgebnis
Alle anderen 6 Ziffern, die unten nicht aufgeführt sindErfolgreich
000001Fehler, Code ungültig
000002Fehler, Code abgelaufen
000003Fehler, maximale Anzahl an Versuchen überschritten

Mehrere Finanzierungsquellen

Da Stripe zusätzliche Unterstützung für Finanzierungsquellen bietet, müssen Sie Ihre Integration nicht aktualisieren. Stripe unterstützt diese automatisch mit der gleichen Transaktionsabwicklungszeit und den gleichen Garantien wie bei Karten- und Bankkontozahlungen.

Führt Weiterleitung durch

Um die Weiterleitungslogik Ihrer Integration zu testen, indem Sie eine Zahlung simulieren, die einen Weiterleitungsablauf verwendet (z. B. iDEAL), verwenden Sie eine unterstützte Zahlungsmethode, die Weiterleitungen erfordert.

So erstellen Sie einen Test-PaymentIntent, der entweder erfolgreich durchgeführt wird oder fehlschlägt:

  1. Navigieren Sie zu den Einstellungen der Zahlungsmethoden im Dashboard und aktivieren Sie eine unterstützte Zahlungsmethode, indem Sie in Ihrer Testumgebung auf Aktivieren klicken.
  2. Zahlungsdaten erfassen.
  3. Zahlung an Stripe senden.
  4. Autorisieren Sie die Testzahlung oder lassen Sie sie fehlschlagen.

Stellen Sie sicher, dass die Seite (entsprechend return_url) auf Ihrer Website den Status der Zahlung angibt.

Siehe auch

  • Testen Ihrer Connect-Integration
  • Testen Ihrer Abrechnungsintegration
  • Testen Ihrer Terminal-Integration
  • Belastungstests
War diese Seite hilfreich?
JaNein
  • Benötigen Sie Hilfe? Kontaktieren Sie den Kundensupport.
  • Nehmen Sie an unserem Programm für frühzeitigen Zugriff teil.
  • Schauen Sie sich unser Änderungsprotokoll an.
  • Fragen? Sales-Team kontaktieren.
  • LLM? Lesen Sie llms.txt.
  • Unterstützt von Markdoc
Ähnliche Leitfäden
Use Cases testen
API-Schlüssel