Skip to main content
L’adaptateur @dodopayments/express fournit à votre application Express trois gestionnaires de routes : checkoutHandler renvoie des URL de checkout, CustomerPortal redirige un client vers le Customer Portal, et Webhooks vérifie les requêtes webhook et appelle vos gestionnaires d’événements.

Checkout Handler

Créez des liens de paiement et des sessions de checkout depuis votre application Express.

Customer Portal

Permettez aux clients de gérer leurs abonnements et leurs informations.

Webhooks

Vérifiez et traitez les événements webhook de Dodo Payments.

Installation

1

Install the Package

Exécutez la commande suivante à la racine de votre projet :
2

Set Up Environment Variables

Créez un fichier .env à la racine de votre projet :
Créez la clé API sous Developer → API Keys. Ajoutez votre endpoint webhook sous Developer → Webhooks et copiez son secret de signature dans DODO_PAYMENTS_WEBHOOK_KEY. Pendant le développement, utilisez une clé API en mode test avec DODO_PAYMENTS_ENVIRONMENT=test_mode, car une clé en mode test fonctionne uniquement avec le mode test. DODO_PAYMENTS_RETURN_URL est facultatif.
Ne committez jamais votre fichier .env ni vos secrets dans le contrôle de version.

Exemples de gestionnaires de routes

Les exemples enregistrent des routes sur une application Express créée avec express(). Les gestionnaires checkout POST et le gestionnaire webhook lisent req.body ; chaque exemple enregistre donc express.json() avant ses routes.
Utilisez ce gestionnaire pour intégrer le checkout de Dodo Payments à votre application Express. Il prend en charge les flux de paiement statique (GET), dynamique (POST) et par session (POST). Enregistrez chaque flux POST sur son propre chemin, car le premier gestionnaire enregistré pour un chemin répond à toutes les requêtes qui lui sont adressées.

Gestionnaire de route checkout

L’adaptateur prend en charge les trois flux checkout de Dodo Payments. Définissez type dans la configuration du gestionnaire pour choisir le flux servi par une route. Chaque flux répond avec un JSON contenant une checkout_url que le client peut ouvrir.
  • Liens de paiement statiques : type: "static", GET. Crée un lien de paiement pour un produit à partir des query parameters, après avoir vérifié que le produit existe.
  • Liens de paiement dynamiques : type: "dynamic", POST. Crée un paiement ponctuel ou un abonnement avec un lien de paiement, selon que le produit est récurrent ou non.
  • Sessions de checkout : type: "session", POST. Crée une session de checkout à partir d’un panier de produits et des informations du client. Utilisez ce flux pour les nouvelles intégrations.
checkoutHandler accepte les options suivantes : Enregistrez le gestionnaire pour GET lorsque type vaut static, et pour POST lorsque type vaut dynamic ou session. Le gestionnaire renvoie 405 pour les autres méthodes.

Query parameters pris en charge

string
requis
Identifiant du produit, par exemple ?productId=pdt_nZuwz45WAs64n3l07zpQR.
integer
défaut:"1"
Quantité du produit.
string
Nom complet du client. Ignoré si firstName ou lastName est fourni.
string
Prénom du client.
string
Nom de famille du client.
string
Adresse e-mail du client.
string
Pays du client, sous forme de code ISO 3166-1 alpha-2.
string
Adresse postale du client.
string
Ville du client.
string
État ou province du client.
string
Code postal du client.
boolean
Définissez cette valeur sur true pour désactiver le champ du nom complet.
boolean
Définissez cette valeur sur true pour désactiver le champ du prénom.
boolean
Définissez cette valeur sur true pour désactiver le champ du nom de famille.
boolean
Définissez cette valeur sur true pour désactiver le champ d’adresse e-mail.
boolean
Définissez cette valeur sur true pour désactiver le champ du pays.
boolean
Définissez cette valeur sur true pour désactiver le champ de la ligne d’adresse.
boolean
Définissez cette valeur sur true pour désactiver le champ de la ville.
boolean
Définissez cette valeur sur true pour désactiver le champ de l’État.
boolean
Définissez cette valeur sur true pour désactiver le champ du code postal.
string
Devise du paiement, par exemple USD.
boolean
défaut:"true"
Affiche ou masque le sélecteur de devise.
number
Fixe le montant facturé, en unités monétaires principales, par exemple 12.5 pour $12.50. Fonctionne uniquement avec les produits Pay What You Want et est ignoré s’il est inférieur au prix minimal du produit.
boolean
défaut:"true"
Affiche ou masque la section des remises.
string
Tout query parameter commençant par metadata_ est transmis au checkout comme métadonnée, par exemple metadata_orderId=123.
Un indicateur de désactivation prend effet uniquement lorsqu’il vaut true et que le champ correspondant contient une valeur, par exemple email avec disableEmail. Le gestionnaire transmet ces paramètres à un lien de paiement statique.
Si productId est absent, le gestionnaire renvoie une réponse 400. Des query parameters invalides ou un produit qui n’existe pas dans votre compte entraînent également une réponse 400.

Format de la réponse

Le checkout statique renvoie une réponse JSON contenant l’URL de checkout :
  • Envoyez les paramètres dans un body JSON d’une requête POST.
  • Prend en charge les paiements ponctuels et récurrents. Le gestionnaire récupère le produit, puis crée un abonnement si le produit est récurrent, ou un paiement ponctuel dans le cas contraire.
  • Le body doit contenir billing (avec street, city, state, country et zipcode) et customer, ainsi que product_id (avec un quantity facultatif) ou product_cart. Les abonnements nécessitent product_id.
  • Le gestionnaire transmet également metadata, allowed_payment_method_types, billing_currency, discount_codes (ou discount_code, désormais obsolète), return_url, show_saved_payment_methods et tax_id. Pour les abonnements, il transmet également addons, on_demand et trial_period_days. Il ignore les autres champs.
  • Pour plus de détails sur les champs, consultez :
Dynamic Checkout appelle les endpoints obsolètes POST /payments et POST /subscriptions. Utilisez Checkout Sessions pour les nouvelles intégrations.

Format de la réponse

Le checkout dynamique renvoie une réponse JSON contenant le lien de paiement comme URL de checkout :
Envoyez le payload d’une session de checkout dans le body JSON. Le gestionnaire crée une session de checkout qui prend en charge l’intégralité du flux de paiement pour les achats ponctuels et les abonnements, puis renvoie son checkout_url. product_cart est obligatoire et doit contenir au moins un produit.Chaque checkout_url ne peut être utilisé qu’une fois et expire après 24 heures, ou après 15 minutes lorsque vous transmettez confirm: true. Une session créée avec payment_method_id ne renvoie aucun checkout_url ; le gestionnaire répond donc avec 400.Consultez le guide d’intégration Checkout Sessions pour plus de détails et la liste complète des champs pris en charge.

Format de la réponse

Les sessions de checkout renvoient une réponse JSON contenant l’URL de checkout :

Gestionnaire de route Customer Portal

Le gestionnaire de route Customer Portal crée une session Customer Portal pour le client indiqué par customer_id et redirige la requête vers le lien du portail. CustomerPortal accepte les options bearerToken et environment, comme checkoutHandler. Si Dodo Payments ne peut pas créer la session, le gestionnaire renvoie 500.

Query parameters

string
requis
ID client de la session du portail, par exemple ?customer_id=cus_123.
boolean
Si cette valeur est true, envoie au client un e-mail contenant le lien du portail.
Renvoie 400 si customer_id est absent. Le gestionnaire n’authentifie pas la requête et ouvre le portail pour tout customer_id reçu. Placez donc la route derrière votre propre authentification et transmettez uniquement l’ID client de l’utilisateur connecté.

Gestionnaire de route webhook

Le gestionnaire webhook vérifie chaque requête avec votre secret webhook, transmis sous la forme webhookKey, puis appelle vos gestionnaires d’événements.
Enregistrez express.json() avant la route webhook. Le gestionnaire vérifie la signature par rapport à req.body ; il rejette donc toutes les requêtes sauf si le body est un JSON analysé. N’utilisez pas express.raw() pour cette route.
  • Méthode : seules les requêtes POST sont prises en charge. Les autres méthodes renvoient 405.
  • Vérification de la signature : vérifie les headers webhook-id, webhook-timestamp et webhook-signature avec webhookKey, conformément à la spécification Standard Webhooks. Renvoie 401 si la vérification échoue.
  • Validation du payload : effectuée avec Zod. Renvoie 400 pour les payloads invalides.
  • Gestion des erreurs :
    • 401 : signature invalide
    • 400 : payload invalide
    • 500 : erreur interne lors de la vérification
  • Routage des événements : appelle onPayload pour chaque événement, puis le gestionnaire correspondant au type de l’événement, et renvoie 200 lorsqu’ils ont terminé. Le gestionnaire n’intercepte pas les erreurs levées par vos gestionnaires d’événements.

Gestionnaires d’événements webhook pris en charge

Chaque gestionnaire est facultatif et asynchrone. Pour le payload de chaque événement, consultez le guide des événements webhook.

Prompt pour le LLM

Dernière modification le 26 septembre 2026