@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 Créez la clé API sous Developer → API Keys. Ajoutez votre endpoint webhook sous Developer → Webhooks et copiez son secret de signature dans
.env à la racine de votre projet :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.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.- Checkout Handler
- Customer Portal Handler
- Webhook Handler
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.
Static Checkout (GET)
Static Checkout (GET)
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.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.Format de la réponse
Le checkout statique renvoie une réponse JSON contenant l’URL de checkout :Dynamic Checkout (POST)
Dynamic Checkout (POST)
- 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(avecstreet,city,state,countryetzipcode) etcustomer, ainsi queproduct_id(avec unquantityfacultatif) ouproduct_cart. Les abonnements nécessitentproduct_id. - Le gestionnaire transmet également
metadata,allowed_payment_method_types,billing_currency,discount_codes(oudiscount_code, désormais obsolète),return_url,show_saved_payment_methodsettax_id. Pour les abonnements, il transmet égalementaddons,on_demandettrial_period_days. Il ignore les autres champs. - Pour plus de détails sur les champs, consultez :
Format de la réponse
Le checkout dynamique renvoie une réponse JSON contenant le lien de paiement comme URL de checkout :Checkout Sessions (POST)
Checkout Sessions (POST)
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é parcustomer_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.Gestionnaire de route webhook
Le gestionnaire webhook vérifie chaque requête avec votre secret webhook, transmis sous la formewebhookKey, puis appelle vos gestionnaires d’événements.
- 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-timestampetwebhook-signatureavecwebhookKey, 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
onPayloadpour 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.