Quick Start
Platform Examples
Checkout Customization
Mobile Recipes
start(...)
typé, avec une récupération intégrée des sessions abandonnées. Utilisez une WebView
manuelle uniquement si aucune de ces solutions ne convient à votre stack.Prérequis
Avant d’intégrer Dodo Payments à votre application mobile, vérifiez que vous disposez des éléments suivants :- Compte Dodo Payments : compte marchand actif avec accès à l’API
- Identifiants API : clé API et clé secrète de webhook depuis votre tableau de bord
- Projet d’application mobile : application Android, iOS, React Native ou Flutter
- Serveur backend : pour gérer de manière sécurisée la création des sessions de checkout
Flux d’intégration
L’intégration mobile suit un processus sécurisé en 4 étapes : votre backend gère les appels API et votre application mobile gère l’expérience utilisateur.status est uniquement un indice d’interface indiquant ce qu’il faut afficher à l’utilisateur. Accordez toujours l’accès à partir du webhook payment.succeeded / subscription.active sur votre backend — jamais à partir du seul résultat mobile.Backend: Create Checkout Session
Checkout Session API Docs
Mobile: Get Checkout URL
- iOS (Swift)
- Android (Kotlin)
- React Native (JavaScript)
- Flutter (Dart)
Mobile: Open Checkout in Browser
Pick your mobile SDK
Backend: Handle Payment Completion
Choisissez votre SDK
Chaque SDK mobile expose le même contrat : un appelstart(...) ouvre le checkout hébergé de Dodo dans la surface de navigateur native de la plateforme et renvoie un CheckoutResult typé dont le status est succeeded, failed, cancelled, pending ou expired. Aucun ne contient de clé API ni n’appelle l’API Dodo Payments, et les quatre prennent en charge la récupération des sessions abandonnées.
Android
com.dodopayments.api:checkout-android ouvre un Chrome Custom Tab. Nécessite minSdk 23.iOS
dodopayments-mobile-sdk-ios ouvre SFSafariViewController. Nécessite iOS 16 ou version ultérieure.React Native
@dodopayments/react-native-checkout, un Turbo Module sur les deux cœurs natifs. Nécessite React Native 0.76 ou version ultérieure.Flutter
dodopayments_checkout, un canal Pigeon sur les deux cœurs natifs. Nécessite Flutter 3.44 ou version ultérieure.Enregistrement d’un schéma d’URL de callback
Les quatre SDK redonnent le contrôle à votre application via un schéma d’URL personnalisé que vous choisissez, par exemplemyapp://checkout/return. Enregistrez-le une fois par
plateforme :
- Android
- iOS
- Expo
checkout_url dans le navigateur système de la plateforme (Android Custom Tabs / iOS SFSafariViewController), interceptez la navigation vers votre return_url, puis lisez les paramètres de requête status et payment_id. Les SDK ci-dessus s’en chargent pour vous.Personnalisation de l’apparence
Chaque SDK accepte un paramètre optionnelcustomization sur start(...) /
CheckoutParams qui contrôle l’apparence et le comportement de la surface de navigateur native : barre d’outils, boutons et présentation. Cela est indépendant du thème de la page de checkout, que vous configurez côté serveur via customization.theme_config dans la session de checkout.
Les options sont regroupées par plateforme, car l’onglet personnalisé d’Android et le SFSafariViewController d’iOS exposent des contrôles natifs différents. Tous les champs sont facultatifs ; si vous omettez entièrement customization, l’apparence par défaut de chaque plateforme est utilisée.
Android - Custom Tab
Android - Custom Tab
default affiche l’icône système « X » ; back dessine plutôt une flèche de retour.iOS - SFSafariViewController
iOS - SFSafariViewController
pageSheet se présente sous forme de carte avec un geste de balayage pour fermer ; fullScreen couvre tout l’écran.presentationStyle vaut fullScreen ; pageSheet maintient les barres fixes quel que soit ce réglage.- React Native
- Flutter
- Android (Kotlin)
- iOS (Swift)
Personnalisation de la page de checkout
La section Personnalisation de l’apparence ci-dessus contrôle la surface de navigateur native : barre d’outils, boutons et palette de couleurs. La page de checkout elle-même — champs affichés, thème et moyens de paiement — est configurée côté serveur lors de la création de la session de checkout. Ces paramètres ont le plus d’impact sur la conversion mobile. Les paramètres ci-dessous se trouvent à trois endroits différents de la requête de session de checkout ; la colonne Emplacement indique à quel objet chacun appartient. C’est l’erreur la plus courante : un paramètre placé dans le mauvais objet est ignoré silencieusement.
show_order_details: false moves the contact and payment fields above the fold, instead of behind the order summary.
minimal_address: true pour ne demander qu’un code postal au lieu des champs complets de rue, ville et région :

minimal_address: true reduces the billing address to a single postcode field.
theme: "system" afin que le checkout respecte la préférence claire ou sombre de l’appareil :

With theme: system, the checkout follows the device's light or dark appearance automatically.
Full checkout session parameter reference
Recettes optimisées pour le mobile
Chaque recette ci-dessous correspond au corps complet d’une requête de session de checkout. Copiez celle qui correspond à votre scénario, remplacez-la par l’identifiant de votre produit et transmettez-la à l’endpoint de création de session de votre backend.Minimal Mobile Checkout - fastest path to payment
Minimal Mobile Checkout - fastest path to payment
- Node.js SDK
- Python SDK
One-Click Returning Customer - saved card, instant confirmation
One-Click Returning Customer - saved card, instant confirmation
confirm: true pour ignorer entièrement le formulaire de checkout.- Node.js SDK
- Python SDK
status du retour par deep link est uniquement un indice d’interface. Confirmez l’accès en écoutant le webhook payment.succeeded sur votre backend.Subscription with Free Trial - trial before first charge
Subscription with Free Trial - trial before first charge
- Node.js SDK
- Python SDK
subscription.active — et non lorsque le SDK mobile renvoie un résultat. Consultez le Guide d’intégration des abonnements pour connaître le flux complet des webhooks.On-Demand Mandate - save a card for future variable charges
On-Demand Mandate - save a card for future variable charges
- Node.js SDK
- Python SDK
Flux d’abonnement depuis un appareil mobile
Les abonnements sont créés via le même flux de session de checkout que les paiements ponctuels : le SDK mobile ouvre le checkout hébergé, le client s’abonne et votre application gère le retour par deep link. Le cycle de vie de l’abonnement est ensuite entièrement géré sur le backend.Abonnements récurrents classiques
Pour une facturation à intervalle fixe (mensuelle ou annuelle), créez une session de checkout avec un produit d’abonnement et un deep linkreturn_url. Votre backend reçoit subscription.active lorsque l’abonnement est confirmé.
Abonnements à la demande
Les abonnements à la demande permettent d’autoriser le moyen de paiement d’un client une seule fois, puis de facturer des montants variables ultérieurement — idéal pour les rechargements de portefeuille, le paiement à l’usage et tout scénario où le montant n’est pas connu à l’avance. Consultez la recette Mandat à la demande ci-dessus pour voir le corps complet de la requête. Points importants pour le mobile :- Définissez
show_on_demand_tag: falseafin que la page de checkout n’affiche pas les termes « abonnement » ou « à la demande ». Pour les cas d’usage de tokenisation de cartes, les clients ne s’attendent pas à voir une terminologie liée aux abonnements. - Une fois le mandat autorisé, votre backend reçoit
subscription.active. Enregistrezsubscription_id: vous l’utiliserez pour tous les frais ultérieurs.
Abonnement avec essai gratuit
Transmettezsubscription_data.trial_period_days dans la session de checkout pour proposer un essai avant le premier cycle de facturation. Le client autorise son moyen de paiement lors de l’inscription à l’essai ; le premier prélèvement est effectué automatiquement à la fin de l’essai. Consultez la recette Abonnement avec essai gratuit ci-dessus pour voir le corps complet de la requête.
Mises à niveau et rétrogradations
Les changements de forfait sont effectués via l’API sur votre backend, et non via une nouvelle session de checkout. Dodo Payments calcule automatiquement le prorata. Pour proposer une option en libre-service aux clients, intégrez ou liez le Customer Portal.Subscription Integration Guide
On-Demand Subscriptions
Upgrade / Downgrade
Customer Portal
Réduire les abandons lors du checkout
Les checkouts mobiles enregistrent davantage d’abandons que les checkouts web : écrans plus petits, distractions plus nombreuses et formulaires plus longs y contribuent tous. Les améliorations les plus rapides viennent de la configuration de la session de checkout elle-même.Optimiser le formulaire
Préremplir les données client
Chaque champ que le client n’a pas besoin de saisir est une raison de moins d’abandonner :- Nouveaux clients — définissez
customer.emailetcustomer.nameà partir de votre session d’authentification. - Clients récurrents — définissez
customer.customer_idpour préremplir automatiquement toutes les informations enregistrées. - Devise — transmettez toujours
billing_currencyetbilling_address.countryensemble.
Outils de récupération
Abandoned Cart Recovery
Payment Retries
Subscription Dunning
Recovery Overview
Bonnes pratiques
- Sécurité : n’intégrez jamais de clé API dans votre application. Créez les sessions de checkout sur votre backend et transmettez uniquement le
checkout_urlobtenu au client. - Autorité : considérez
CheckoutResult.statuscomme un indice d’interface. Accordez l’accès uniquement après confirmation du paiement par votre backend. - Expérience utilisateur : affichez un état de chargement pendant que votre backend crée la session et traitez
cancelledcomme un résultat normal, et non comme une erreur. - Tests : utilisez le mode test et des cartes de test, puis vérifiez le parcours de l’URL de retour sur un appareil réel et dans un simulateur.
- Conversion : définissez
show_order_details: falseetminimal_address: truepour obtenir les meilleurs taux de finalisation du checkout mobile. Placer les moyens de paiement au-dessus de la ligne de flottaison et réduire le nombre de champs sont les deux changements les plus efficaces. - Devise : transmettez toujours explicitement
billing_currencyetbilling_address.country; si l’un des deux manque, la devise adaptative peut modifier la devise de facturation selon l’adresse IP du client. - Facturation à la demande : définissez
show_on_demand_tag: falselorsque vous utilisez des abonnements à la demande pour la tokenisation de cartes. Les clients qui utilisent un flux de rechargement de portefeuille ne s’attendent pas à voir le terme « abonnement ». - Récupération : activez la récupération des paniers abandonnés dans votre tableau de bord Dodo Payments afin de réengager automatiquement les clients qui ne finalisent pas leur checkout.
Résolution des problèmes
Problèmes courants
- Le callback n’arrive jamais : le schéma dans
returnUrldoit correspondre à celui que vous avez enregistré. Sur Android, il s’agit du placeholder de manifestdodoCallbackScheme; sur iOS et React Native, il s’agit du type d’URLInfo.plist. - Le checkout revient dans le navigateur au lieu de revenir dans votre application (iOS) : vous n’avez pas transmis l’URL entrante. Appelez
DodoCheckout.handleOpenURL(url)depuis.onOpenURL,scene(_:openURLContexts:)ou un écouteur React NativeLinking. PLATFORM_ERRORsur Android : il s’agit le plus souvent d’une incompatibilité de schéma. Cela peut également se produire lorsque votreMainActivitydéfinitandroid:taskAffinity=""(la valeur par défaut standardflutter create), ce qui peut faire perdre le checkout en cours à certaines versions OEM.ALREADY_IN_PROGRESS: un checkout est encore ouvert. Attendez sa fin ou fermez-le avant d’en démarrer un autre.- Échec de compilation avec un placeholder non résolu : vous avez ajouté le SDK Android sans jamais définir
manifestPlaceholders["dodoCallbackScheme"]. - Paiement réussi, mais accès non accordé : c’est attendu si vous vous basez sur le résultat mobile. Accordez plutôt l’accès à partir du webhook
payment.succeeded/subscription.active. - Apple Pay / Google Pay ne s’affichent pas sur mobile : le checkout est chargé dans une WebView intégrée (
WKWebView/ AndroidWebView), qui masque les wallets et peut empêcher 3-D Secure de fonctionner. Ouvrez-le avec le SDK ou dans le navigateur système (Custom Tabs /SFSafariViewController).
Ressources supplémentaires
- Guide d’intégration des paiements
- Documentation des webhooks
- Processus de test
- FAQ techniques
- Personnalisation de la session de checkout
- Abonnements à la demande
- Mise à niveau/rétrogradation d’un abonnement
- Récupération des paniers abandonnés
- Customer Portal
