@dodopayments/tanstack fournit à votre projet TanStack Start 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 l’appelez donc depuis un gestionnaire de route serveur.
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 répertorie comme dépendance peer.2
Set Up Environment Variables
Créez un fichier TanStack Start charge les fichiers
.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 :.env, et les routes serveur lisent les valeurs depuis process.env. DODO_PAYMENTS_RETURN_URL est l’endroit où les clients arrivent 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.Exemples de gestionnaires de routes
Les exemples sont des routes serveur TanStack Start dans
src/routes/api/. Chacune définit ses gestionnaires sous server.handlers dans createFileRoute. Les versions plus anciennes de TanStack Start, comme la version 1.129, définissent les routes serveur avec createServerFileRoute depuis @tanstack/react-start/server et un appel .methods() à la place. Les gestionnaires Dodo Payments fonctionnent de la même manière avec les deux API : transmettez-leur le request.- Checkout Handler
- Customer Portal Handler
- Webhook Handler
Utilisez ce gestionnaire pour ajouter le checkout Dodo Payments à votre application. Le gestionnaire
GET sert le checkout statique. Le gestionnaire POST sert les sessions de checkout, ou le checkout dynamique lorsque vous définissez type: "dynamic". L’exemple de checkout dynamique suppose que vous avez défini type: "dynamic".Gestionnaire de route Checkout
Le gestionnaire de checkout prend en charge les trois méthodes de paiement avec Dodo Payments :- Static Payment Links : URL partageables qui collectent les paiements sans code.
- Dynamic Payment Links : liens de paiement que vous générez avec des informations personnalisées. Ils utilisent des endpoints obsolètes.
- Checkout Sessions : checkout hébergé avec panier de produits, informations client et options de personnalisation. Il s’agit du flux recommandé.
Checkout accepte ces options :
Le gestionnaire sert le 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 les autres cas.
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 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 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 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 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 réductions.
string
Tout paramètre de requête commençant par
metadata_ est transmis au checkout en tant que métadonnées, par exemple metadata_orderId=123.email avec disableEmail=true. Le gestionnaire ajoute returnUrl depuis sa configuration au lien sous la forme redirect_url.Format de la réponse
Le checkout statique renvoie une réponse JSON contenant l’URL de checkout. En mode test, l’URL utilisetest.checkout.dodopayments.com :Dynamic Checkout (POST)
Dynamic Checkout (POST)
- Envoyez les paramètres dans le corps JSON d’une requête POST.
- Prend en charge les paiements uniques et récurrents. Le gestionnaire récupère le produit, puis crée un abonnement si le produit est récurrent et un paiement unique dans le cas contraire.
- Le corps doit contenir
billing(avecstreet,city,state,countryetzipcode) etcustomer, ainsi queproduct_idouproduct_cart. Les abonnements nécessitentproduct_id. - Pour connaître tous les champs de corps pris en charge, 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)
Les sessions de checkout créent un checkout hébergé pour les achats uniques 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 corps 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 pour consulter tous les champs pris en charge, consultez le Guide d’intégration des Checkout Sessions.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 que vous transmettez et y redirige le navigateur.CustomerPortal accepte les mêmes options bearerToken et environment que Checkout.
Paramètres de requête
string
requis
Identifiant 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.customer_id est absent, 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 commewebhookKey, 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-timestampetwebhook-signatureavecwebhookKey, 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 n’est pas valide.
- Gestion des erreurs :
- 401 : signature non valide
- 400 : charge utile non valide
- 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.