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 :
Seul session_id est garanti d’être présent. Deux cas renvoient des champs supplémentaires ou en omettent certains :
  • payment_method_id a été fourni — la charge est traitée immédiatement et checkout_url est null. Utilisez plutôt le payment_id renvoyé.
  • confirm: true a créé le paiement lors de la création de la session — la réponse inclut également payment_id, client_secret et publishable_key à utiliser avec le SDK de paiement Dodo Payments.
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 pour plusieurs clients ou tentatives de paiement — créez une nouvelle session de paiement chaque fois que vous avez besoin d’un lien actualisé.
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 finaliser son achat.
Options d’intégration alternatives : Au lieu d’effectuer une redirection, vous pouvez intégrer directement le paiement dans votre page à l’aide de Overlay Checkout (fenêtre modale) ou d’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 incluant 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 requis pour chaque session de paiement

Optional Fields

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

Champs requis

array
requis
Tableau de produits à inclure dans la session de paiement. Chaque produit doit posséder un product_id valide provenant de votre tableau de bord Dodo Payments.
Paiement mixte : Vous pouvez combiner des produits à paiement unique et des produits par abonnement dans une même session de paiement. Cela permet des cas d’utilisation avancés tels que des frais de mise en place avec 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 Products → View Details, 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 client. Vous pouvez associer un client existant à l’aide de son ID ou créer une nouvelle fiche client pendant le paiement.
Associez un client existant à la session de paiement à l’aide de son ID.
object
Informations d’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 pendant le paiement. Cela permet d’optimiser l’expérience pour certains marchés ou exigences commerciales.Options courantes : credit, debit, upi_collect, apple_pay, google_pay, amazon_pay, klarna, affirm, afterpay_clearpay, cashapp, ach, multibanco, bancontact_card, eps, ideal, blik, paypal. Il ne s’agit pas de la liste complète — consultez la référence de l’API Create Checkout Session pour connaître toutes les valeurs acceptées.
Important : Incluez toujours credit et debit comme options de secours afin d’éviter les échecs de paiement lorsque les moyens de paiement préféré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 plus encoreExemple : "USD" pour les dollars américains, "EUR" pour les euros
Ce champ n’est effectif 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 enregistrés précédemment pour les clients existants afin d’accélérer le paiement et d’améliorer l’expérience utilisateur.
string
URL vers laquelle rediriger les clients une fois le paiement terminé. 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 permettre aux clients de retourner clairement sur votre site sans finaliser l’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 renvoie 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), jusqu’à un maximum 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 bénéficier 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 collecte uniquement :
  • Pays : Toujours requis pour déterminer les taxes
  • Code ZIP/postal : Uniquement dans les régions où il est nécessaire au calcul de la taxe de vente, de la TVA ou de la GST
Cela réduit considérablement les frictions lors du paiement en supprimant les champs de formulaire inutiles.
Activez l’adresse minimale pour finaliser le paiement plus rapidement. La collecte de l’adresse complète reste disponible pour les entreprises qui ont besoin de détails de facturation complets.
string
Un moyen de paiement enregistré appartenant au client associé. Nécessite confirm: true et un customer.customer_id existant. Lorsqu’il est défini, la charge est traitée immédiatement et checkout_url est renvoyé comme null — utilisez plutôt le payment_id renvoyé.
Si la valeur est true, renvoie une URL de paiement raccourcie au lieu de l’URL complète de la session.
string
ID de la collection de produits pour le flux de paiement fondé sur une collection.
string
ID fiscal du client (par exemple, un numéro de TVA). Nécessite billing_address avec un country.
string
Nom commercial ou légal facultatif associé à l’ID fiscal. Lorsqu’il est fourni avec un tax_id valide, il est affiché sur la facture à la place du nom personnel du client.
integer
Remplacez le seuil de mandat défini au niveau du marchand (en paises INR) pour les mandats électroniques INR sur les cartes indiennes.
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 pendant le 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 des webhooks et disponibles via l’API.
Les réponses des clients aux champs personnalisés sont incluses dans :
  • Webhooks : payment.succeeded, subscription.active et d’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 contenant plusieurs produits

3. Abonnement avec période d’essai

4. Paiement préconfirmé

Lorsque confirm est défini sur true, le client est dirigé directement 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 adaptative 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 existants

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 (Buy Now Pay Later)

Pour plus d’informations sur la configuration et les tests de BNPL, consultez la page Buy Now Pay Later (BNPL).

11. Utilisation de 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 :
Lors de l’utilisation de payment_method_id, confirm doit être défini sur true et un customer_id existant doit être fourni. Le moyen de paiement est validé pour vérifier sa compatibilité avec la devise du paiement. Comme la charge est traitée immédiatement, checkout_url est renvoyé comme null — utilisez plutôt le payment_id renvoyé.
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 existants.

12. Liens courts pour des URL de paiement plus claires

Générez des liens de paiement raccourcis et partageables avec des slugs personnalisés :
Les liens courts sont parfaits pour les SMS, les e-mails ou le partage 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 passer par 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 du paiement 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 immédiatement vers votre return_url une fois le paiement terminé, sans afficher la page de réussite par défaut.

14. Forcer une langue

Forcez le paiement à s’afficher dans une langue donnée, 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 des webhooks (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. Cela est utile pour afficher des prix précis 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 — une prévisualisation de la prochaine date de facturation, afin que vous puissiez l’afficher avant la création de l’abonnement. Elle est calculée par rapport à maintenant : 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 (les frais d’essai par unité après remises, dans les unités mineures de la devise du prix). trial_amount n’est présent que 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.

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 Checkout Sessions, ce 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 uniquement 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 Checkout Sessions est simple :
1

Update your integration

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

Adjust request payload

Adaptez le payload de la requête au format Checkout Sessions.
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 17 août 2026