Skip to main content
Le module @dodopayments/nuxt fournit à votre application Nuxt trois gestionnaires de routes serveur. checkoutHandler renvoie des URL de checkout, customerPortalHandler redirige un client vers le Customer Portal, et Webhooks vérifie les événements webhook et les achemine vers votre code.

Checkout API Route

Créez des URLs de checkout depuis une route serveur Nuxt.

Customer Portal API Route

Permettez aux clients de gérer leurs abonnements et leurs informations depuis une route serveur Nuxt.

Webhooks API Route

Recevez et vérifiez les événements webhook de Dodo Payments dans Nuxt.

Vue d’ensemble

Le module enregistre ses gestionnaires comme des auto-imports serveur Nuxt. Vos routes serveur peuvent donc appeler checkoutHandler, customerPortalHandler et Webhooks sans instructions d’importation. Chaque route lit vos identifiants depuis runtimeConfig. Nuxt n’expose que runtimeConfig.public au navigateur, afin que la clé API et le secret webhook restent sur le serveur.

Installation

1

Install the Nuxt Module

Exécutez cette commande à la racine de votre projet :
Le module indique Nuxt 3 (3.13.1 ou version ultérieure) et zod 3.25 ou version ultérieure comme dépendances homologues.
2

Register the Module in nuxt.config.ts

Ajoutez @dodopayments/nuxt à votre tableau modules et mappez vos identifiants dans runtimeConfig :
nuxt.config.ts
Définissez ces variables d’environnement, par exemple dans un fichier .env à la racine de votre projet :Un serveur Nuxt compilé ne lit pas votre fichier .env. À l’exécution, Nuxt remplace une valeur runtimeConfig uniquement à partir de la variable correspondant à son chemin, comme NUXT_PRIVATE_RETURN_URL pour private.returnUrl. Définissez donc également ces variables dans votre environnement d’hébergement.
Ne validez jamais votre fichier .env ni vos secrets dans le contrôle de version.

Exemples de gestionnaires de routes API

Les exemples créent des routes serveur dans le répertoire server/routes/api/. Nuxt associe chaque route au nom du fichier et au suffixe de méthode. Ainsi, checkout.get.ts gère GET /api/checkout.
Utilisez ce gestionnaire pour ajouter le checkout de Dodo Payments à votre application Nuxt. Une route GET sert le checkout statique. Une route POST sert les sessions de checkout ou le checkout dynamique lorsque vous définissez type: "dynamic".
Créez une route GET pour le checkout statique :
checkout.post.ts sert un flux POST. Utilisez soit l’exemple de checkout dynamique, soit celui de la session de checkout :
Si productId est manquant ou invalide, le gestionnaire renvoie une réponse 400.
Pour tester les routes, envoyez ces requêtes :

Gestionnaire de route de checkout

Le gestionnaire de checkout prend en charge les trois méthodes de paiement avec Dodo Payments :
  • Payment Links statiques : des URL partageables qui permettent de collecter des paiements sans code.
  • Payment Links dynamiques : des liens de paiement que vous générez avec des détails personnalisés. Ils utilisent des endpoints obsolètes.
  • Sessions de checkout : un checkout hébergé avec un panier de produits, les informations du client et des options de personnalisation. Il s’agit du flux recommandé.
checkoutHandler accepte les options suivantes :

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 du client.
string
Adresse e-mail du client.
string
Pays du client, sous forme de code ISO 3166-1 alpha-2.
string
Ligne d’adresse du client.
string
Ville du client.
string
État ou province du client.
string
Code ZIP ou 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.
boolean
Définissez cette valeur sur true pour désactiver le champ de l’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 ZIP.
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 paramètre de requête commençant par metadata_ est transmis comme métadonnée.
Le gestionnaire ajoute returnUrl provenant de sa configuration au lien sous la forme redirect_url.
Si productId est manquant, le gestionnaire renvoie une réponse 400. Les paramètres de requête invalides et les identifiants de produit inexistants renvoient également 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.
Le checkout dynamique utilise comme proxy les endpoints obsolètes POST /payments et POST /subscriptions. 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 l’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. Si le corps ne contient pas return_url, le gestionnaire utilise returnUrl depuis sa configuration.Pour plus de détails et pour consulter tous les champs pris en charge, consultez le Guide d’intégration des sessions de checkout.Une session créée avec payment_method_id ne renvoie aucune URL de checkout ; le gestionnaire répond donc avec 400. Pour débiter un moyen de paiement enregistré, créez la session avec le SDK.

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é et y redirige le navigateur.
Le gestionnaire ne vérifie pas l’identité de l’appelant. Toute personne qui l’appelle avec un identifiant client obtient le portail de ce client. Protégez la route avec votre propre authentification et transmettez uniquement l’identifiant client de l’utilisateur connecté.

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 est définie sur true, Dodo Payments envoie également le lien du portail au client par e-mail.
À partir de @dodopayments/nuxt 0.2.11, le gestionnaire renvoie HTTP 400 si customer_id est manquant, et HTTP 500 si la session du portail ne peut pas être créée. Les versions antérieures renvoient HTTP 200 avec le corps JSON { "status": 400, "body": "Missing customer_id in query parameters" }. Pour vous fier au statut HTTP, effectuez une mise à niveau vers la version 0.2.11 ou une version ultérieure.

Gestionnaire de route webhook

Le gestionnaire de route webhook vérifie chaque requête 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 le corps brut de la requête ainsi que 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 : valide la charge utile 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.
L’adaptateur n’intercepte pas les erreurs générées dans vos gestionnaires. Elles se propagent jusqu’à Nuxt et la requête échoue.

Gestionnaires d’événements webhook pris en charge

Chaque gestionnaire 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 faire ajouter le module à votre projet. Pour fournir également à votre agent la documentation et les compétences Dodo Payments, installez le plugin Agent.
Dernière modification le 28 septembre 2026