Skip to main content
L’adaptateur @dodopayments/hono fournit à votre application Hono trois gestionnaires de routes : Checkout 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 Hono.

Customer Portal

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

Webhooks

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

Installation

1

Install the Package

Exécutez la commande suivante à la racine de votre projet :
Le package nécessite Hono 4.8.9 ou une version ultérieure.
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 commitez 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 Hono créée avec new Hono(). Les gestionnaires lisent eux-mêmes le corps de la requête et n’ont donc besoin d’aucun middleware d’analyse du corps.
Utilisez ce gestionnaire pour intégrer le checkout Dodo Payments à votre application Hono. Il prend en charge les flux statique (GET), dynamique (POST) et de session (POST). Enregistrez chaque flux POST sur son propre chemin, car Hono s’arrête au premier gestionnaire exécuté pour une requête.

Gestionnaire de routes checkout

L’adaptateur prend en charge les trois flux de checkout Dodo Payments. Définissez type dans la configuration du gestionnaire pour choisir le flux servi par une route. Chaque flux renvoie un JSON contenant une checkout_url que le client peut ouvrir.
  • Liens de paiement statiques : type: "static", GET. Construit un lien de paiement pour un produit à partir des paramètres de requête, 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.
Checkout accepte les options suivantes : Enregistrez le gestionnaire pour GET lorsque type vaut static, et pour POST lorsque type vaut dynamic ou session. Le gestionnaire considère toute requête qui n’est pas une requête POST comme une requête de checkout statique.

Paramètres de requête 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 la valeur sur true pour désactiver le champ du nom complet.
boolean
Définissez la valeur sur true pour désactiver le champ du prénom.
boolean
Définissez la valeur sur true pour désactiver le champ du nom.
boolean
Définissez la valeur sur true pour désactiver le champ d’e-mail.
boolean
Définissez la valeur sur true pour désactiver le champ du pays.
boolean
Définissez la valeur sur true pour désactiver le champ de l’adresse.
boolean
Définissez la valeur sur true pour désactiver le champ de la ville.
boolean
Définissez la valeur sur true pour désactiver le champ de l’État.
boolean
Définissez la valeur sur true pour désactiver le champ du code postal.
string
Devise du paiement, par exemple USD.
boolean
défaut:"true"
Afficher ou masquer 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"
Afficher ou masquer la section des remises.
string
Tout paramètre de requête commençant par metadata_ est transmis au checkout comme métadonnée, par exemple metadata_orderId=123.
Un indicateur de désactivation ne prend effet que lorsqu’il vaut true et que le champ correspondant possède 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 paramètres de requête invalides ou un produit qui n’existe pas dans votre compte produisent é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 le corps 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 et un paiement ponctuel dans le cas contraire.
  • Le corps 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 le discount_code obsolète), return_url, show_saved_payment_methods et tax_id. Pour les abonnements, il transmet aussi addons, on_demand et trial_period_days. Les autres champs sont ignorés.
  • Pour plus de détails sur les champs, consultez :
Le checkout dynamique appelle les endpoints obsolètes POST /payments et POST /subscriptions. Utilisez les sessions de checkout 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 la charge utile de la session de checkout dans le corps JSON. Le gestionnaire crée une session de checkout qui gère 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 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.Consultez le Guide d’intégration des sessions de checkout 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 routes Customer Portal

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

Paramètres de requête

string
requis
Identifiant du client pour la session du portail, par exemple ?customer_id=cus_123.
boolean
Si cette valeur vaut true, envoie un e-mail au client 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’identifiant client de l’utilisateur connecté.

Gestionnaire de routes webhook

Le gestionnaire webhook vérifie chaque requête avec votre secret webhook, transmis en tant que webhookKey, puis appelle vos gestionnaires d’événements. Il lit lui-même le corps brut de la requête ; la route n’a donc besoin d’aucun middleware d’analyse du corps.
  • 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 : effectuée avec Zod. Renvoie 400 si la charge utile est invalide.
  • Gestion des erreurs :
    • 401 : signature invalide
    • 400 : charge utile 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 générées par vos gestionnaires d’événements.

Gestionnaires d’événements webhook pris en charge

Chaque gestionnaire est facultatif et asynchrone. Pour connaître la charge utile de chaque événement, consultez le Guide des événements webhook.

Prompt pour LLM

Dernière modification le 26 septembre 2026