Skip to main content
Le package @dodopayments/bun fournit à votre serveur Bun trois gestionnaires de requêtes. Checkout renvoie des URL de checkout, CustomerPortal redirige un client vers le Customer Portal, et Webhooks vérifie les événements webhook et les achemine vers votre code. Chaque gestionnaire accepte un Request standard et renvoie un Response. Vous pouvez donc l’appeler depuis le gestionnaire fetch de Bun.serve().

Checkout Handler

Créez des URL de checkout avec des flux statiques, dynamiques et de session de checkout.

Customer Portal

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

Webhooks

Recevez et traitez les événements webhook Dodo Payments.

Installation

1

Install the Package

Exécutez cette commande à la racine de votre projet :
Le package nécessite également zod 3.25 ou une version ultérieure, qu’il indique comme dépendance peer.
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, puis copiez son Signing secret dans DODO_PAYMENTS_WEBHOOK_KEY :
Bun lit automatiquement les fichiers .env. Les exemples lisent donc ces valeurs depuis process.env. DODO_PAYMENTS_RETURN_URL est l’endroit où les clients sont redirigés après le checkout. Si vous ne transmettez pas d’environnement, les gestionnaires utilisent live_mode. Une clé API de mode test fonctionne uniquement avec test_mode.
Ne commitez jamais votre fichier .env ni vos secrets dans le contrôle de version.

Exemples de gestionnaires de routes

Tous les exemples utilisent le serveur natif de Bun, Bun.serve(), et acheminent les requêtes selon le chemin et la méthode dans son gestionnaire fetch.
Utilisez ce gestionnaire pour ajouter le checkout Dodo Payments à votre serveur Bun. Le gestionnaire statique traite les requêtes GET. Les gestionnaires de session et dynamiques traitent les requêtes POST. L’exemple de checkout dynamique suppose que le serveur renvoie dynamicCheckoutHandler(request) pour les requêtes POST.

Gestionnaire de route de checkout

Le gestionnaire de checkout prend en charge les trois façons d’accepter des paiements avec Dodo Payments :
  • Liens de paiement statiques : URL partageables qui collectent les paiements sans code.
  • Liens de paiement dynamiques : liens de paiement que vous générez avec des informations personnalisées. Ils utilisent des endpoints obsolètes.
  • Sessions de checkout : checkout hébergé avec un panier de produits, les informations du client et des options de personnalisation. Il s’agit du flux recommandé.
Checkout accepte les options suivantes : Le gestionnaire sert un checkout statique pour les requêtes GET. Pour les requêtes POST, il crée un lien de paiement dynamique lorsque type vaut dynamic, et une session de checkout dans le cas contraire.

Paramètres de requête pris en charge

string
requis
Identifiant du produit, par exemple ?productId=pdt_xxx.
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 l’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"
Affichez ou masquez 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 minimum du produit.
boolean
défaut:"true"
Affichez ou masquez la section des réductions.
string
Tout paramètre de requête commençant par metadata_ est transmis au checkout en tant que metadata, par exemple metadata_orderId=123.
Un indicateur de désactivation ne prend effet que lorsque le champ correspondant possède une valeur, par exemple email avec disableEmail=true. Le gestionnaire ajoute returnUrl depuis sa configuration au lien sous la forme redirect_url.
Si productId est manquant, le gestionnaire renvoie une réponse 400. Des paramètres de requête invalides ou un produit qui n’existe pas dans votre compte renvoient également une réponse 400.

Format de la réponse

Le checkout statique renvoie une réponse JSON contenant l’URL de checkout. En mode test, l’URL utilise test.checkout.dodopayments.com :
  • Envoyez les paramètres dans le 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 ou product_cart. Les abonnements nécessitent product_id.
  • Pour connaître tous les champs pris en charge du body, consultez :
Le checkout dynamique utilise les endpoints obsolètes POST /payments et POST /subscriptions comme proxy. Il continue de fonctionner pour les intégrations existantes, mais les nouvelles intégrations doivent utiliser les sessions de checkout.

Format de la réponse

Le checkout dynamique renvoie une réponse JSON contenant le lien de paiement comme URL de checkout :
Les sessions de checkout créent un checkout hébergé pour les achats ponctuels et les abonnements, avec un contrôle complet de la personnalisation. product_cart est le seul champ obligatoire et doit contenir au moins un produit. Si le body ne contient pas return_url, le gestionnaire utilise returnUrl depuis sa configuration.Chaque checkout_url ne peut être utilisé qu’une seule 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.Pour plus de détails et la liste complète des champs pris en charge, consultez le Guide d’intégration des sessions de checkout.

Format de la réponse

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

Gestionnaire de route du Customer Portal

Le gestionnaire de route du Customer Portal crée une session Customer Portal pour le client que vous transmettez et y redirige le navigateur. CustomerPortal accepte les mêmes options bearerToken et environment que Checkout.
Le gestionnaire ne vérifie pas l’identité de l’appelant. Toute personne qui l’appelle avec un ID client obtient l’accès au portail de ce client. Protégez la route avec votre propre authentification et transmettez uniquement l’ID client de l’utilisateur connecté.

Paramètres de requête

string
requis
ID client de la session du portail, par exemple ?customer_id=cus_123.
boolean
Si cette valeur est définie sur true, Dodo Payments envoie également le lien du portail au client par e-mail.
Le gestionnaire renvoie 400 si customer_id est manquant, et 500 si la session du portail ne peut pas être créée.

Gestionnaire de route webhook

Le gestionnaire de route webhook vérifie chaque requête avec votre secret webhook, transmis sous la forme webhookKey, avant d’exécuter votre code :
  • 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 en-têtes webhook-id, webhook-timestamp et webhook-signature avec webhookKey, conformément à la spécification Standard Webhooks. Renvoie 401 si la vérification échoue.
  • Validation de la charge utile : analyse le body en tant que JSON et le valide avec Zod. Renvoie 400 pour un JSON ou une charge utile non valide.
  • Gestion des erreurs :
    • 401 : signature non valide
    • 400 : charge utile non valide
    • 500 : erreur interne pendant 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.
L’adaptateur n’intercepte pas les erreurs levées dans vos gestionnaires. Elles se propagent jusqu’à Bun.serve() et la requête échoue.

Gestionnaires d’événements webhook pris en charge

Chaque gestionnaire est facultatif et asynchrone, et reçoit la charge utile vérifiée correspondant à son type d’événement :
Pour connaître la signification de chaque événement, consultez le Guide des événements webhook.

Prompt pour LLM

Copiez ce prompt dans votre assistant de programmation IA pour lui demander d’ajouter l’adaptateur à votre projet. Pour fournir également à votre agent la documentation et les compétences Dodo Payments, installez le Plugin Agent.
Dernière modification le 26 septembre 2026