Skip to main content

Quick Start Guide

Get your first checkout session running in under 5 minutes

API Reference & Live Testing

Explore the full API documentation and interactively test Checkout Session requests and responses.

Preview Checkout

Calculate pricing, taxes, and totals before creating a session.
Session Validity: Checkout sessions are valid for 24 hours by default. If you pass confirm=true in your request, the session will only be valid for 15 minutes.
Liens à usage unique : le checkout_url renvoyé par l’API n’est pas réutilisable et expire dans les 24 heures (ou après 15 minutes lorsque confirm=true). Il est destiné à un seul client pour effectuer un paiement. Générez une nouvelle session de paiement pour chaque client et chaque tentative de paiement au lieu de partager ou de réutiliser un lien.

Prérequis

1

Dodo Payments Account

Vous devez disposer d’un compte marchand Dodo Payments actif avec un accès à l’API.
2

API Credentials

Générez vos identifiants API depuis le tableau de bord Dodo Payments :
3

Products Setup

Créez vos produits dans le tableau de bord Dodo Payments avant d’implémenter les sessions de paiement.

Créer votre première session de paiement

Réponse de l’API

Toutes les méthodes ci-dessus renvoient la même structure de réponse :
Le checkout_url généré est à usage unique et expire dans les 24 heures. Ne le mettez pas en cache et ne le réutilisez pas entre plusieurs clients ou tentatives de paiement : créez une nouvelle session de paiement chaque fois que vous avez besoin d’un nouveau lien.
1

Get the checkout URL

Extrayez le checkout_url de la réponse de l’API.
2

Redirect your customer

Dirigez votre client vers l’URL de paiement pour terminer son achat.
Options d’intégration alternatives : au lieu d’effectuer une redirection, vous pouvez intégrer directement le paiement dans votre page avec Overlay Checkout (superposition modale) ou Inline Checkout (entièrement intégré). Dans une application mobile native, transmettez la même URL aux SDK Mobile Checkout pour Android, iOS, React Native ou Flutter. Toutes ces options utilisent la même URL de session de paiement.
3

Handle the return

Après le paiement, les clients sont redirigés vers votre return_url avec des paramètres de requête comprenant l’ID du paiement ou de l’abonnement, le statut, l’adresse e-mail du client et les éventuelles clés de licence. Consultez la documentation des paramètres return_url pour obtenir la liste complète.

Corps de la requête

Required Fields

Champs essentiels nécessaires pour chaque session de paiement

Optional Fields

Configuration supplémentaire pour personnaliser votre expérience de paiement

Champs obligatoires

array
requis
Tableau de produits à inclure dans la session de paiement. Chaque produit doit avoir un product_id valide provenant de votre tableau de bord Dodo Payments.
Paiement mixte : vous pouvez combiner des produits avec paiement unique et des produits par abonnement dans une même session de paiement. Cela permet des cas d’utilisation avancés, comme des frais de configuration associés à des abonnements, des offres groupées de matériel et de SaaS, et bien plus encore.
Trouver les ID de vos produits : vous trouverez les ID des produits dans votre tableau de bord Dodo Payments, sous Produits → Afficher les détails, ou en utilisant l’API List Products.

Champs facultatifs

Configurez ces champs pour personnaliser l’expérience de paiement et ajouter une logique métier à votre flux de paiement.
object
Informations sur le client. Vous pouvez associer un client existant à l’aide de son ID ou créer un nouvel enregistrement client pendant le paiement.
Associez un client existant à la session de paiement à l’aide de son ID.
object
Informations sur l’adresse de facturation pour un calcul précis des taxes, la prévention de la fraude et la conformité réglementaire.
Lorsque confirm est défini sur true, tous les champs de l’adresse de facturation deviennent obligatoires pour créer la session.
array
Contrôlez les moyens de paiement disponibles pour les clients lors du paiement. Cela permet d’optimiser l’expérience pour certains marchés ou exigences commerciales.Options disponibles : credit, debit, upi_collect, apple_pay, google_pay, amazon_pay, klarna, affirm, afterpay_clearpay, cashapp, multibanco, bancontact_card, eps, ideal, przelewy24, paypal
Important : incluez toujours credit et debit comme options de secours afin d’éviter les échecs de paiement lorsque les moyens de paiement privilégiés ne sont pas disponibles.
Exemple :
string
Remplacez la sélection de devise par défaut par une devise de facturation fixe. Utilise les codes de devise ISO 4217.Devises prises en charge : USD, EUR, GBP, CAD, AUD, INR, et bien d’autresExemple : "USD" pour les dollars américains, "EUR" pour les euros
Ce champ n’est pris en compte que lorsque la tarification adaptative est activée. Si elle est désactivée, la devise par défaut du produit est utilisée.
boolean
défaut:"false"
Affichez les moyens de paiement précédemment enregistrés pour les clients récurrents afin d’accélérer le paiement et d’améliorer l’expérience utilisateur.
string
URL vers laquelle rediriger les clients après la finalisation du paiement. Dodo Payments ajoute les paramètres de requête suivants à votre URL lors de la redirection :Exemples d’URL de redirection :
Utilisez les paramètres de requête license_key et email pour afficher les clés de licence ou envoyer immédiatement une confirmation sur votre page de retour, sans appel API supplémentaire.
string
URL vers laquelle rediriger les clients lorsqu’ils cliquent sur le bouton de retour ou annulent la session de paiement. Si elle n’est pas fournie, le bouton de retour ne sera pas affiché.
Définissez un cancel_url pour offrir aux clients un moyen clair de revenir sur votre site sans terminer leur achat. Cela améliore l’expérience de paiement et réduit les frictions.
boolean
défaut:"false"
Si la valeur est true, finalise immédiatement tous les détails de la session. L’API génère une erreur si des données obligatoires sont manquantes.
array
Appliquez un ou plusieurs codes de réduction cumulés à la session de paiement. Les codes sont appliqués dans l’ordre du tableau (le premier code réduit le prix de base, le deuxième réduit le prix déjà remisé, et ainsi de suite), dans la limite de 20 codes par session.
Le champ discount_code ci-dessous, au singulier, est obsolète, mais reste entièrement pris en charge — les intégrations existantes continuent de fonctionner sans modification. Il ne peut pas être combiné avec discount_codes dans la même requête. Migrez vers discount_codes lorsque cela vous convient pour profiter du cumul.
string
obsolète
Obsolète — préférez discount_codes pour les nouvelles intégrations. Ce champ fonctionne toujours pour assurer la rétrocompatibilité, mais ne peut pas être combiné avec discount_codes dans la même requête.
object
Paires clé-valeur personnalisées permettant de stocker des informations supplémentaires sur la session.
boolean
Remplacez le comportement 3DS par défaut du marchand pour cette session.
boolean
défaut:"false"
Activez le mode de collecte d’adresse minimale. Lorsqu’il est activé, le paiement ne collecte que :
  • Pays : toujours obligatoire pour la détermination des taxes
  • Code ZIP/code postal : uniquement dans les régions où il est nécessaire pour calculer la taxe de vente, la TVA ou la GST
Cela réduit considérablement les frictions lors du paiement en supprimant les champs de formulaire inutiles.
Activez l’adresse minimale pour accélérer la finalisation du paiement. La collecte de l’adresse complète reste disponible pour les entreprises qui exigent des informations de facturation complètes.
object
Personnalisez l’apparence et le comportement de l’interface de paiement.
object
Configurez des fonctionnalités et des comportements spécifiques pour la session de paiement.
array
Collectez des informations supplémentaires auprès des clients lors du paiement à l’aide de champs de formulaire personnalisés. Vous pouvez définir jusqu’à 5 champs personnalisés par session de paiement. Les réponses des clients sont incluses dans les payloads webhook et disponibles via l’API.
Les réponses des clients aux champs personnalisés sont incluses dans :
  • Webhooks : payment.succeeded, subscription.active et les autres payloads d’événements pertinents contiennent le tableau custom_field_responses
  • Réponses de l’API : les objets de paiement et d’abonnement incluent custom_field_responses
object
Configuration supplémentaire pour les sessions de paiement contenant des produits par abonnement.

Exemples d’utilisation

Voici 10 exemples complets présentant différentes configurations de sessions de paiement pour divers scénarios commerciaux :

1. Paiement simple pour un seul produit

2. Panier multi-produits

3. Abonnement avec période d’essai

4. Paiement préconfirmé

Lorsque confirm est défini sur true, le client est directement dirigé vers la page de paiement, sans passer par les étapes de confirmation.

5. Paiement avec remplacement de devise

Le remplacement billing_currency ne prend effet que lorsque la devise adaptive currency est activée dans les paramètres de votre compte. Si elle est désactivée, ce paramètre n’a aucun effet.

6. Moyens de paiement enregistrés pour les clients récurrents

7. Paiement B2B avec collecte de l’ID fiscal

8. Paiement avec thème sombre et codes de réduction cumulés

9. Moyens de paiement régionaux (UPI pour l’Inde)

Pour plus d’informations sur la configuration et les tests d’UPI, consultez la page Moyens de paiement en Inde.

10. Paiement BNPL (Achetez maintenant, payez plus tard)

Pour plus d’informations sur la configuration et les tests de BNPL, consultez la page Achetez maintenant, payez plus tard (BNPL).

11. Utiliser des moyens de paiement existants pour un paiement instantané

Utilisez le moyen de paiement enregistré d’un client pour créer une session de paiement traitée immédiatement, sans collecte du moyen de paiement :
Lorsque vous utilisez payment_method_id, confirm doit être défini sur true et un customer_id existant doit être fourni. Le moyen de paiement est vérifié pour déterminer s’il est compatible avec la devise du paiement.
Le moyen de paiement doit appartenir au client et être compatible avec la devise du paiement. Cela permet les achats en un clic pour les clients récurrents.

12. Liens courts pour des URL de paiement plus propres

Générez des liens de paiement raccourcis et partageables avec des slugs personnalisés :
Les liens courts sont parfaits pour le partage par SMS, e-mail ou sur les réseaux sociaux. Ils sont plus faciles à retenir et inspirent davantage confiance aux clients que les URL longues.

13. Ignorer la page de réussite du paiement avec redirection immédiate

Redirigez immédiatement les clients une fois le paiement terminé, sans afficher la page de réussite par défaut :
Utilisez redirect_immediately: true lorsque vous disposez d’une page de réussite personnalisée offrant une meilleure expérience utilisateur que la page de réussite par défaut. Cette option est particulièrement utile pour les applications mobiles et les flux de paiement intégrés.
Lorsque redirect_immediately est activé, les clients sont redirigés vers votre return_url immédiatement après la finalisation du paiement, en ignorant complètement la page de réussite par défaut.

14. Forcer une langue

Forcez l’affichage du paiement dans une langue spécifique, en remplaçant la détection de la langue du navigateur du client :
Utilisez force_language lorsque vous connaissez la langue préférée de votre client (par exemple, depuis les paramètres de son compte) ou lorsque vous ciblez certains marchés régionaux.
Langues prises en charge : arabe (ar), catalan (ca), chinois (zh), néerlandais (nl), anglais (en), français (fr), allemand (de), hébreu (he), indonésien (id), italien (it), japonais (ja), coréen (ko), malais (ms), polonais (pl), portugais (pt), roumain (ro), russe (ru), espagnol (es), suédois (sv), thaï (th), turc (tr)

15. Collecter des champs personnalisés

Collectez des informations supplémentaires auprès des clients pendant le paiement à l’aide de champs personnalisés :
Les réponses aux champs personnalisés sont automatiquement incluses dans les payloads webhook (payment.succeeded, subscription.active, etc.) et peuvent être récupérées via l’API. Utilisez-les pour enrichir votre CRM, déclencher des flux d’intégration ou personnaliser l’expérience client.
Types de champs disponibles : text, number, email, url, date, dropdown, boolean

Prévisualiser les sessions de paiement

Avant de créer une session de paiement, vous pouvez prévisualiser le détail des prix, notamment les taxes, les remises et les totaux. Cette fonctionnalité est utile pour afficher des prix exacts aux clients avant qu’ils ne passent au paiement.
Lorsque le panier contient un produit par abonnement, la réponse de prévisualisation renvoie également un next_billing_date — un aperçu de la prochaine date de facturation, afin que vous puissiez l’afficher avant la création de l’abonnement. Il est calculé par rapport à l’heure actuelle : now + trial period lorsqu’un essai s’applique, sinon now + one payment frequency. Le champ est omis pour les paniers composés uniquement de paiements uniques. Il s’agit d’une estimation basée sur l’heure de prévisualisation ; le next_billing_date faisant foi est défini lors de l’activation de l’abonnement.
La prévisualisation renvoie également trial_period_days (la durée effective de l’essai, gratuit ou payant) et trial_amount (le montant de l’essai par unité après remises, dans les unités mineures de la devise du prix). trial_amount est présent uniquement pour un essai payant et vaut null pour un essai gratuit ou en l’absence d’essai. Utilisez current_breakup pour connaître le total taxé effectivement dû aujourd’hui.

Preview API Reference

Consultez la documentation complète de l’endpoint de prévisualisation.

Passer des liens dynamiques aux sessions de paiement

Principales différences

Auparavant, lors de la création d’un lien de paiement avec Dynamic Links, vous deviez fournir l’adresse de facturation complète du client. Avec les sessions de paiement, cela n’est plus nécessaire. Vous pouvez simplement transmettre les informations dont vous disposez et nous nous chargeons du reste. Par exemple :
  • Si vous connaissez uniquement le pays de facturation du client, fournissez simplement cette information.
  • Le flux de paiement collecte automatiquement les informations manquantes avant de diriger le client vers la page de paiement.
  • En revanche, si vous disposez déjà de toutes les informations requises et souhaitez accéder directement à la page de paiement, vous pouvez transmettre l’ensemble des données et inclure confirm=true dans le corps de votre requête.

Processus de migration

La migration de Dynamic Links vers les sessions de paiement est simple :
1

Update your integration

Mettez à jour votre intégration pour utiliser la nouvelle méthode de l’API ou du SDK.
2

Adjust request payload

Adaptez le payload de la requête au format des sessions de paiement.
3

That's it!

Oui. Aucune gestion supplémentaire ni étape de migration particulière n’est nécessaire de votre côté.

Référence API associée

Create Checkout Session

Référence API complète pour créer des sessions de paiement avec tous les paramètres et options disponibles

Preview Checkout Session

Référence API pour prévisualiser les prix, les taxes et les totaux avant de créer une session
Dernière modification le 31 juillet 2026