Ü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 ist für alle Konten verfügbar – keine Genehmigung erforderlich. Verwenden Sie diesen Leitfaden, um:- Ein On-Demand-Abonnement zu erstellen (ein Mandat mit optionalem Anfangspreis zu autorisieren)
- Nachfolgende Zahlungen 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
So funktioniert On-Demand
- Sie erstellen ein Abonnement mit dem
on_demand-Objekt, um eine Zahlungsmethode zu autorisieren und optional eine Anfangsbelastung einzuziehen. - Später lösen Sie Belastungen gegen dieses Abonnement mit benutzerdefinierten Beträgen über den dedizierten Charge-Endpunkt aus.
- Sie hören auf Webhooks (z. B.
payment.succeeded,payment.failed), um Ihr System zu aktualisieren.
Erstellen Sie ein On-Demand-Abonnement
Endpunkt: POST /checkouts Wichtige Anforderungsfelder (Body):Bitte finden Sie diese in Checkout-Session erstellen
Erstellen Sie ein On-Demand-Abonnement
- Node.js SDK
- Python SDK
- Go SDK
- cURL
Success
Berechnen Sie ein On-Demand-Abonnement
Nachdem das Mandat autorisiert wurde, erstellen Sie nach Bedarf Zahlungen. Endpunkt: POST /subscriptions/{subscription_id}/charge Wichtige Anforderungsfelder (Body):Charge request body parameters
Charge request body parameters
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 Belastung.
Optionale Beschreibung für diese Belastung.
Ist dies auf true gesetzt, werden adaptive Währungsgebühren innerhalb von
product_price eingeschlossen. Andernfalls werden die Gebühren oben drauf gerechnet.Zusätzliche Metadaten für die Zahlung. Wenn weggelassen, werden die Abonnement-Metadaten verwendet.
- Node.js SDK
- Python SDK
- Go SDK
- cURL
Success
Zahlungswiederholungen
Unser Betrugserkennungssystem kann aggressive Wiederholungsmuster blockieren (und kann sie als potenzielles Kartentesten kennzeichnen). Befolgen Sie eine sichere Wiederholungsrichtlinie.Grundsätze für sichere Wiederholungsrichtlinien
- Backoff-Mechanismus: Verwenden Sie exponentielles Backoff zwischen Wiederholungen.
- Retry-Begrenzung: Beschränken Sie die Gesamtanzahl der Wiederholungen (max. 3–4 Versuche).
- Intelligente Filterung: Wiederholen Sie nur bei retryfähigen Fehlern (z. B. Netzwerk-/Issuer-Fehler, 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 ein eigenes Retry-System pflegen, unterscheiden Sie Wiederholungen über Metadaten (z. B.
retry_attempt).
Vorgeschlagener Wiederholungszeitplan (Abonnements)
- 1. Versuch: Sofort, wenn Sie die Zahlung 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 gebündelte Wiederholungen; richten Sie sich nach der Autorisierungszeit
- Verankern Sie Wiederholungen am ursprünglichen Autorisierungszeitpunkt, um “Burst”-Verhalten in Ihrem Portfolio zu vermeiden.
- Beispiel: Wenn der Kunde heute um 13:10 Uhr eine Testphase oder ein Mandat startet, planen Sie nachfolgende Wiederholungen für 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 den Zeitpunkt der letzten erfolgreichen Zahlung
Tspeichern, planen Sie den nächsten Versuch umT + X days, um die Time-of-Day-Ausrichtung beizubehalten.
Zeitzone und DST: Verwenden Sie einen konsistenten Zeitstandard für die Planung und konvertieren Sie nur zur Anzeige, um Intervalle beizubehalten.
Ablehnungscodes, die Sie nicht wiederholen sollten
STOLEN_CARDDO_NOT_HONORFRAUDULENTPICKUP_CARDAUTHENTICATION_FAILURELOST_CARD
Für eine vollständige Liste von Ablehnungsgründen und der Frage, ob sie vom Nutzer korrigierbar sind, siehe die
Transaction Failures-Dokumentation.
Implementierungsrichtlinien (kein Code)
- Verwenden Sie einen Scheduler/Queue, der präzise Zeitstempel speichert; berechnen Sie den nächsten Versuch genau zum gleichen Tageszeiten-Offset (z. B.
T + 3 dayszur gleichen HH:MM). - Pflegen und verwenden Sie den Zeitstempel der letzten erfolgreichen Zahlung
Tzur Berechnung des nächsten Versuchs; bündeln Sie nicht mehrere Abonnements zum selben Zeitpunkt. - Bewerten Sie immer den letzten Ablehnungsgrund; stoppen Sie Wiederholungen bei harten Ablehnungen aus der oben genannten Ausnahmeliste.
- Begrenzen Sie gleichzeitige Wiederholungen pro Kunde und pro Konto, um unbeabsichtigte Spitzen zu vermeiden.
- Kommunizieren Sie proaktiv: Informieren Sie den Kunden per E-Mail/SMS, dass er seine Zahlungsmethode vor dem nächsten geplanten Versuch aktualisieren soll.
- Verwenden Sie Metadaten nur zur Beobachtbarkeit (z. B.
retry_attempt); versuchen Sie niemals, Betrugs-/Risikosysteme zu “umgehen”, indem Sie belanglose 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 Hold gesetzt (z. B. unbezahlter Zustand)
- payment.succeeded: Zahlung erfolgreich
- payment.failed: Zahlung fehlgeschlagen
Testen und nächste Schritte
Create in test mode
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.Trigger a charge
Rufen Sie den Charge-Endpunkt mit einem kleinen
product_price auf (z. B. 100) und vergewissern Sie sich, dass Sie payment.succeeded erhalten.Fehlersuche
- 422 Invalid Request: Stellen Sie sicher, dass
on_demand.mandate_onlybei der Erstellung undproduct_pricebei Belastungen bereitgestellt wird. - Währungsfehler: Wenn Sie
product_currencyüberschreiben, bestätigen Sie, dass diese Währung für Ihr Konto und Ihren Kunden unterstützt wird. - Keine empfangenen Webhooks: Überprüfen Sie Ihre Webhook-URL und die Konfiguration des Signatur-Geheimnisses.