Skip to main content
Manual Retry versucht eine fehlgeschlagene Zahlung für die Verlängerung eines Abonnements erneut, wenn Sie dies anfordern – über die Detailseite der Zahlung oder über die API. Dabei wird die für das Abonnement gespeicherte Zahlungsmethode belastet. Der Vorgang läuft unabhängig vom automatischen Zeitplan für Payment Retries.

Was ist ein manueller Wiederholungsversuch?

Wenn eine Zahlung für eine Verlängerung fehlschlägt, wechselt das Abonnement zu on_hold. Wenn Sie Payment Retries aktiviert haben, wird die Belastung nach einem Back-off-Zeitplan erneut versucht. Manchmal wissen Sie, dass die Zahlung jetzt erfolgreich sein wird: Der Kunde hat bestätigt, dass er sein Konto aufgeladen hat, oder Ihr Support-Team telefoniert gerade mit ihm. Manual Retry startet sofort einen Versuch, statt Stunden oder Tage auf den nächsten geplanten Versuch zu warten.
  • Nur Zahlungen für Verlängerungen: Manual Retry gilt für Rechnungen zur Verlängerung eines Abonnements, solange sich das Abonnement im Status on_hold befindet. Erstzahlungen, einmalige Zahlungen, Belastungen aufgrund von Planänderungen und On-Demand-Belastungen sind nicht zulässig.
  • Keine Aktion des Kunden erforderlich: Die Belastung erfolgt über die bereits für das Abonnement gespeicherte Zahlungsmethode.
  • Unabhängig von automatischen Retries: Ein manueller Retry verbraucht keinen Versuch aus dem automatischen Zeitplan, verschiebt den nächsten geplanten Retry nicht und funktioniert auch dann, wenn Payment Retries deaktiviert sind.
  • Die Rechnung wird erneut versucht, nicht die Zahlung: Die fehlgeschlagene Zahlung dient nur als Ausgangspunkt. Dodo Payments ermittelt die offene Rechnung zur Verlängerung und belastet den ausstehenden Betrag. Daher spielt es keine Rolle, über welche fehlgeschlagene Zahlung der Rechnung Sie den Retry starten.

Wiederholung über das Dashboard

Nur Benutzer mit der Rolle Owner oder Editor können einen manuellen Retry senden.
1

Open the failed payment

Gehen Sie zu Transactions → Payments und klicken Sie auf die fehlgeschlagene Zahlung für die Verlängerung, um die Seite Transaction details zu öffnen.
2

Click Retry Payment Manually

Klicken Sie oben rechts auf Retry Payment Manually. Die Schaltfläche ist nur verfügbar, solange die Zahlung eligible ist.
3

Check the result

Dodo Payments erstellt für den Versuch eine neue Zahlung, die im Activity Log erscheint. Wenn die Belastung erfolgreich ist, wechselt das Abonnement zurück zu active, und das nächste Abrechnungsdatum wird auf einen Abrechnungszeitraum nach dem erfolgreichen Retry verschoben. Wenn der Payment Processor die Belastung noch nicht abgerechnet hat, wird die Zahlung als in Bearbeitung angezeigt, bis der Webhook payment.succeeded oder payment.failed das Ergebnis meldet.
Seite mit Transaktionsdetails für eine fehlgeschlagene Zahlung mit Fehlercode und Fehlermeldung, einem Activity Log und einer Schaltfläche zum manuellen Wiederholen der Zahlung

Retry Payment Manually on the transaction details page of a failed renewal

Eligibility

Dodo Payments sendet einen manuellen Retry nur, wenn jede Prüfung in dieser Tabelle erfolgreich ist. Die Spalte Reason code enthält den von der API zurückgegebenen Wert: in reason auf GET /payments/{payment_id}/retry und als Fehler code auf POST /payments/{payment_id}/retry.
Manual Retry ist an einer Stelle restriktiver als automatische Retries: Das Abonnement muss sich im Status on_hold befinden. Ein past_due-Abonnement in einer Kulanzfrist besteht diese Prüfung nicht. Automatische Retries werden für andere nicht aktive Status weiterhin ausgeführt. Siehe Subscription Status Transitions.
Ein erneuter Versuch mit derselben Karte nach einer harten Ablehnung kann nicht erfolgreich sein, und wiederholte Ablehnungen beeinträchtigen Ihre Autorisierungsrate. Wenn der Grund MANUAL_RETRY_HARD_DECLINE lautet, bitten Sie den Kunden stattdessen, seine Zahlungsmethode zu aktualisieren. Subscription Dunning erledigt dies automatisch.

Retry Limits

Jede Rechnung für eine Verlängerung erlaubt 3 manuelle Retries mit einer Abkühlzeit dazwischen: Die Limits gelten sowohl im Testmodus als auch im Live-Modus. Wenn das Limit einen Retry ablehnt, gibt die API MANUAL_RETRY_LIMIT_REACHED (HTTP 429) zurück; der Fehler-Body enthält nur code und message. Um zu erfahren, wann der nächste Retry möglich ist, prüfen Sie den Retry-Status und lesen Sie retry_available_at. Der Wert ist null, sobald alle drei Retries verbraucht sind. Automatische Retries werden nicht auf dieses Limit angerechnet, und manuelle Retries zählen nicht zu den 8 Versuchen des automatischen Zeitplans.

Manuelle und automatische Retries

Die beiden Retry-Pfade unterscheiden sich in folgenden Punkten:

Retries über die API

Prüfen Sie zuerst die Berechtigung und senden Sie anschließend den Retry. Beide Endpoints erwarten die ID einer fehlgeschlagenen Zahlung.

Prüfen, ob eine Zahlung erneut versucht werden kann

GET /payments/{payment_id}/retry gibt bei einer nicht zulässigen Zahlung keinen Fehler zurück. Stattdessen wird can_retry: false mit dem Code reason zurückgegeben, sodass Ihr eigenes Dashboard oder Support-Tool denselben Status wie das Dodo Payments-Dashboard anzeigen kann. Dafür ist die Rolle Viewer erforderlich.
Response

Manuellen Retry senden

POST /payments/{payment_id}/retry erstellt eine neue Zahlung und belastet die gespeicherte Zahlungsmethode. Dafür ist die Rolle Editor erforderlich. Die SDK-Beispiele verwenden erneut client aus dem vorherigen Beispiel.
Response

Fehlerantworten

Wenn ein Retry nicht zulässig ist, gibt POST einen der folgenden HTTP-Statuscodes zurück: Die Referenz Error Codes beschreibt jeden Code.

Webhooks

Ein manueller Retry erstellt eine gewöhnliche Zahlung. Daher werden dieselben Webhooks wie bei jedem Versuch einer Verlängerungszahlung ausgelöst: Im Payment-Objekt dieser Ereignisse ist retry_attempt 1 oder höher, und subscription_id ist gesetzt – genauso wie bei einem automatischen Retry. Das Payment-Objekt enthält kein Feld, das einen manuellen Versuch kennzeichnet. Bewahren Sie daher payment_id aus der Retry-Antwort auf, wenn Sie einen manuellen Versuch von einem geplanten unterscheiden müssen.

Payment Webhook Payloads

Vollständige Payload-Schemas für Payment-Ereignisse.

Verwandte Themen

Subscription Payment Retries

Der automatische Back-off-Zeitplan, der parallel zu manuellen Retries ausgeführt wird.

Subscription Dunning

Senden Sie dem Kunden eine E-Mail, damit er seine Zahlungsmethode nach einer harten Ablehnung aktualisiert.

Handle Payment Failures

Lesen Sie Ablehnungscodes und entscheiden Sie, wann sich ein Retry lohnt.

Error Codes

Jeder MANUAL_RETRY_*-Code, sein Auslöser und seine Meldung.
Zuletzt geändert am 26. September 2026