Skip to main content

Prerequisites

To integrate the Dodo Payments API, you’ll need:
  • A Dodo Payments merchant account
  • API credentials (API key and webhook secret key) from the dashboard
For a more detailed guide on the prerequisites, check this section.

API Integration

Checkout Sessions

Use Checkout Sessions to sell subscription products with a secure, hosted checkout. Pass your subscription product in product_cart and redirect customers to the returned checkout_url.
Mixed Checkout: You can combine subscription products with one-time products in the same checkout session. This enables use cases like setup fees with subscriptions, hardware bundles with SaaS, and more. See the Checkout Sessions guide for examples.

API Response

The following is an example of the response:
Redirect the customer to checkout_url.

Webhooks

When integrating subscriptions, you’ll receive webhooks to track the subscription lifecycle. These webhooks help you manage subscription states and payment scenarios effectively. To set up your webhook endpoint, please follow our Detailed Integration Guide.

Subscription Event Types

The following webhook events track subscription status changes:
  1. subscription.active - Subscription is successfully activated.
  2. subscription.updated - Subscription object was updated (fires on any field change).
  3. subscription.on_hold - Subscription is put on hold due to failed renewal.
  4. subscription.failed - Subscription creation failed during mandate creation.
  5. subscription.renewed - Subscription is renewed for the next billing period.
For reliable subscription lifecycle management, we recommend tracking these subscription events.
Use subscription.updated to get real-time notifications about any subscription changes, keeping your application state in sync without polling the API.

Payment Scenarios

Les webhooks que vous recevez, ainsi que leur délai, dépendent du fait que le produit inclue ou non une période d’essai. Facturation immédiate (0 jour d’essai) :
  1. subscription.active : le mandat est autorisé et l’abonnement est activé.
  2. payment.succeeded : confirme le premier débit. 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é. Aucun débit récurrent n’est encore effectué. Le premier débit réel est reporté à la fin de l’essai.
  2. À la fin de l’essai : le montant récurrent est débité 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 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 du débit lié à la modification du plan.
  • 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 un guide complet sur la lecture de error_code/error_message, déterminer quand effectuer une nouvelle tentative et présenter les échecs aux clients, consultez Gérer les échecs de paiement.

subscription.failed contre subscription.on_hold

Ces deux événements sont faciles à confondre, mais 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 d’accès 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 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 : le débit automatique du renouvellement échoue en raison de fonds insuffisants, d’une carte expirée ou d’un refus bancaire
  • Le débit lié à la modification du plan échoue : un débit immédiat 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 des débits récurrents
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 un abonnement suspendu

Pour réactiver un abonnement à l’état on_hold, utilisez l’API Update Payment Method. Cette opération :
  1. Crée un débit correspondant aux sommes restantes dues
  2. Génère une facture pour ce débit
  3. Traite le paiement avec le nouveau moyen de paiement
  4. Réactive l’abonnement à l’état active lorsque le paiement est effectué avec succès
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 webhook suivants :
  1. payment.succeeded - Le débit des sommes restantes dues a été effectué avec succès
  2. subscription.active - L’abonnement a été réactivé

Exemple de payload d’événement Subscription


Modifier les 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 et la quantité de l’abonnement, ainsi que de gérer le prorata.

Change Plan API Reference

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

Options de prorata

Lors de la modification des plans d’abonnement, vous disposez de deux options pour gérer le débit immédiat :

1. prorated_immediately

  • Calcule le montant au prorata en fonction du temps restant dans le cycle de facturation actuel
  • Ne facture au client que la différence entre l’ancien et le nouveau plan
  • Pendant une période d’essai, bascule immédiatement l’utilisateur vers le nouveau plan et facture le client immédiatement

2. full_immediately

  • Facture au client le montant total de l’abonnement du nouveau plan
  • Ignore le temps restant ou les crédits du plan précédent
  • Utile lorsque vous souhaitez réinitialiser le cycle de facturation ou facturer le montant total indépendamment du prorata

3. difference_immediately

  • Lors d’une mise à niveau, la différence entre les deux montants des plans est immédiatement facturée au client.
  • Par exemple, si le plan actuel coûte 30 Dollars et que le client passe à un plan de 80 Dollars, il est immédiatement facturé de $50.
  • Lors d’une rétrogradation, le montant inutilisé du plan actuel est ajouté sous forme de crédit interne et automatiquement appliqué aux futurs renouvellements de l’abonnement.
  • Par exemple, si le plan actuel coûte 50 Dollars et que le client passe à un plan de 20 Dollars, les $30 restants sont crédités et utilisés lors du prochain cycle de facturation.

4. do_not_bill

  • Applique immédiatement la modification du plan, mais ne facture rien au moment de la modification.
  • 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 initiale est conservée.
Les trois modes « débiter 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 initiale, mais il n’applique aucun débit immédiat.

Comportement

  • Lorsque vous appelez cette API, Dodo Payments initie immédiatement un débit selon l’option de prorata sélectionnée
  • Si la modification du plan est une rétrogradation et que vous utilisez prorated_immediately, les crédits sont automatiquement calculés et ajoutés au solde de crédits de l’abonnement. Ces crédits sont propres à cet abonnement et ne seront utilisés que pour compenser les futurs paiements récurrents du même abonnement
  • L’option full_immediately ignore le calcul des crédits et facture le montant total du nouveau plan
Choisissez soigneusement votre option de prorata : utilisez prorated_immediately pour une facturation équitable qui tient compte du temps inutilisé, ou full_immediately lorsque vous souhaitez facturer le montant total du nouveau plan indépendamment du cycle de facturation actuel.

Traitement du débit

  • Le débit immédiat initié lors de la modification du plan termine généralement son traitement en moins de 2 minutes
  • Si ce débit immédiat échoue pour quelque raison que ce soit, l’abonnement est automatiquement suspendu jusqu’à la résolution du problème

Abonnements à la demande

Create Subscription

Référence API pour créer des produits d’abonnement et gérer le cycle de vie de l’abonnement

Change Subscription Plan

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

Update Payment Method

Référence API pour mettre à jour les méthodes de paiement et réactiver les abonnements en attente

Patch Subscription

Référence API pour mettre à jour les détails et la configuration de l’abonnement
Pour créer un abonnement à la demande : Pour créer un abonnement à la demande, utilisez l’endpoint API POST /subscriptions et incluez le champ on_demand dans le corps de votre requête. Cela vous permet d’autoriser un moyen de paiement sans débit immédiat ou de définir un prix initial personnalisé. Pour débiter un abonnement à la demande : Pour les débits suivants, 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 et de réponses, des politiques de nouvelle tentative sécurisées 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 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 du premier débit réussi. Transmettez toujours billing_currency et billing_address.country explicitement 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 son premier débit, 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 utilisent une autorisation de $0, et non un débit. 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 ; le premier débit réel a lieu à la fin de l’essai. Dans la liste des paiements, un abonnement en période d’essai affiche exactement un paiement avec amount: 0.
Cycle de vie de l’abonnement : 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 durée 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 de Dodo.
Les cartes indiennes utilisent un e-mandat RBI. Les débits hors session (renouvellements et débits liés aux modifications de plan) peuvent prendre jusqu’à environ 48 heures pour être réglés, et les auto-débits 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’un débit est encore à l’état processing, un second débit 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 débits d’abonnement ont un minimum de $1 (ou l’équivalent dans la devise concernée). Les montants $0.01–$0.99 sont rejetés avec product_price: value out of range ; seul $0 est autorisé, via une configuration mandate_only à la demande.

Référence API associée

Create Subscription

Référence API pour créer des produits d’abonnement et gérer le cycle de vie des abonnements

Change Subscription Plan

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

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 31 juillet 2026