Skip to main content

Prérequis

Avant de commencer, vous avez besoin des éléments suivants :
  • Un compte marchand Dodo Payments
  • Une clé API disponible dans Developer → API Keys du tableau de bord, stockée dans DODO_PAYMENTS_API_KEY
  • Un secret de webhook disponible dans Developer → Webhooks, stocké dans DODO_PAYMENTS_WEBHOOK_KEY
  • Au moins un produit d’abonnement créé sous Products
Pour plus de détails, consultez Prérequis du guide d’intégration.

Intégration de l’API

Sessions de checkout

Créez un abonnement en construisant une session de checkout avec votre produit d’abonnement. Le client autorise un moyen de paiement et l’abonnement est activé lorsqu’il termine le checkout.
Vous pouvez combiner un produit d’abonnement avec des produits ponctuels dans la même session de paiement. Cela permet de gérer les frais de configuration, les offres groupées de matériel avec du SaaS et des cas d’utilisation similaires. Consultez Checkout Sessions pour découvrir des exemples.Vous pouvez également vendre deux produits d’abonnement ou plus dans un seul paiement. Le client paie une seule fois et obtient un abonnement indépendant pour chaque produit, chacun ayant son propre cycle de facturation. Un tel panier ne peut pas contenir de produits ponctuels. Consultez Multi-Subscription Cart.

Réponse de l’API

La réponse inclut un checkout_url :
Redirigez le client vers cette URL. Il autorise le moyen de paiement et l’abonnement est activé.

Webhooks

Les Webhooks notifient votre serveur lorsque des événements d’abonnement se produisent. Configurez votre endpoint sous Developer → Webhooks dans le dashboard. Pour configurer votre endpoint webhook, consultez Webhooks.

Types d’événements d’abonnement

Suivez ces événements pour gérer le cycle de vie de l’abonnement :
  1. subscription.active — L’abonnement est activé
  2. subscription.updated — Un champ de l’abonnement a été modifié
  3. subscription.on_hold — Une charge de renouvellement ou de changement de plan a échoué
  4. subscription.failed — La création de l’abonnement a échoué (définitif ; le client doit se réabonner)
  5. subscription.renewed — Une charge récurrente a réussi
  6. subscription.past_due — Un renouvellement a échoué et la période de grâce a commencé ; le client conserve l’accès jusqu’à past_due_ends_at
  7. subscription.plan_changed — Le plan a été mis à niveau, rétrogradé ou modifié
  8. subscription.cancelled — L’abonnement a été annulé
  9. subscription.expired — L’abonnement a atteint la fin de sa durée
Il s’agit des événements principaux. Pour obtenir la liste complète, notamment paused, unpaused et update_payment_method, consultez Subscription Webhooks.
Utilisez subscription.updated pour recevoir en temps réel des notifications concernant toute modification d’abonnement et maintenir l’état de votre application synchronisé sans interroger l’API.

Scénarios de paiement

Flux de paiement réussi La séquence des webhooks dépend de la présence ou non d’une période d’essai pour l’abonnement. Facturation immédiate (0 jour d’essai) :
  1. subscription.active : le mandat est autorisé et l’abonnement est activé.
  2. payment.succeeded : confirme la première charge. Attendez-vous à cet événement dans les 2 à 10 minutes suivant le paiement.
Avec une période d’essai :
  1. Au début de l’essai (paiement) : subscription.active est déclenché une fois le moyen de paiement autorisé. Aucune charge récurrente n’est encore prélevée. La première charge réelle est différée jusqu’à la fin de l’essai.
  2. À la fin de l’essai : le montant récurrent est prélevé et vous recevez payment.succeeded avec subscription.renewed.
Chaque renouvellement suivant :
  • subscription.renewed : est déclenché à chaque cycle de facturation lorsque le paiement du renouvellement est prélevé, toujours avec payment.succeeded. Il contient également le next_billing_date mis à jour.
Chaque fois qu’une somme est réellement prélevée pour un produit d’abonnement, vous recevez subscription.renewed et payment.succeeded. Utilisez subscription.renewed (plutôt que payment.succeeded seul) comme signal pour prolonger l’accès au cycle suivant.
Scénarios d’échec de paiement
  1. Échec de l’abonnement
  • subscription.failed - La création de l’abonnement a échoué, car le mandat n’a pas pu être créé.
  • payment.failed - Indique un paiement échoué.
  1. Abonnement suspendu
  • subscription.on_hold - L’abonnement est suspendu en raison de l’échec du paiement du renouvellement ou de la charge liée à un changement de plan. Si votre entreprise dispose d’une période de grâce, un renouvellement échoué fait d’abord passer l’abonnement à past_due (subscription.past_due), puis à on_hold (ou cancelled, selon la configuration de votre période de grâce) uniquement lorsque celle-ci prend fin. Consultez Subscription States.
  • Lorsqu’un abonnement est suspendu, il ne se renouvellera pas automatiquement tant que le moyen de paiement n’aura pas été mis à jour.
Bonne pratique : pour simplifier l’implémentation, nous vous recommandons de suivre principalement les événements d’abonnement afin de gérer le cycle de vie de l’abonnement.
Pour obtenir une procédure complète expliquant comment lire error_code/error_message, déterminer quand réessayer et signaler les échecs aux clients, consultez Handle Payment Failures.

subscription.failed et subscription.on_hold

Ces deux événements sont faciles à confondre, mais ils nécessitent une gestion très différente :
subscription.failed est définitif. L’abonnement ne peut pas être réactivé. Le client doit créer un nouvel abonnement. N’accordez jamais de droits lorsque cet événement est déclenché.

Gestion d’un abonnement suspendu

Lorsqu’un abonnement passe à l’état on_hold, vous devez mettre à jour le moyen de paiement pour le réactiver. Cette section explique quand les abonnements sont suspendus et comment les gérer.

Quand les abonnements sont suspendus

Un abonnement est suspendu lorsque :
  • Le paiement du renouvellement échoue : la charge de renouvellement automatique échoue en raison de fonds insuffisants, d’une carte expirée ou d’un refus de la banque
  • La charge liée à un changement de plan échoue : une charge immédiate lors de la mise à niveau ou de la rétrogradation du plan échoue
  • L’autorisation du moyen de paiement échoue : le moyen de paiement ne peut pas être autorisé pour les charges récurrentes
Les abonnements à l’état on_hold ne se renouvellent pas automatiquement. Vous devez mettre à jour le moyen de paiement pour réactiver l’abonnement.

Réactivation des abonnements suspendus

Pour réactiver un abonnement à l’état on_hold, utilisez l’API Update Payment Method. Cette opération :
  1. Crée une charge correspondant aux sommes restant dues
  2. Génère une facture pour cette charge
  3. Traite le paiement avec le nouveau moyen de paiement
  4. Réactive l’abonnement à l’état active une fois le paiement réussi
1

Handle subscription.on_hold webhook

Lorsque vous recevez un webhook subscription.on_hold, mettez à jour l’état de votre application et informez le client :
2

Update payment method

Lorsque le client est prêt à mettre à jour son moyen de paiement, appelez l’API Update Payment Method :
Vous pouvez également utiliser un ID de moyen de paiement existant si le client a enregistré des moyens de paiement :
3

Monitor webhook events

Après la mise à jour du moyen de paiement, surveillez les événements webhook suivants :
  1. payment.succeeded - La charge correspondant aux sommes restant dues a réussi
  2. subscription.active - L’abonnement a été réactivé

Exemple de payload d’événement d’abonnement


Modification des plans d’abonnement

Vous pouvez mettre à niveau ou rétrograder un plan d’abonnement à l’aide de l’endpoint change plan API. Cela vous permet de modifier le produit, la quantité et de gérer la proratisation de l’abonnement.

Change Plan API Reference

Pour obtenir des informations détaillées sur la modification des plans d’abonnement, consultez notre documentation Change Plan API.

Options de proratisation

Lors de la modification des plans d’abonnement, vous disposez de quatre options pour gérer la charge immédiate :

1. prorated_immediately

  • Crédite la portion inutilisée du cycle de facturation actuel, au prorata du temps restant. Le crédit couvre le plan de base, la quantité et les éventuels modules complémentaires
  • Puis facture un cycle complet selon le nouveau plan, la nouvelle quantité et les nouveaux modules complémentaires. La charge elle-même n’est jamais proratisée
  • Charge immédiate nette = (nouveau cycle complet) moins (fraction restante x ancien cycle complet). Si le crédit est supérieur, la différence est conservée comme crédit associé à l’abonnement pour les renouvellements futurs
  • Pendant une période d’essai, cette option fait immédiatement passer l’utilisateur au nouveau plan et facture le client sans attendre

2. full_immediately

  • Facture au client le montant total de l’abonnement du nouveau plan, sans crédit pour le cycle précédent
  • Qu’il s’agisse d’une mise à niveau ou d’une rétrogradation, le client paie l’intégralité du prix du nouveau plan à partir de zéro
  • Utile lorsque vous souhaitez facturer le montant total, quelle que soit la durée restante de l’ancien plan

3. difference_immediately

  • Le client paie uniquement la différence entre le prix de l’ancien plan et celui du nouveau plan
  • Le montant ne dépend pas du moment du cycle où la modification est effectuée. La même mise à niveau coûte autant au premier qu’au vingt-neuvième jour
  • Lors d’une mise à niveau, la différence est immédiatement facturée au client. Par exemple, $30/mois → $80/mois = $50 facturés immédiatement
  • Lors d’une rétrogradation, la différence de prix est enregistrée comme crédit associé à l’abonnement et appliquée automatiquement aux futurs renouvellements. Par exemple, $50/mois → $20/mois = $30 enregistrés comme crédit

4. do_not_bill

  • Applique immédiatement la modification du plan, mais ne facture rien au moment de la modification. Le nouveau plan, la nouvelle quantité et les nouveaux modules complémentaires sont utilisables immédiatement
  • Comme rien n’est facturé sur le moment, une mise à niveau offre au client le plan supérieur gratuitement pendant le reste du cycle actuel. Une rétrogradation prend effet immédiatement, sans crédit pour la portion inutilisée du cycle déjà payée
  • Les modules complémentaires accordés via do_not_bill ne sont pas crédités lors d’une modification ultérieure du plan, car ils n’ont jamais été facturés. Une modification ultérieure facture intégralement la nouvelle quantité de modules complémentaires
  • Le plan mis à jour (ainsi que la quantité et les modules complémentaires) est facturé lors du prochain renouvellement planifié, et la date de facturation d’origine est conservée
Les trois modes « facturer maintenant » réinitialisent le cycle de facturation. prorated_immediately, difference_immediately et full_immediately déplacent le next_billing_date de l’abonnement à la date de modification. Seul do_not_bill conserve la date de renouvellement d’origine, mais il n’applique aucune charge immédiate.

Comportement

  • Lorsque vous appelez cette API, Dodo Payments lance immédiatement une charge selon l’option de proratisation sélectionnée
  • Avec prorated_immediately, un crédit correspondant à la portion inutilisée du cycle actuel est calculé à chaque modification, qu’il s’agisse d’une mise à niveau ou d’une rétrogradation. Si ce crédit dépasse la charge du nouveau cycle, le solde est ajouté au crédit de l’abonnement. Ces crédits sont propres à cet abonnement et servent uniquement à compenser les futurs paiements récurrents du même abonnement
  • Avec difference_immediately, le montant net correspond toujours exactement à la différence de prix. Pour les rétrogradations, l’excédent est enregistré comme crédit associé à l’abonnement, comme avec prorated_immediately
  • L’option full_immediately ignore les calculs de crédit et facture l’intégralité du nouveau plan
  • L’option do_not_bill applique immédiatement la modification, mais reporte la facturation à la prochaine date de renouvellement, qui est conservée
Choix du mode de proratisation :
  • difference_immediately — le client paie la différence de prix. Il s’agit de l’option la plus prévisible ; la charge est la même quel que soit le moment du cycle où la modification est effectuée.
  • prorated_immediately — le client reçoit un crédit uniquement pour le temps inutilisé du cycle actuel. La charge varie selon le moment du cycle où la modification est effectuée.
  • full_immediately — le client paie le montant total du nouveau plan. Aucun crédit pour le cycle précédent.
  • do_not_bill — aucune charge immédiate. Le nouveau plan est facturé lors du prochain renouvellement. C’est le seul mode qui conserve la date de facturation d’origine.

Traitement de la charge

  • La charge immédiate lancée lors de la modification du plan termine généralement son traitement en moins de 2 minutes
  • Si cette charge immédiate échoue pour quelque raison que ce soit, l’abonnement est automatiquement suspendu jusqu’à la résolution du problème

Abonnements à la demande

Les abonnements à la demande vous permettent de facturer les clients de manière flexible, et non uniquement selon un calendrier fixe. Cette fonctionnalité est disponible pour tous les comptes.
Pour créer un abonnement à la demande : Pour créer un abonnement à la demande, utilisez l’endpoint API POST /checkouts et incluez le champ subscription_data.on_demand dans le corps de votre requête. Cela vous permet d’autoriser un moyen de paiement sans effectuer de charge immédiate ou de définir un prix initial personnalisé.
POST /subscriptions est obsolète. Il fonctionne toujours pour les intégrations existantes, mais les nouvelles intégrations doivent créer des abonnements à la demande via une Checkout Session (POST /checkouts) avec subscription_data.on_demand. Consultez le On-Demand Subscriptions Guide pour connaître le flux actuel.
Pour facturer un abonnement à la demande : Pour les charges ultérieures, utilisez l’endpoint POST /subscriptions//charge et indiquez le montant à facturer au client pour cette transaction.
Pour consulter un guide complet, étape par étape (avec des exemples de requêtes/réponses, des politiques de nouvelle tentative sécurisées et la gestion des webhooks), consultez le On-Demand Subscriptions Guide.

Points clés à connaître sur la facturation des abonnements

Définissez une période d’abonnement plus longue que la fréquence de paiement. Si la période d’abonnement est égale à la fréquence de paiement (par exemple, période = 1 mois, fréquence = 1 mois), l’abonnement est valable pour un seul cycle, puis passe à expired au lieu de se renouveler. Pour un plan mensuel continu, définissez une longue période d’abonnement (par exemple, 20 ans) avec une fréquence de paiement mensuelle.
La devise est verrouillée lors de la première charge réussie. Transmettez toujours explicitement billing_currency et billing_address.country lors de la création du paiement. S’ils sont omis, ils sont détectés à partir de l’adresse IP du client (Adaptive Currency) et, dès que l’abonnement reçoit sa première charge, la devise est fixée pour toute sa durée de vie. Un client qui voyage ultérieurement ne peut pas la modifier.
Les essais créent une autorisation de $0, et non une charge. Lorsqu’un abonnement comprend une période d’essai, le début de l’essai crée une autorisation de mandat de $0 pour enregistrer la carte ; la première charge réelle intervient à la fin de l’essai. Dans la liste des paiements, un abonnement en essai gratuit affiche exactement un paiement avec total_amount égal à 0. Un essai payant facture à l’avance son trial_amount.
Cycle de vie de l’abonnement : past_due = un renouvellement a échoué et la période de grâce est en cours (le client conserve l’accès). on_hold = un renouvellement a échoué (récupérable : demandez au client de mettre à jour son moyen de paiement ; les nouvelles tentatives de recouvrement s’appliquent). expired = la durée s’est terminée sans renouvellement et ne peut pas être réactivée. Le client doit se réabonner. cancelled = terminé par le client ou le marchand. La plupart des échecs de renouvellement sont des refus du côté de l’émetteur (fonds insuffisants, carte refusée), et non une erreur de Dodo.
Les cartes indiennes utilisent un e-mandat RBI. Le règlement des charges hors session (renouvellements et charges liées aux changements de plan) peut prendre jusqu’à environ 48 heures, et les prélèvements automatiques récurrents supérieurs à ₹15,000 nécessitent une nouvelle authentification du client (une mise à niveau dépassant cette limite ne peut donc pas utiliser le mandat existant). Tant qu’une charge est encore processing, une seconde charge sur le même abonnement échoue avec “Cannot create new charge as previous payment is not successful yet.” Les cartes non indiennes sont confirmées presque instantanément.
Les abonnements ont un minimum de $1.00 en USD. Le paiement rejette un total inférieur avec TOTAL_PAYMENT_AMOUNT_BELOW_MINIMUM_AMOUNT. Les devises autres que USD, EUR et GBP doivent également représenter au moins $1.00 ; consultez Minimum Amounts. Une charge à la demande product_price inférieure à 100 dans la plus petite unité monétaire est rejetée avec product_price: value out of range. Un produit d’abonnement dont le prix est exactement $0 est autorisé ; consultez Card-Optional at Zero Price. Pour autoriser une carte sans la facturer, utilisez une configuration mandate_only à la demande.

Référence API associée

Create Subscription (Deprecated)

API héritée pour créer directement un abonnement. Utilisez Checkout Sessions pour les nouvelles intégrations

Change Subscription Plan

Référence API pour mettre à niveau, rétrograder ou modifier des plans d’abonnement avec des options de proratisation

Update Payment Method

Référence API pour mettre à jour les moyens de paiement et réactiver les abonnements suspendus

Patch Subscription

Référence API pour mettre à jour les détails et la configuration des abonnements
Dernière modification le 8 octobre 2026