@dodopayments/remix fournit à votre application Remix 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 et renvoie un Response ; vous l’appelez donc depuis le loader ou le action d’une route.
Checkout Handler
Créez des URL de checkout depuis votre application Remix.
Customer Portal
Permettez aux clients de gérer leurs abonnements et leurs informations.
Webhooks
Recevez et vérifiez les événements webhook Dodo Payments.
Installation
1
Install the Package
Exécutez cette commande à la racine de votre projet :Le package répertorie Remix 2 (
remix 2.16.8 ou version ultérieure) et zod 3.25 ou version ultérieure comme peer dependencies.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. DODO_PAYMENTS_RETURN_URL correspond à la page vers laquelle les clients sont redirigés après le checkout. Si vous ne transmettez pas d’environnement, les gestionnaires utilisent live_mode.Exemples de gestionnaires de routes
Les exemples sont des resource routes Remix, qui exportent un
loader pour les requêtes GET ou un action pour les requêtes POST, sans composant. Avec les routes à fichiers plats, app/routes/api.checkout.tsx sert /api/checkout.- Checkout Handler
- Customer Portal Handler
- Webhook Handler
Utilisez ce gestionnaire pour ajouter le checkout Dodo Payments à votre application Remix. Le
loader sert le checkout statique. Le action sert ici le checkout dynamique. Pour servir des sessions de checkout, le flux recommandé, renvoyez plutôt checkoutSessionHandler(request) depuis le action.action renvoie checkoutSessionHandler(request).Gestionnaire de route Checkout
Le gestionnaire de checkout prend en charge les trois façons d’accepter des paiements 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 un panier de produits, les informations du client et des options de personnalisation. Il s’agit du flux recommandé.
Checkout accepte ces options :
Static Checkout (GET)
Static Checkout (GET)
Query Parameters 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 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 la ligne d’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 ZIP.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 remises.
string
Tout query parameter commençant par
metadata_ est transmis en tant que métadonnées.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 un corps JSON d’une requête POST.
- Prend en charge les paiements ponctuels et récurrents.
billingetcustomersont requis.- 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 l’URL de checkout :Checkout Sessions (POST)
Checkout Sessions (POST)
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 requis. Si le corps ne contient pas return_url, le gestionnaire utilise returnUrl de sa configuration.Pour plus de détails et la liste complète des champs pris en charge, consultez le Guide d’intégration des Checkout Sessions.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 que vous transmettez et y redirige le navigateur avec une réponse 307.Query Parameters
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.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-timestampetwebhook-signatureavecwebhookKey, conformément à la spécification Standard Webhooks. Renvoie 401 si la vérification échoue. - Validation de la payload : valide la payload avec Zod. Renvoie 400 si la payload est invalide.
- Gestion des erreurs :
- 401 : signature invalide
- 400 : payload 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.