Übersicht
On-Demand-Abonnements ermöglichen es Ihnen, die Zahlungsmethode eines Kunden einmal zu autorisieren und dann variable Beträge zu berechnen, wann immer Sie es benötigen, anstatt nach einem festen Zeitplan.Diese Funktion muss möglicherweise in Ihrem Konto aktiviert werden. Kontaktieren Sie den Support, wenn Sie sie nicht in Ihrem Dashboard sehen.
- Ein On-Demand-Abonnement zu erstellen (ein Mandat mit optionalem Anfangspreis autorisieren)
- Nachfolgende Gebühren mit benutzerdefinierten Beträgen auszulösen
- Ergebnisse mithilfe von Webhooks zu verfolgen
Voraussetzungen
- Dodo Payments-Händlerkonto und API-Schlüssel
- Webhook-Geheimnis konfiguriert und einen Endpunkt zum Empfangen von Ereignissen
- Ein Abonnementprodukt in Ihrem Katalog
Wie On-Demand funktioniert
- Sie erstellen ein Abonnement mit dem
on_demandObjekt, um eine Zahlungsmethode zu autorisieren und optional eine Anfangsgebühr zu erheben. - Später erstellen Sie Gebühren gegen dieses Abonnement mit benutzerdefinierten Beträgen über den speziellen Gebührenendpunkt.
- Sie hören Webhooks (z. B.
payment.succeeded,payment.failed) ab, um Ihr System zu aktualisieren.
Erstellen Sie ein On-Demand-Abonnement
Endpunkt: POST /subscriptions Wichtige Anforderungsfelder (Body):Anforderungs-Body-Parameter
Anforderungs-Body-Parameter
Produkt-ID für das Abonnement.
Anzahl der Einheiten. Mindestens 1.
Rechnungsadresse des Kunden.
Entweder einen bestehenden Kunden anhängen oder Kundendetails angeben.
Wenn wahr, wird ein gehosteter Kassenlink zur Autorisierung des Mandats und optionalen Anfangszahlung erstellt.
Wohin der Kunde nach Abschluss der gehosteten Kasse umgeleitet werden soll.
Wenn wahr, autorisiert die Zahlungsmethode, ohne den Kunden während der Erstellung zu belasten.
Anfangsgebühr (in der kleinsten Währungseinheit). Wenn angegeben, überschreibt dieser Wert den ursprünglichen Preis des Produkts, der bei der Erstellung des Produkts festgelegt wurde. Wenn weggelassen, wird der gespeicherte Preis des Produkts verwendet. Beispiel: Um $1,00 zu berechnen, übergeben Sie
100.Optionale Währungsüberschreibung für die Anfangsgebühr. Standardmäßig die Produktwährung.
Optionale Beschreibungsüberschreibung für Rechnungs- und Positionen.
Wenn wahr, werden adaptive Währungsgebühren innerhalb von
product_price einbezogen. Wenn falsch, werden Gebühren zusätzlich hinzugefügt. Wird ignoriert, wenn adaptive Preisgestaltung deaktiviert ist.Erstellen Sie ein On-Demand-Abonnement
- Node.js SDK
- Python SDK
- Go SDK
- cURL
Setzen Sie
payment_link: true, leiten Sie den Kunden zu payment_link weiter, um die Mandatsautorisierung abzuschließen.Success
Belasten Sie ein On-Demand-Abonnement
Nachdem das Mandat autorisiert wurde, erstellen Sie nach Bedarf Gebühren. Endpunkt: POST /subscriptions/{subscription_id}/charge Wichtige Anforderungsfelder (Body):Gebührenanforderungs-Body-Parameter
Gebührenanforderungs-Body-Parameter
Betrag, der berechnet werden soll (in der kleinsten Währungseinheit). Beispiel: Um $25,00 zu berechnen, übergeben Sie
2500.Optionale Währungsüberschreibung für die Gebühr.
Optionale Beschreibungsüberschreibung für diese Gebühr.
Wenn wahr, werden adaptive Währungsgebühren innerhalb von
product_price einbezogen. Wenn falsch, werden Gebühren zusätzlich hinzugefügt.Zusätzliche Metadaten für die Zahlung. Wenn weggelassen, werden die Abonnementmetadaten verwendet.
- Node.js SDK
- Python SDK
- Go SDK
- cURL
Success
Zahlungswiederholungen
Unser Betrugserkennungssystem kann aggressive Wiederholungsmuster blockieren (und sie als potenzielles Kartentesten kennzeichnen). Befolgen Sie eine sichere Wiederholungsrichtlinie.Grundsätze für sichere Wiederholungsrichtlinien
- Backoff-Mechanismus: Verwenden Sie exponentielles Backoff zwischen den Wiederholungen.
- Wiederholungsgrenzen: Begrenzen Sie die Gesamtzahl der Wiederholungen (maximal 3–4 Versuche).
- Intelligente Filterung: Wiederholen Sie nur bei wiederholbaren Fehlern (z. B. Netzwerk-/Ausstellerfehler, unzureichende Mittel); wiederholen Sie niemals bei harten Ablehnungen.
- Verhinderung von Kartentests: Wiederholen Sie keine Fehler wie
DO_NOT_HONOR,STOLEN_CARD,LOST_CARD,PICKUP_CARD,FRAUDULENT,AUTHENTICATION_FAILURE. - Metadaten variieren (optional): Wenn Sie Ihr eigenes Wiederholungssystem pflegen, unterscheiden Sie Wiederholungen über Metadaten (z. B.
retry_attempt).
Vorgeschlagener Wiederholungszeitplan (Abonnements)
- 1. Versuch: Sofort, wenn Sie die Gebühr erstellen
- 2. Versuch: Nach 3 Tagen
- 3. Versuch: Nach weiteren 7 Tagen (insgesamt 10 Tage)
- 4. Versuch (final): Nach weiteren 7 Tagen (insgesamt 17 Tage)
Vermeiden Sie Burst-Wiederholungen; richten Sie sich nach der Autorisierungszeit aus
- Verankern Sie Wiederholungen an dem ursprünglichen Autorisierungszeitstempel, um „Burst“-Verhalten in Ihrem Portfolio zu vermeiden.
- Beispiel: Wenn der Kunde um 13:10 Uhr heute mit einer Testphase oder einem Mandat beginnt, planen Sie nachfolgende Wiederholungen um 13:10 Uhr an den folgenden Tagen gemäß Ihrem Backoff (z. B. +3 Tage → 13:10 Uhr, +7 Tage → 13:10 Uhr).
- Alternativ, wenn Sie die letzte erfolgreiche Zahlungszeit
Tspeichern, planen Sie den nächsten Versuch umT + X days, um die Zeitabgleichung zu erhalten.
Zeitzone und DST: Verwenden Sie einen konsistenten Zeitstandard für die Planung und konvertieren Sie nur zur Anzeige, um Intervalle aufrechtzuerhalten.
Ablehnungscodes, die Sie nicht wiederholen sollten
STOLEN_CARDDO_NOT_HONORFRAUDULENTPICKUP_CARDAUTHENTICATION_FAILURELOST_CARD
Für eine umfassende Liste von Ablehnungsgründen und ob sie vom Benutzer korrigierbar sind, siehe die
Transaktionsfehler Dokumentation.
Implementierungsrichtlinien (kein Code)
- Verwenden Sie einen Scheduler/Warteschlange, der präzise Zeitstempel speichert; berechnen Sie den nächsten Versuch zum genauen Zeitversatz (z. B.
T + 3 dayszur gleichen HH:MM). - Pflegen und verweisen Sie auf den letzten erfolgreichen Zahlungszeitstempel
T, um den nächsten Versuch zu berechnen; bündeln Sie niemals mehrere Abonnements zur gleichen Zeit. - Bewerten Sie immer den letzten Ablehnungsgrund; stoppen Sie Wiederholungen bei harten Ablehnungen in der obigen Ausnahmeliste.
- Begrenzen Sie gleichzeitige Wiederholungen pro Kunde und pro Konto, um versehentliche Spitzen zu vermeiden.
- Kommunizieren Sie proaktiv: E-Mail/SMS an den Kunden, um seine Zahlungsmethode vor dem nächsten geplanten Versuch zu aktualisieren.
- Verwenden Sie Metadaten nur zur Beobachtbarkeit (z. B.
retry_attempt); versuchen Sie niemals, Betrugs-/Risikosysteme zu „umgehen“, indem Sie unwesentliche Felder rotieren.
Ergebnisse mit Webhooks verfolgen
Implementieren Sie die Webhook-Verarbeitung, um die Kundenreise zu verfolgen. Siehe Implementierung von Webhooks.- subscription.active: Mandat autorisiert und Abonnement aktiviert
- subscription.failed: Erstellung fehlgeschlagen (z. B. Mandatsfehler)
- subscription.on_hold: Abonnement auf Eis gelegt (z. B. unbezahlter Zustand)
- payment.succeeded: Gebühr erfolgreich
- payment.failed: Gebühr fehlgeschlagen
Testen und nächste Schritte
1
Im Testmodus erstellen
Verwenden Sie Ihren Test-API-Schlüssel, um das Abonnement mit
payment_link: true zu erstellen, öffnen Sie dann den Link und schließen Sie das Mandat ab.2
Eine Gebühr auslösen
Rufen Sie den Gebührenendpunkt mit einer kleinen
product_price (z. B. 100) auf und überprüfen Sie, ob Sie payment.succeeded erhalten.3
Live gehen
Wechseln Sie zu Ihrem Live-API-Schlüssel, sobald Sie Ereignisse und interne Statusaktualisierungen validiert haben.
Fehlersuche
- 422 Ungültige Anfrage: Stellen Sie sicher, dass
on_demand.mandate_onlybei der Erstellung angegeben ist undproduct_pricefür Gebühren angegeben ist. - Währungsfehler: Wenn Sie
product_currencyüberschreiben, bestätigen Sie, dass es für Ihr Konto und Ihren Kunden unterstützt wird. - Keine Webhooks empfangen: Überprüfen Sie Ihre Webhook-URL und die Konfiguration des Signaturgeheimnisses.