So testen Sie Stripe Billing

So testen Sie Ihre Billing-Integration

Testen Sie Ihre Integration gründlich, bevor Sie sie für Kundinnen und Kunden freigeben oder für Live-Aktivitäten verwenden. Nutzen Sie die Ressourcen auf dieser Seite zusätzlich zu allen organisatorischen Richtlinien (z. B. Runbooks, Quality Gates oder Entwicklungschecklisten), um festzustellen, ob Ihre Integration für die Produktionsumgebung bereit ist.

Grundsätze für die Inbetriebnahme

Bevor Sie Ihre Integration live schalten, prüfen Sie diese Checklisten von Stripe:

So sieht ein typischer Integrationsablauf aus.

Stellen Sie bei Abonnement- und wiederkehrenden Umsatzintegrationen sicher, dass zumindest die folgenden Komponenten wie erwartet funktionieren.

In der Tabelle sind Ereignisbenachrichtigungen für jede Komponente aufgelistet. Sie können Ihre Integration so konfigurieren, dass diese Ereignisse mit Webhooks überwacht werden. In diesem Leitfaden erfahren Sie mehr über Ereignisbenachrichtigungen und Tests.

Komponente	Beschreibung	Ereignisse
Kundenanmeldung	Stellen Sie sicher, dass Ihre Integration erfolgreich die Informationen erfassen kann, die Sie benötigen, um einen Kundendatensatz in Stripe zu erstellen. Ihre Kundinnen/Kunden können diese Informationen über Payment Links, Checkout, Elements oder ein mit der Stripe API erstelltes, vollständig nutzerdefiniertes Zahlungsformular eingeben. Gleich welches Formular Sie verwenden, Sie müssen sicherstellen, dass Sie das bei Stripe gespeicherte Kundenobjekt sehen. Sie können das Dashboard oder die API verwenden, um Kundinnen/Kunden zu verwalten.	`customer.created` `customer.subscription.created`
Invoicing	Bei Abonnements werden Rechnungen am Ende jedes Abrechnungszyklus erstellt. Abhängig von Ihrer Zahlungseinzugsmethode können Sie eine Rechnung versenden, um rückständige Zahlungen einzuziehen oder um eine automatische Abbuchung zu bestätigen. Stellen Sie sicher, dass Ihre Integration Rechnungen so erstellt und versendet, wie Sie es erwarten. In dem Leitfaden erfahren Sie mehr über die Erstellung und Verwaltung von Rechnungen für Abonnements. Mithilfe von Test-Uhren können Sie Abrechnungszyklen simulieren, in denen Rechnungen generiert und versendet werden. Im Leitfaden zu Test-Uhren erfahren Sie mehr über spezifische Use cases, die Sie testen können.	`invoice.created` `invoice.finalized` `invoice.finalization_failed` `invoice.paid` `invoice.payment_action_required` `invoice.payment_failed` `invoice.upcoming` `invoice.updated`
Abonnementverwaltung	Richten Sie das Kundenportal ein, damit Ihre Kundinnen und Kunden ihre Abonnements und Rechnungsinformationen verwalten können. Erstellen Sie zum Testen ein Abonnement in einer Sandbox. Melden Sie sich dann als Testnutzer/in beim Portal an und aktualisieren Sie das Abonnement. Überprüfen Sie im Dashboard oder in der API, ob das Abonnement die Änderung des Kunden/der Kundin widerspiegelt. Lesen Sie den Integrationsleitfaden, um zu erfahren, wie Sie das Kundenportal einrichten.	`customer.subscription.deleted` `customer.subscription.paused` `customer.subscription.resumed` `customer.subscription.updated`
Testversionen	Bieten Sie Kundinnen/Kunden eine Testversion Ihrer Dienstleistung an. Um zu prüfen, ob Ihre Testversion korrekt eingerichtet ist, können Sie eine Test-Uhr erstellen. Durch das Abonnement sollte eine Rechnung mit dem Wert Null für den Testzeitraum generiert werden. Erfahren Sie, wie Sie Testversionen mit Test-Uhren testen können. Weitere Informationen zur Funktionsweise von Testversionen finden Sie im Leitfaden zu Abonnement-Testphasen.	`customer.subscription.trial_will_end` `customer.subscription.updated`
Fehlgeschlagene Zahlungen	Zahlungen von Ihren Kund/innen können aus verschiedenen Gründen fehlschlagen. Stellen Sie sicher, dass Ihre Integration mit Fehlern umgehen kann, einschließlich der Wiederholung von Zahlungen. Erfahren Sie, wie Sie fehlgeschlagene Zahlungen testen.	`invoice.finalization_failed` `invoice.payment_failed` `invoice.payment_action_required`

Test-Uhren

Mit Test-Uhren können Sie Billing-Objekte wie Abonnements im Zeitverlauf in einer Sandbox simulieren, sodass Sie nicht ein Jahr warten müssen, um zu sehen, wie Ihre Integration mit einem Zahlungsausfall für eine jährliche Abonnementverlängerung umgeht. Bei Verwendung von Test-Uhren müssen Sie keinen Code schreiben: Sie können Simulationen im Dashboard erstellen. Sie können auch über die API darauf zugreifen. Erfahren Sie mehr über Test-Uhren und gängige Use cases.

Abonnement-Testzeiträume testen

Führen Sie zunächst die folgenden Schritte aus, um mit der Verwendung von Test-Uhren zu beginnen:

Als Nächstes können Sie Testzeiträume mit Test-Uhren ausprobieren. Angenommen, Sie möchten, dass Ihre Kund/innen Ihr Produkt mit einem Sieben-Tage-Testzeitraum kostenlos ausprobieren, bevor Sie mit der Zahlung beginnen, und Sie möchten die Zahlungsinformationen im Voraus erfassen. Führen Sie die folgenden Schritte aus, um diese Situation mit Test-Uhren zu simulieren:

Erstellen Sie eine neue Test-Uhr und legen Sie ihre frozen_time auf den 1. Januar fest.
Fügen Sie eine/n Kund/in und seine/ihre Zahlungsmethode hinzu. Verwenden Sie in diesem Fall eine Testkarte.
Erstellen Sie ein Abonnement und fügen Sie einen kostenlosen Sieben-Tage-Testzeitraum hinzu:

So fügen Sie einem bestehenden Abonnement über das Dashboard einen Testzeitraum hinzu:

Suchen Sie das Abonnement, das Sie ändern möchten.

Klicken Sie auf Aktionen.
Klicken Sie auf Abonnement aktualisieren.
Klicken Sie auf Kostenlosen Testzeitraum hinzufügen und geben Sie im Feld Dauer des kostenlosen Testzeitraums die Zahl „Sieben“ ein.
Klicken Sie auf Abonnement aktualisieren.

Nachdem Sie ein Abonnement mit einem kostenlosen Sieben-Tage-Testzeitraum erstellt haben, wird ein Abonnement mit dem Status trialing erstellt. Aufgrund des kostenlosen Testzeitraums wird eine Rechnung mit dem Betrag 0,00 $ generiert.
Verschieben Sie das Datum auf den 5. Januar, um die Ereignisbenachrichtigung customer.subscription.trial_will_end anzuzeigen. Stripe sendet die Benachrichtigung drei Tage vor Ablauf des Testzeitraums. Mit diesem Webhook-Ereignis können Sie Ihre Kund/innen darüber informieren, dass der Testzeitraum in Kürze endet.
Verschieben Sie das Datum auf den 8. Januar. Sie können sehen, dass das Abonnement jetzt den Status paid hat und eine Rechnung über 50 USD erstellt wird.
Verschieben Sie das Datum um einen Zyklus (zum Beispiel auf den 8. Februar bei einem monatlichen Abonnement). Sie können sehen, dass das Abonnement erfolgreich verlängert wurde.

Testzeiträume mit Test-Uhren testen

Webhook-Benachrichtigungen für Abonnements testen

Abonnement-Integrationen beruhen in hohem Maße auf Webhooks. Sie richten einen Webhook-Endpoint auf Ihrem Server ein und geben an, welche Ereignisbenachrichtigungen überwacht werden sollen. Stripe sendet Benachrichtigungen für Ereignisse wie ein Upgrade oder eine Kündigung eines Abonnements.

Sie können Webhooks testen, indem Sie entweder tatsächliche Test-Abonnements erstellen oder indem Sie Ereignisbenachrichtigungen durch die Stripe-CLI oder über das Dashboard auslösen.

Nachdem Sie die Stripe-CLI eingerichtet und mit Ihrem Stripe-Konto verknüpft haben, können Sie Ereignisse aus dem Abonnement-Lebenszyklus auslösen, um Ihre Webhook-Integration zu testen. Wenn Sie zum Auslösen von Ereignissen die Stripe-CLI verwenden, können Sie Ereignisbenachrichtigungen auf Ihrem Server sehen, sobald sie eingehen. So können Sie Ihre Webhook-Integration direkt ohne Netzwerktunnel oder Firewalls überprüfen.

Wenn Sie die Stripe-CLI oder das Dashboard zum Auslösen von Ereignissen verwenden, enthält das von Ihrem Webhook empfangene Ereignis falsche Daten, die nicht den Abonnementinformationen entsprechen. Der zuverlässigste Ansatz zum Testen von Webhook-Benachrichtigungen besteht darin, tatsächliche Test-Abonnements zu erstellen und die dazugehörigen Ereignisse zu verarbeiten.

In der folgenden Tabelle werden die häufigsten Ereignisse im Zusammenhang mit Abonnements beschrieben und ggf. Maßnahmen zum Umgang mit den Ereignissen vorgeschlagen.



`customer.created`	Wird gesendet, wenn eine Kundin/ein Kunde erfolgreich erstellt wird.
`customer.subscription.created`	Wird beim Erstellen des Abonnements gesendet. Der `status` des Abonnements kann `incomplete` lauten, wenn zum Abschließen der Zahlung eine Kundenauthentifizierung erforderlich ist oder wenn Sie `payment_behavior` auf `default_incomplete` festlegen. Zeigen Sie das Zahlungsverhalten für Abonnements an, um mehr zu erfahren.
`customer.subscription.deleted`	Wird gesendet, wenn das Abonnement eines/einer Kund/in endet.
`customer.subscription.paused`	Wird gesendet, wenn sich der `status` eines Abonnements in `paused` ändert. Dies wird beispielsweise gesendet, wenn ein Abonnement so konfiguriert wird, dass es pausiert wird, wenn ein kostenloser Testzeitraum ohne Zahlungsmethode endet. Das Invoicing erfolgt erst nach der Wiederaufnahme des Abonnements. Wir senden dieses Ereignis nicht, wenn der Zahlungseinzug angehalten wird, da in diesem Zeitraum weiterhin Rechnungen erstellt werden.
`customer.subscription.resumed`	Wird gesendet, wenn ein Abonnement, das sich zuvor im Status `paused` befand, wieder aufgenommen wird. Dies gilt nicht, wenn die Pause des Zahlungseinzugs aufgehoben wurde.
`customer.subscription.trial_will_end`	Wird drei Tage vor Ablauf des Testzeitraums gesendet. Wenn der Testzeitraum kürzer als drei Tage ist, wird dieses Ereignis ausgelöst.
`customer.subscription.updated`	Wird gesendet, wenn ein Abonnement gestartet oder geändert wird. So lösen beispielsweise das Erneuern des Abonnements, das Hinzufügen eines Gutscheins, das Anwenden eines Rabatts, das Hinzufügen eines Rechnungspostens und das Ändern von Abonnementplänen alle dieses Ereignis aus.
`entitlements.active_entitlement_summary.updated`	Wird gesendet, wenn die aktiven Berechtigungen einer Kundin/eines Kunden aktualisiert werden. Wenn Sie dieses Ereignis erhalten, können Sie den Zugriff auf die Funktionen Ihres Produkts gewähren oder deaktivieren. Mehr erfahren über die Integration mit Berechtigungen.
`invoice.created`	Wird gesendet, wenn eine Rechnung für ein neues oder verlängertes Abonnement erstellt wird. Wenn Stripe keine erfolgreiche Antwort auf `invoice.created` erhält, verzögert sich die Finalisierung aller Rechnungen mit dem automatischen Einzug um bis zu 72 Stunden. Erfahren Sie mehr über das Finalisieren von Rechnungen. Antworten Sie auf die Benachrichtigung, indem Sie eine Anfrage an die API zur Finalisierung einer Rechnung senden.
`invoice.finalized`	Wird gesendet, wenn eine Rechnung erfolgreich finalisiert wurde und bereit für die Bezahlung ist. Sie können die Rechnung an den Kunden/die Kundin senden. Sehen Sie sich die Finalisierung der Rechnung an, um mehr zu erfahren. Je nach Ihren Einstellungen belasten wir automatisch die Standard-Zahlungsmethode oder versuchen den Einzug. Zeigen Sie E-Mails nach der Finalisierung an, um mehr zu erfahren.
`invoice.finalization_failed`	Die Rechnung konnte nicht finalisiert werden. Erfahren Sie in diesem Leitfaden, wie Sie mit Fehlern bei der Rechnungsfinalisierung umgehen. Erfahren Sie im Leitfaden mit der Übersicht zu Rechnungen mehr über die Rechnungsfinalisierung. Überprüfen Sie den last_finalization_error der Rechnung, um die Ursache des Fehlers zu ermitteln. Wenn Sie Stripe Tax verwenden, überprüfen Sie das Feld automatic_tax des Invoice-Objekts. Wenn `automatic_tax[status]=requires_location_inputs` kann die Rechnung nicht finalisiert werden, und Zahlungen können nicht eingezogen werden. Benachrichtigen Sie Ihre/n Kund/in und erfassen Sie den erforderlichen Kundenstandort. Wenn `automatic_tax[status]=failed` wiederholen Sie die Anfrage später noch einmal.
`invoice.paid`	Wird gesendet, wenn die Rechnung erfolgreich bezahlt wird. Sie können den Zugriff auf Ihr Produkt gewähren, wenn Sie dieses Ereignis erhalten und der `status` des Abonnements `active` ist.
`invoice.payment_action_required`	Wird gesendet, wenn die Rechnung eine Kundenauthentifizierung erfordert. Erfahren Sie, wie Sie mit dem Abonnement umgehen, wenn die Rechnung Maßnahmen erfordert.
`invoice.payment_failed`	Eine Zahlung für eine Rechnung ist fehlgeschlagen. Der PaymentIntent-Status ändert sich in `requires_action`. Der Status des Abonnements ist weiterhin `incomplete` nur für die erste Rechnung des Abonnements. Wenn eine Zahlung fehlschlägt, gibt es zahlreiche Aktionen, die durchgeführt werden können: Benachrichtigen Sie den/die Kund/in. Erfahren Sie, wie Sie Abonnementeinstellungen konfigurieren können, um Smart Retries und andere Funktionen zur Umsatzsicherung zu aktivieren. Wenn Sie PaymentIntents verwenden, erfassen Sie neue Zahlungsinformationen und bestätigen Sie den PaymentIntent. Aktualisieren Sie die Standard-Zahlungsmethode für das Abonnement.
`invoice.upcoming`	Wird ein paar Tage vor der Verlängerung des Abonnements gesendet. Die Anzahl der Tage basiert auf der im Dashboard festgelegten Anzahl für Bevorstehende Verlängerungsereignisse. Bei bestehenden Abonnements wird die Änderung der Anzahl der Tage im nächsten Abrechnungszeitraum wirksam. Sie können bei Bedarf noch zusätzliche Rechnungsposten hinzufügen.
`invoice.updated`	Wird gesendet, wenn eine Zahlung erfolgreich ist oder fehlschlägt. Wenn die Zahlung erfolgreich ist, wird das Attribut `paid` auf `true` festgelegt und der `status` ist `paid`. Wenn die Zahlung fehlschlägt, wird das Attribut `paid` auf `false` festgelegt und der `status` bleibt `open`. Fehlgeschlagene Zahlungen lösen außerdem das Ereignis `invoice.payment_failed` aus.
`payment_intent.created`	Wird gesendet, wenn ein PaymentIntent erstellt wird.
`payment_intent.succeeded`	Wird gesendet, wenn die Zahlung für einen PaymentIntent erfolgreich abgeschlossen wurde.
`subscription_schedule.aborted`	Wird gesendet, wenn ein Abonnementplan storniert wurde, weil das zugehörige Abonnement aufgrund von Zahlungsverzug gekündigt wurde.
`subscription_schedule.canceled`	Wird gesendet, wenn ein Abonnementplan gekündigt wird, wodurch auch alle aktiven zugehörigen Abonnements gekündigt werden.
`subscription_schedule.completed`	Wird gesendet, wenn alle Phasen eines Abonnementplans abgeschlossen sind.
`subscription_schedule.created`	Wird gesendet, wenn ein neuer Abonnementplan erstellt wird.
`subscription_schedule.expiring`	Wird 7 Tage vor Ablauf eines Abonnementplans gesendet.
`subscription_schedule.released`	Wird gesendet, wenn ein Abonnementplan freigegeben wird oder beendet und von dem verbleibenden Abonnement getrennt wird.
`subscription_schedule.updated`	Wird gesendet, wenn ein Abonnementplan aktualisiert wird.

Fehlgeschlagene Zahlungen testen

Verwenden Sie entsprechende Testkreditkartennummern, um fehlgeschlagene Zahlungen für Abonnements und Rechnungen auszulösen.

Einige Abonnement-Updates veranlassen Stripe, das Abonnement in Rechnung zu stellen und einen sofortigen Zahlungsversuch zu unternehmen (dieser synchrone Zahlungsversuch kann bei der ersten Rechnung oder bei bestimmten Rechnungs-Updates erfolgen). Schlägt dieser Versuch fehl, wird das Abonnement im Status incomplete erstellt.

Um die Auswirkungen fehlgeschlagener Zahlungen auf ein aktives Abonnement zu testen, hängen Sie die Karte 4000 0000 0000 0341 als Standardzahlungsmethode der Kundin/des Kunden an. Verwenden Sie dabei aber einen Testzeitraum, um den Zahlungsversuch zu verzögern (einige Sekunden oder Minuten reichen aus). Das Abonnement wird sofort aktiv, wobei ein Rechnungsentwurf erstellt wird, wenn der Testzeitraum endet. Es dauert ca. eine Stunde, bis sich der Rechnungsstatus in „offen“ ändert und versucht wird, die Zahlung einzuziehen, was fehlschlägt.

Verwenden Sie Test-Uhren, um den zeitlichen Ablauf in einer Sandbox zu simulieren, wodurch Abrechnungsressourcen wie Abonnements ihren Status ändern und Webhook-Ereignisse auslösen. Auf diese Weise können Sie sehen, wie Ihre Integration mit einer fehlgeschlagenen Zahlung für eine vierteljährliche oder jährliche Verlängerung umgeht, ohne ein Jahr warten zu müssen.

Zahlungen testen, die 3D Secure erfordern

Verwenden Sie die Karte 4000 0027 6000 3184, um die 3D Secure-Auslösung für Abonnements und Rechnungen zu simulieren.

Wenn ein 3D-Secure Authentifizierungsvorgang ausgelöst wird, können Sie in dem sich öffnenden 3DS-Dialogfeld die Authentifizierung oder das Fehlschlagen des Zahlungsversuchs testen. Wenn die Zahlung erfolgreich authentifiziert wird, ist die Rechnung bezahlt. Gehört die Rechnung zu einem Abonnement mit dem Status incomplete, wird das Abonnement aktiv. Wenn der Zahlungsversuch fehlschlägt, ist der Authentifizierungsversuch nicht erfolgreich und die Rechnung verbleibt im Status open.

Zahlungen per Banküberweisung für Rechnungen testen

So testen Sie manuelle Zahlungen für Rechnungen per Banküberweisung:

Erstellen Sie in einer Sandbox eine Rechnung und legen Sie die Einzugsmethode auf send_invoice und das Array payment_settings[payment_method_types] auf [customer_balance] fest.
Suchen Sie die Rechnung im Dashboard und klicken Sie auf Senden.
Ihren Kundinnen und Kunden wird jeweils eine eindeutige virtuelle Bankkontonummer zugewiesen. Diese können Sie über die Funding Instructions API abrufen. Außerdem sind die virtuellen Bankdaten sind auf der gehosteten Rechnungsseite sowie der PDF enthalten.

Die Standard-Zahlungsmethode für Rechnungen und Abonnements testen

Verwenden Sie bestimmte Testkarten-IDs, um Standardzahlungsmethoden zu simulieren, die für Abonnements und Rechnungen verwendet werden.

Die angegebene Zahlungsmethode muss an den Kunden/die Kundin des Abonnements oder der Rechnung angehängt werden, wodurch sie als default_payment method festgelegt wird. Wenn Sie beispielsweise pm_card_visa verwenden, um eine Test-Visa-Zahlungsmethode zu erstellen:

Rufen Sie den Endpoint PaymentMethod Attach mit pm_card_visa und dem/der vorgesehenen Kunden/Kundin für das Abonnement oder die Rechnung auf
Erstellen Sie mit der resultierenden Zahlungsmethoden-ID das Abonnement oder die Rechnung mit dieser ID als default_payment_method.

Jetzt wird diese Zahlungsmethode durch das Abonnement oder die Rechnung belastet.

Erfahren Sie mehr über die Verwendung von Standard-Zahlungsmethoden für Abonnements und Rechnungen.

Verifizierung der Steuer-ID des/der Kund/in testen

Verwenden Sie diese magischen Steuer-IDs, um bestimmte Verifizierungsbedingungen in Testumgebungen auszulösen. Die Steuer-ID muss entweder die EU-USt.-Identifikationsnummer oder die Australian Business Number (ABN) sein.

Nummer	Typ
`000000000`	Verifizierung erfolgreich
`111111111`	Verifizierung nicht erfolgreich
`222222222`	Verifizierung bleibt bis aus Weiteres ausstehend

Automatisierte Tests

Sie können automatisierte Tests für Ihre Integration einrichten. So optimieren Sie die Tests:

Beachten Sie die Richtlinie zur Datenaufbewahrung für abonnementbezogene Daten in einer Sandbox.
Vermeiden Sie die Wiederverwendung von Ressourcen wie Gutscheinen und Promo-Codes für verschiedene Tests.
Verwenden Sie den HTTP-Server stripe-mock, der auf der Stripe API basiert und das Verhalten der API genau widerspiegelt.