@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 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 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.- Checkout Handler
- Customer Portal Handler
- Webhook Handler
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.
Static Checkout (GET)
Static Checkout (GET)
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.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.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 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(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(ou lediscount_codeobsolète),return_url,show_saved_payment_methodsettax_id. Pour les abonnements, il transmet aussiaddons,on_demandettrial_period_days. Les autres champs sont ignorés. - 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 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 danscustomer_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.Gestionnaire de routes webhook
Le gestionnaire webhook vérifie chaque requête avec votre secret webhook, transmis en tant quewebhookKey, 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-timestampetwebhook-signatureavecwebhookKey, 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
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 générées par vos gestionnaires d’événements.