So gewinnen Sie fehlgeschlagene Zahlungen in Zuora zurück

Zuora gibt Ihnen viel Kontrolle über den Zahlungseinzug, was auch viele Einstellungen bedeutet, die stimmen müssen. Fehlgeschlagene Zahlungen in Zuora berühren mindestens vier Bereiche: Payment Runs, Retry-Regeln, Benachrichtigungen und die Art, wie Kunden ihre Zahlungsmethode aktualisieren. Dieser Ratgeber geht jeden davon durch und endet mit einem praktischen Plan für das Setup.

Er hält sich an die Dokumentation von Zuora selbst: Payment Runs, Retry-Regeln für Zahlungen konfigurieren, Payment Retry, Configurable Payment Retry, Zahlungsversuche und Retry-Regeln, Standard-Events für Zuora Payments und Wie lasse ich Kunden ihre gespeicherten Zahlungsmethoden ändern? (alle abgerufen im November 2026). Feldnamen können je nach Version Ihres Tenants variieren; prüfen Sie sie daher in Ihren eigenen Einstellungen.

Schritt 1: Payment Runs verstehen

In Zuora läuft der automatische Einzug über Payment Runs. Ein Payment Run zieht offene Rechnungen über elektronische Zahlungsmethoden wie Karten oder ACH ein. Laut der Dokumentation zu Payment Runs:

• Ein Run kann bis zu 200.000 Rechnungen verarbeiten.
• Es gibt Ad-hoc-Runs, die Sie von Hand starten, und wiederkehrende Runs, die täglich, wöchentlich oder monatlich nach Zeitplan laufen.
• Runs ziehen nur von Konten mit aktiviertem Auto-Pay ein. Auto-Pay wird auf jedem Kundenkonto gesetzt; ein Konto ohne es wird also nie von einem Run belastet, und seine Rechnungen bleiben einfach offen.
• Während eine Rechnung von einer Zahlung verarbeitet wird, ist sie gesperrt, und jede andere Zahlung darauf scheitert. Zuora empfiehlt festzulegen, welche Rechnungen über welche Methode eingezogen werden (Payment Run, Payment Page, API), damit sie nicht kollidieren.

Das Erste, was Sie prüfen sollten, wenn „Zuora es nicht erneut versucht“, sind oft gar nicht die Wiederholungen: Es ist, ob das Konto Auto-Pay aktiv und eine elektronische Standard-Zahlungsmethode hat.

Schritt 2: Ihren Wiederholungsmechanismus wählen

Zuora hat zwei Wege, eine fehlgeschlagene elektronische Zahlung erneut zu versuchen. Zuora rät davon ab, beide gleichzeitig zu betreiben.

Retry-Regeln auf Tenant-Ebene

Die eingebauten Regeln, beschrieben in Retry-Regeln für Zahlungen konfigurieren, gelten standardmäßig für fehlgeschlagene Zahlungsverarbeitung, wenn Payment Retry in Ihrem Tenant aktiviert ist. Sie legen fest:

• wie oft eine fehlgeschlagene Zahlungsmethode höchstens hintereinander erneut versucht wird;
• einen Mindestabstand seit dem letzten fehlgeschlagenen Versuch (zum Beispiel mit 8 Stunden: keine automatische Wiederholung, wenn der letzte Fehlschlag weniger als 8 Stunden her ist);
• einen Zeitraum, in dem Zahlungen nicht erneut versucht werden.

Sie können diese pro Zahlungsmethode überschreiben. Diese Regeln sind einfach und vorhersehbar, aber dieselben Regeln gelten für jede Ablehnung, unabhängig vom Grund.

Configurable Payment Retry (CPR)

Configurable Payment Retry ist die flexiblere Option von Zuora. Sie lässt Sie die Wiederholungslogik pro Kundengruppe und pro Antwortcode des Gateways festlegen und Codes Kategorien wie Hard, Medium und Soft Declines zuordnen. Kernpunkte aus der Dokumentation:

Einstellung oder Verhalten	Was Zuora dokumentiert
Wiederholungsfenster	Tage vom Eintritt in die Wiederholung bis zum letzten Versuch, höchstens 90 Tage
Anzahl der Versuche	Höchstens 20; der Payment Run macht den ersten Versuch, CPR den Rest
Smart Retry	Ein optionales Machine-Learning-Modell, das Zeitpunkte anhand von Merkmalen des Abonnenten und der Transaktion wählt
Hard Declines	Eine Option Stop Retry On Hard Declines beendet den Zyklus bei einem Hard Decline
Timing	Versuche laufen stündlich in Batches, Wiederholungen können also nicht häufiger als stündlich sein
Zahlungsmethoden	Nur Kartenzahlungen, keine Lastschriften wie ACH oder SEPA
Regeländerungen	Gelten nur für künftige Versuche; abgeschlossene Zyklen werden nicht neu gestartet

Zwei Verhaltensweisen aus den Best Practices zu CPR übersieht man leicht:

• CPR schaltet Auto-Pay ab, während ein Wiederholungszyklus läuft, damit der reguläre Payment Run die Rechnung nicht erneut belastet. Laut der Seite zu den Auto-Pay-Einstellungen hängt das, was sich ändert, von der Ebene der Wiederholung ab: Auf Rechnungsebene wird nur das Auto-Pay-Flag der Rechnung abgeschaltet; auf Kontoebene wird das Auto-Pay des Kontos abgeschaltet und erst wieder eingeschaltet, wenn die Zahlung eingezogen ist. Zuora empfiehlt die Wiederholung auf Rechnungsebene, die das Konto für künftige Payment Runs berechtigt hält. Eine ältere Seite mit Best Practices beschreibt, dass beide Flags auf false gesetzt werden; prüfen Sie also, welche Ebene Ihr Tenant nutzt.
• Um Wiederholungen sofort zu stoppen (zum Beispiel, weil der Kunde per Überweisung bezahlt hat), beenden Sie den Wiederholungszyklus manuell, was Sie über die CPR-APIs tun können.

Wenn Sie unsicher sind, wie Sie einen Antwortcode einordnen sollen, schlägt Zuora vor, ihn als Soft Decline zuzuordnen und die Ergebnisse zu beobachten. Zuora dokumentiert außerdem einen Weg, Smart Retry gegen Ihre bestehende Logik zu testen, bevor Sie alles umstellen.

Schritt 3: den Kunden informieren, mit Benachrichtigungen und Callouts

Wiederholungen gewinnen vorübergehende Ablehnungen zurück. Abgelaufene, ersetzte oder gesperrte Karten brauchen den Kunden. Zuoras Standard-Events für Zahlungen liefern Ihnen die Anknüpfungspunkte:

• Payment Declined: wird ausgelöst, wenn das Gateway eine elektronische Zahlung ablehnt. Eine Einstellung „Sequence of failed attempt“ steuert, bei welchem aufeinanderfolgenden Fehlschlag die Benachrichtigung ausgelöst wird; sie wird mit NumConsecutiveFailures der Zahlungsmethode verglichen und steht standardmäßig auf 1. Externe Zahlungen lösen diese Benachrichtigungen nicht aus.
• Warnungen zum Kartenablauf: Events 15 und 30 Tage, bevor die Standardkarte abläuft (das Ablaufdatum ist der letzte Tag des Ablaufmonats). Damit können Sie um eine neue Karte bitten, bevor etwas scheitert.
• Payment Method Updated: wird ausgelöst, wenn sich die Standard-Zahlungsmethode ändert, Ihr Signal, die Erinnerungen zu stoppen.

Jede Benachrichtigung kann als E-Mail oder als Callout zugestellt werden, eine HTTP-Anfrage an Ihren Endpoint, konfiguriert in der Definition der Benachrichtigung. Nutzen Sie Callouts, um Ihre eigene App zu aktualisieren (Banner, Zugang) und Nachrichten auszulösen, die Sie außerhalb von Zuora versenden. Zuora Workflow kann ebenfalls auf diese Events reagieren und Vorlagen-E-Mails senden oder externe APIs aufrufen, wenn Sie die Logik lieber in Zuora behalten.

Ein einfacher Plan für Benachrichtigungen:

Auslöser	Nachricht	Kanal
Karte läuft in 30 Tagen ab	„Ihre Karte läuft bald ab, aktualisieren Sie sie hier“	E-Mail
Erste abgelehnte Zahlung	„Ihre Zahlung ist nicht durchgegangen“, mit dem Link zur Aktualisierung	E-Mail und in der App
Dritter Fehlschlag in Folge	Erinnerung mit dem Datum, ab dem der Zugang betroffen ist	E-Mail
Zahlungsmethode aktualisiert	Bestätigung, keine weiteren Erinnerungen	E-Mail

Schritt 4: den Kunden seine Zahlungsmethode aktualisieren lassen

Der Link zur Aktualisierung in diesen E-Mails braucht ein Ziel. Zuora dokumentiert in seinem Leitfaden zum Ändern gespeicherter Zahlungsmethoden drei Wege:

1. Die gehostete Seite für Zahlungsmethoden für Kreditkarten, mit Übergabe der bestehenden Zahlungsmethoden-ID (pmId), damit der Kunde die Kartendaten aktualisieren kann. Das ist der Weg, der Kartendaten von Ihren Servern fernhält; Zuora empfiehlt Payment Pages 2.0 gegenüber dem Umgang mit Kartendaten über die API.
2. Die REST-Operation Update a payment method. Zuoras API-Referenz empfiehlt nachdrücklich Payment Pages 2.0, statt sie direkt aufzurufen, und eine Kartennummer darüber zu senden, bringt Ihre eigenen Systeme in den PCI-Geltungsbereich.
3. Die Zuora-Oberfläche, im Bereich Electronic Payment Methods des Kundenkontos, für Support-Mitarbeiter.

Nachdem eine neue Standard-Zahlungsmethode gespeichert ist, stellen Sie sicher, dass die offene Rechnung tatsächlich eingezogen wird, entweder durch den nächsten Payment Run (prüfen Sie Auto-Pay, das CPR womöglich abgeschaltet hat) oder durch eine sofortige Zahlung. Denken Sie an die Sperre der Rechnung: Lassen Sie nicht eine Payment Page und einen Payment Run gleichzeitig dieselbe Rechnung belasten.

Eine Checkliste zur Rückgewinnung in Zuora

1. Prüfen Sie Auto-Pay auf jedem Konto mit aktivem Abo und bestätigen Sie, dass eine elektronische Standard-Zahlungsmethode existiert.
2. Wählen Sie einen Wiederholungsmechanismus: Tenant-Regeln für Einfachheit, CPR für Logik nach Ablehnungsgrund und Kundengruppen. Nicht beides.
3. Ordnen Sie Antwortcodes in CPR zu und schalten Sie Stop Retry On Hard Declines ein, damit eine gestohlene Karte nicht wochenlang erneut versucht wird.
4. Halten Sie das Wiederholungsfenster kürzer als den Abrechnungszeitraum bei Monatsplänen.
5. Schalten Sie Warnungen zum Kartenablauf nach 30 und 15 Tagen ein und sehen Sie sich den Payment Method Updater an, der bei unterstützten Gateways vor dem Bill Cycle Day die Updater-Dienste von Visa, Mastercard und American Express nach neuen Kartendaten fragt.
6. Richten Sie die Benachrichtigung Payment Declined ein, mit einem Link zu einer gehosteten Zahlungsseite, plus einem Callout an Ihre App.
7. Ziehen Sie nach einer Aktualisierung ein: Bestätigen Sie, dass die Rechnung belastet wird, sobald eine neue Karte gespeichert ist.
8. Prüfen Sie Ablehnungen monatlich nach Antwortcode und Kundengruppe.

Das mit NoChurn umsetzen

Zuora bleibt für Rechnungsstellung, Payment Runs, Wiederholungen und Ihr Gateway zuständig. NoChurn verbindet sich über einen Zuora-OAuth-Client, importiert Konten und Abos, empfängt Zuora-Benachrichtigungen und ergänzt von der KI geschriebene Mahnmails, die Sie vor dem Versand prüfen, mit einem Link zur Aktualisierung der Zahlungsmethode. Außerdem ergänzt es Kündigungsflows mit Gründen, Angeboten (ein Rabatt oder ein Planwechsel auf dem Zuora-Abo) und einer immer sichtbaren Kündigung per Klick, Win-back-Mails an Tag 30, 60 und 90 je nach Kündigungsgrund und einen Churn-Score von 0 bis 100. Streitfälle kommen vom Gateway hinter Zuora; bei Stripe oder Braintree sammelt NoChurn die Belege und entwirft eine Antwort, die Sie prüfen. Siehe NoChurn + Zuora.