Vue d’ensemble
Les abonnements à la demande vous permettent d’autoriser une méthode de paiement d’un client une fois, puis de facturer des montants variables chaque fois que vous en avez besoin, au lieu de suivre un calendrier fixe. Cette fonctionnalité est disponible pour tous les comptes—aucune approbation requise. Utilisez ce guide pour :- Créer un abonnement à la demande (autoriser un mandat avec un prix initial optionnel)
- Déclencher des charges ultérieures avec des montants personnalisés
- Suivre les résultats à l’aide de webhooks
Prérequis
- Compte marchand Dodo Payments et clé API
- Secret de webhook configuré et un point de terminaison pour recevoir des événements
- Un produit d’abonnement dans votre catalogue
Comment fonctionne la demande
- Vous créez un abonnement avec l’objet
on_demandpour autoriser une méthode de paiement et éventuellement collecter une charge initiale. - Plus tard, vous créez des charges contre cet abonnement avec des montants personnalisés en utilisant le point de terminaison de charge dédié.
- Vous écoutez les webhooks (par exemple,
payment.succeeded,payment.failed) pour mettre à jour votre système.
Créer un abonnement à la demande
Point de terminaison : POST /checkouts Champs de requête clés (corps) :Veuillez les trouver dans Créer une session de paiement
Créer un abonnement à la demande
- Node.js SDK
- Python SDK
- Go SDK
- cURL
Success
Facturer un abonnement à la demande
Après que le mandat a été autorisé, créez des charges selon vos besoins. Point de terminaison : POST /subscriptions/{subscription_id}/charge Champs de requête clés (corps) :Paramètres du corps de la requête de charge
Paramètres du corps de la requête de charge
Montant à facturer (dans la plus petite unité monétaire). Exemple : pour facturer 25,00 $, passez
2500.Surcharge de devise optionnelle pour la charge.
Surcharge de description optionnelle pour cette charge.
Si vrai, inclut les frais de devise adaptatifs dans
product_price. Si faux, les frais sont ajoutés en plus.Métadonnées supplémentaires pour le paiement. Si omis, les métadonnées de l’abonnement sont utilisées.
- Node.js SDK
- Python SDK
- Go SDK
- cURL
Success
Réessayer les paiements
Notre système de détection de fraude peut bloquer des modèles de réessai agressifs (et peut les signaler comme des tests de carte potentiels). Suivez une politique de réessai sûre.Principes pour des politiques de réessai sûres
- Mécanisme de retour en arrière : Utilisez un retour en arrière exponentiel entre les réessais.
- Limites de réessai : Limitez le nombre total de réessais (3 à 4 tentatives maximum).
- Filtrage intelligent : Réessayez uniquement en cas d’échecs réessayables (par exemple, erreurs réseau/émetteur, fonds insuffisants) ; ne réessayez jamais les refus fermes.
- Prévention des tests de carte : Ne réessayez pas les échecs tels que
DO_NOT_HONOR,STOLEN_CARD,LOST_CARD,PICKUP_CARD,FRAUDULENT,AUTHENTICATION_FAILURE. - Varier les métadonnées (optionnel) : Si vous maintenez votre propre système de réessai, différenciez les réessais via des métadonnées (par exemple,
retry_attempt).
Calendrier de réessai suggéré (abonnements)
- 1ère tentative : Immédiate lors de la création de la charge
- 2ème tentative : Après 3 jours
- 3ème tentative : Après 7 jours supplémentaires (10 jours au total)
- 4ème tentative (finale) : Après 7 jours supplémentaires (17 jours au total)
Évitez les réessais en rafale ; alignez-vous sur l’heure d’autorisation
- Ancrez les réessais à l’horodatage d’autorisation original pour éviter un comportement de “rafale” dans votre portefeuille.
- Exemple : Si le client commence un essai ou un mandat à 13h10 aujourd’hui, planifiez les réessais de suivi à 13h10 les jours suivants selon votre retour en arrière (par exemple, +3 jours → 13h10, +7 jours → 13h10).
- Alternativement, si vous stockez l’heure du dernier paiement réussi
T, planifiez la prochaine tentative àT + X dayspour préserver l’alignement de l’heure de la journée.
Fuseau horaire et DST : utilisez une norme horaire cohérente pour la planification et convertissez uniquement pour l’affichage afin de maintenir les intervalles.
Codes de refus que vous ne devriez pas réessayer
STOLEN_CARDDO_NOT_HONORFRAUDULENTPICKUP_CARDAUTHENTICATION_FAILURELOST_CARD
Pour une liste complète des raisons de refus et si elles peuvent être corrigées par l’utilisateur, consultez la documentation sur les
Échecs de transaction.
Directives de mise en œuvre (sans code)
- Utilisez un planificateur/une file d’attente qui persiste des horodatages précis ; calculez la prochaine tentative à l’heure exacte de décalage (par exemple,
T + 3 daysà la même HH:MM). - Maintenez et référencez l’horodatage du dernier paiement réussi
Tpour calculer la prochaine tentative ; ne regroupez pas plusieurs abonnements au même instant. - Évaluez toujours la dernière raison de refus ; arrêtez les réessais pour les refus fermes dans la liste à ignorer ci-dessus.
- Limitez les réessais simultanés par client et par compte pour éviter des pics accidentels.
- Communiquez de manière proactive : envoyez un e-mail/SMS au client pour mettre à jour sa méthode de paiement avant la prochaine tentative prévue.
- Utilisez les métadonnées uniquement pour l’observabilité (par exemple,
retry_attempt) ; n’essayez jamais de “contourner” les systèmes de fraude/de risque en faisant tourner des champs sans conséquence.
Suivre les résultats avec des webhooks
Implémentez la gestion des webhooks pour suivre le parcours du client. Voir Implémentation des webhooks.- subscription.active : Mandat autorisé et abonnement activé
- subscription.failed : Échec de la création (par exemple, échec du mandat)
- subscription.on_hold : Abonnement mis en attente (par exemple, état impayé)
- payment.succeeded : Charge réussie
- payment.failed : Échec de la charge
Tests et prochaines étapes
Créer en mode test
Utilisez votre clé API de test pour créer l’abonnement avec
payment_link: true, puis ouvrez le lien et complétez le mandat.Déclencher une charge
Appelez le point de terminaison de charge avec un petit
product_price (par exemple, 100) et vérifiez que vous recevez payment.succeeded.Dépannage
- 422 Requête invalide : Assurez-vous que
on_demand.mandate_onlyest fourni lors de la création et queproduct_priceest fourni pour les charges. - Erreurs de devise : Si vous surchargez
product_currency, confirmez qu’elle est prise en charge pour votre compte et votre client. - Aucun webhook reçu : Vérifiez votre URL de webhook et la configuration du secret de signature.