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 des produits d’abonnement et des produits ponctuels dans une même session de checkout. Cela permet de gérer les frais de configuration, les packs de matériel avec SaaS et des cas d’usage similaires. Consultez Sessions de checkout pour voir des exemples.

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 surviennent. Configurez votre endpoint sous Developer → Webhooks dans le tableau de bord. Pour configurer votre endpoint de 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 — Un renouvellement ou une facturation liée à un changement de forfait 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 facturation 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 son accès jusqu’à past_due_ends_at
  7. subscription.plan_changed — Le forfait a été augmenté, réduit ou modifié
  8. subscription.cancelled — L’abonnement a été annulé
  9. subscription.expired — L’abonnement a atteint la fin de sa période
Il s’agit des événements principaux. Pour obtenir la liste complète, notamment paused, unpaused et update_payment_method, consultez Webhooks d’abonnement.
Utilisez subscription.updated pour recevoir des notifications en temps réel concernant toute modification d’un abonnement et maintenir l’état de votre application synchronisé sans interroger l’API périodiquement.

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 facturation. Attendez-vous à le recevoir dans les 2 à 10 minutes suivant le checkout.
Avec une période d’essai :
  1. Au début de l’essai (checkout) : subscription.active est déclenché une fois le moyen de paiement autorisé. Aucune facturation récurrente n’est encore effectuée. La première facturation réelle est reportée à la fin de l’essai.
  2. À la fin de l’essai : le montant récurrent est facturé 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 débité, toujours avec payment.succeeded. Il contient également le next_billing_date mis à jour.
Chaque fois qu’un montant est effectivement débité 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 du 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 d’un renouvellement ou d’une facturation liée à un changement de forfait. Si votre entreprise prévoit 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 États des abonnements.
  • Lorsqu’un abonnement est suspendu, il ne se renouvelle pas automatiquement tant que le moyen de paiement n’a 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 consulter une procédure complète expliquant comment lire error_code/error_message, déterminer quand réessayer et présenter les échecs aux clients, consultez Gérer les échecs de paiement.

subscription.failed par rapport à 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é.

Gérer 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 dans quels cas 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 facturation automatique du renouvellement échoue en raison de fonds insuffisants, d’une carte expirée ou d’un refus bancaire
  • La facturation liée à un changement de forfait échoue : une facturation immédiate lors d’une augmentation ou d’une réduction de forfait échoue
  • L’autorisation du moyen de paiement échoue : le moyen de paiement ne peut pas être autorisé pour les facturations 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éactiver les abonnements suspendus

Pour réactiver un abonnement à l’état on_hold, utilisez l’API Update Payment Method. Cette opération :
  1. Crée une facturation pour les sommes restantes dues
  2. Génère une facture pour cette facturation
  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 l’ID d’un moyen de paiement existant si le client a enregistré des moyens de paiement :
3

Monitor webhook events

Après avoir mis à jour le moyen de paiement, surveillez les événements de webhook suivants :
  1. payment.succeeded - La facturation des sommes restantes dues a réussi
  2. subscription.active - L’abonnement a été réactivé

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


Modifier les forfaits d’abonnement

Vous pouvez augmenter ou réduire un forfait d’abonnement à l’aide de l’endpoint API de changement de forfait. 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 forfaits d’abonnement, consultez notre documentation de l’API Change Plan.

Options de proratisation

Lors de la modification d’un forfait d’abonnement, vous disposez de quatre options pour gérer la facturation immédiate :

1. prorated_immediately

  • Crédite la portion inutilisée du cycle de facturation actuel, proratisée selon le temps restant. Le crédit couvre le forfait de base, la quantité et les éventuels modules complémentaires
  • Facture ensuite un cycle complet selon le nouveau forfait, la nouvelle quantité et les nouveaux modules complémentaires. La facturation elle-même n’est jamais proratisée
  • Facturation 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 bascule immédiatement l’utilisateur vers le nouveau forfait et facture le client immédiatement

2. full_immediately

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

3. difference_immediately

  • Le client paie uniquement la différence entre le prix de l’ancien forfait et celui du nouveau
  • Le montant ne dépend pas du moment du cycle où la modification est effectuée. La même augmentation coûte le même prix au jour 1 et au jour 29
  • En cas d’augmentation, la différence est immédiatement facturée au client. Par exemple, $30/mois → $80/mois = $50 facturés immédiatement
  • En cas de réduction, la différence de prix est conservée comme crédit associé à l’abonnement et appliquée automatiquement aux renouvellements futurs. Par exemple, $50/mois → $20/mois = $30 conservés comme crédit

4. do_not_bill

  • Applique immédiatement la modification du forfait, mais ne facture rien au moment de la modification. Le nouveau forfait, la nouvelle quantité et les nouveaux modules complémentaires sont utilisables immédiatement
  • Comme aucune facturation n’est effectuée immédiatement, une augmentation permet au client de bénéficier gratuitement du forfait supérieur pendant le reste du cycle actuel. Une réduction 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 forfait, car ils n’ont jamais été facturés. Une modification ultérieure facture intégralement la nouvelle quantité de modules complémentaires
  • Le forfait mis à jour (ainsi que la quantité et les modules complémentaires) est facturé au prochain renouvellement prévu, 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 facturation immédiate.

Comportement

  • Lorsque vous appelez cette API, Dodo Payments lance immédiatement une facturation 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 augmentation ou d’une réduction. Si ce crédit dépasse la facturation du nouveau cycle, le solde est ajouté au crédit de l’abonnement. Ces crédits sont spécifiques à 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éductions, l’excédent est conservé comme crédit associé à l’abonnement, comme avec prorated_immediately
  • L’option full_immediately ignore les calculs de crédit et facture le montant total du nouveau forfait
  • L’option do_not_bill applique immédiatement la modification, mais reporte la facturation à la prochaine date de renouvellement, qui est conservée
Choisir un mode de proratisation :
  • difference_immediately — le client paie la différence de prix. C’est l’option la plus prévisible ; la facturation est identique quel que soit le moment du cycle où la modification est effectuée.
  • prorated_immediately — le client reçoit un crédit correspondant uniquement à la durée inutilisée du cycle actuel. La facturation varie selon le moment du cycle où la modification intervient.
  • full_immediately — le client paie le montant total du nouveau forfait. Aucun crédit pour le cycle précédent.
  • do_not_bill — aucune facturation immédiate. Le nouveau forfait est facturé au prochain renouvellement. C’est le seul mode qui conserve la date de facturation d’origine.

Traitement de la facturation

  • La facturation immédiate lancée lors de la modification du forfait est généralement traitée en moins de 2 minutes
  • Si cette facturation 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 vos clients de manière flexible, et pas uniquement selon une fréquence 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 facturation 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 Session de checkout (POST /checkouts) avec subscription_data.on_demand. Consultez le Guide des abonnements à la demande pour connaître le flux actuel.
Pour facturer un abonnement à la demande : Pour les facturations suivantes, utilisez l’endpoint POST /subscriptions//charge et indiquez le montant à facturer au client pour cette transaction.
Pour consulter un guide complet étape par étape, notamment avec des exemples de requêtes/réponses, des politiques de nouvelle tentative sûres et la gestion des webhooks, consultez le Guide des abonnements à la demande.

Points essentiels à 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 valide pendant un seul cycle, puis passe à expired au lieu de se renouveler. Pour un forfait 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 facturation réussie. Transmettez toujours explicitement billing_currency et billing_address.country lors de la création du checkout. 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 facturation, la devise est fixée pour toute sa durée de vie. Un client qui voyage par la suite ne peut pas la modifier.
Les essais créent une autorisation de $0, et non une facturation. Lorsqu’un abonnement comporte 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 facturation réelle intervient à la fin de l’essai. Dans la liste des paiements, un abonnement en période d’essai gratuite affiche exactement un paiement dont total_amount vaut 0. Un essai payant facture à la place son trial_amount à l’avance.
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 son accès). on_hold = un renouvellement a échoué (récupérable : invitez le client à mettre à jour son moyen de paiement ; les nouvelles tentatives de recouvrement s’appliquent). expired = la période s’est terminée sans renouvellement et ne peut pas être réactivée. Le client doit se réabonner. cancelled = l’abonnement a été 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 Dodo.
Les cartes indiennes utilisent un e-mandat RBI. Le règlement des facturations hors session (renouvellements et facturations liées aux changements de forfait) 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 augmentation dépassant cette limite ne peut donc pas utiliser le mandat existant). Tant qu’une facturation est encore processing, une seconde facturation 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 facturations d’abonnement ont un minimum de $1 (ou l’équivalent dans la devise concernée). Les montants de $0.01–$0.99 sont refusés 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 à la demande mandate_only.

Référence API associée

Create Subscription (Deprecated)

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

Change Subscription Plan

Référence API permettant d’augmenter, de réduire ou de modifier les forfaits d’abonnement avec des options de proratisation

Update Payment Method

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

Patch Subscription

Référence API permettant de mettre à jour les détails et la configuration d’un abonnement
Dernière modification le 26 septembre 2026