Skip to main content

Quick Start

Lancez votre intégration des paiements mobiles en 4 étapes simples

Platform Examples

Exemples de code complets pour Android, iOS, React Native et Flutter

Checkout Customization

Configurez les thèmes, le préremplissage et 14 paramètres spécifiques au mobile

Mobile Recipes

Configurations de checkout à copier-coller pour 5 scénarios mobiles courants
Dodo Payments fournit un SDK de checkout officiel pour Android, iOS, React Native, et Flutter. Chacun encapsule le modèle documenté ci-dessous (ouvrir l’URL du checkout, capturer le retour et analyser le résultat) derrière un seul appel 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.
Le deep link 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.
1

Backend: Create Checkout Session

Checkout Session API Docs

Découvrez comment créer une session de checkout sur votre backend avec Node.js, Python et d’autres langages. Consultez les exemples complets et les références des paramètres dans la documentation dédiée de l’API Checkout Sessions.
Sécurité : les sessions de checkout doivent être créées sur votre serveur backend, jamais dans l’application mobile. Cela protège vos clés API et garantit une validation correcte.
2

Mobile: Get Checkout URL

Votre application mobile appelle votre backend pour obtenir l’URL du checkout. Authentifiez cette requête avec le propre jeton de session de l’utilisateur connecté.
Sécurité : les applications mobiles communiquent uniquement avec votre backend, jamais directement avec l’API Dodo Payments.
3

Mobile: Open Checkout in Browser

Ouvrez l’URL du checkout dans un navigateur intégré sécurisé pour traiter le paiement. Vous pouvez aussi éviter entièrement la configuration manuelle grâce au SDK de checkout officiel pour votre plateforme.

Pick your mobile SDK

Étapes d’installation et instructions de configuration pour Android, iOS, React Native et Flutter.
4

Backend: Handle Payment Completion

Traitez la finalisation du paiement via les webhooks et les URL de redirection afin de confirmer l’état du paiement.

Choisissez votre SDK

Chaque SDK mobile expose le même contrat : un appel start(...) 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.
Le status renvoyé est un indice d’interface, pas une preuve de paiement. Confirmez chaque paiement depuis votre backend via le webhook payment.succeeded / subscription.active, ou en récupérant le paiement avec votre clé secrète.

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 exemple myapp://checkout/return. Enregistrez-le une fois par plateforme :
android/app/build.gradle
Le manifest du SDK déclare déjà l’activité de redirection ; il n’est donc pas nécessaire d’ajouter du XML au manifest.
Vous préférez le construire vous-même ? Ouvrez le 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.
N’ouvrez pas le checkout dans une WebView intégrée (WKWebView / Android WebView). Il s’agit du problème le plus courant des intégrations mobiles : une WebView intégrée désactive Apple Pay et Google Pay, et peut également empêcher le fonctionnement des défis 3-D Secure et du préremplissage des cartes enregistrées. Les clients voient donc moins d’options de paiement et davantage d’échecs. Utilisez toujours le SDK ou ouvrez le checkout_url dans le navigateur système (Custom Tabs / SFSafariViewController). Cette surface de navigateur native est précisément ce qui permet à Apple Pay et Google Pay de continuer à fonctionner.

Personnalisation de l’apparence

Chaque SDK accepte un paramètre optionnel customization 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.
Color
Couleur d’arrière-plan de la barre d’outils.
Color
Couleur de la barre de navigation.
Color
Couleur du séparateur au-dessus de la barre de navigation.
'default' | 'back'
default affiche l’icône système « X » ; back dessine plutôt une flèche de retour.
'start' | 'end'
Indique le côté de la barre d’outils où apparaît le bouton de fermeture.
boolean
Affiche l’icône de partage de la barre d’outils.
boolean
Affiche le titre de la page sous l’URL dans la barre d’outils.
boolean
Permet à la barre d’outils de se masquer automatiquement lors du défilement.
boolean
Affiche « Ajouter cette page aux favoris » dans le menu Plus.
boolean
Affiche « Télécharger la page » dans le menu Plus.
'system' | 'light' | 'dark'
Force une apparence claire ou sombre, indépendamment du réglage système de l’appareil.
'done' | 'close' | 'cancel'
Libellé ou icône du bouton de fermeture.
'pageSheet' | 'fullScreen'
pageSheet se présente sous forme de carte avec un geste de balayage pour fermer ; fullScreen couvre tout l’écran.
boolean
Permet à la barre d’outils de se réduire lors du défilement. Visible uniquement lorsque presentationStyle vaut fullScreen ; pageSheet maintient les barres fixes quel que soit ce réglage.
'system' | 'light' | 'dark'
Force une apparence claire ou sombre, indépendamment du réglage système de l’appareil.

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.
Transmettez toujours billing_currency et billing_address.country ensemble. Si l’un des deux est omis, la devise adaptative peut modifier silencieusement la devise de facturation en fonction de l’adresse IP du client. Un marchand a vu un abonnement américain passer en EUR lorsque son client a voyagé en Europe, car le pays de facturation n’avait pas été défini explicitement.
Le plus grand levier de conversion sur mobile : définissez show_order_details: false et minimal_address: true. 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.
Checkout côte à côte : détails de la commande développés (champs sous la ligne de flottaison) contre réduits (champs en haut)

show_order_details: false moves the contact and payment fields above the fold, instead of behind the order summary.

Définissez minimal_address: true pour ne demander qu’un code postal au lieu des champs complets de rue, ville et région :
Checkout côte à côte : formulaire d’adresse de facturation complet contre code postal uniquement

minimal_address: true reduces the billing address to a single postcode field.

Définissez theme: "system" afin que le checkout respecte la préférence claire ou sombre de l’appareil :
Checkout côte à côte : même page affichée en mode clair et en mode sombre

With theme: system, the checkout follows the device's light or dark appearance automatically.

La disponibilité des moyens de paiement varie selon le type de produit. Apple Pay et Cash App sont pris en charge pour les abonnements récurrents non nuls. Pour les paiements ponctuels, tous les moyens activés sont disponibles.

Full checkout session parameter reference

Consultez tous les paramètres disponibles, leur type et leur valeur par défaut dans le guide Checkout Sessions.

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.
Utilisez cette configuration pour obtenir le formulaire le plus court possible : moyens de paiement en haut, seul un code postal requis pour l’adresse, aucun champ de réduction et un thème correspondant à l’appareil.
Consultez Checkout Sessions pour connaître tous les paramètres disponibles et leurs valeurs par défaut.
Utilisez cette configuration lorsque la page de checkout doit sembler intégrée à votre application. Définissez les couleurs de votre marque, une police personnalisée et un libellé de bouton de paiement localisé.
Checkout mobile aux couleurs de la marque avec une palette bleu marine sombre personnalisée appliquée via theme_config
theme_config accepte des objets dark et light distincts afin que la palette s’adapte à l’apparence actuelle de l’appareil. Consultez Checkout Sessions pour la référence complète des couleurs.
Utilisez cette configuration pour les utilisateurs connectés ayant déjà payé. Combinez un identifiant client, leur moyen de paiement enregistré et confirm: true pour ignorer entièrement le formulaire de checkout.
Le 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.
Utilisez cette configuration pour les produits d’abonnement qui proposent une période d’essai gratuite avant le premier cycle de facturation.
Accordez l’accès à la fonctionnalité lorsque votre backend reçoit le webhook 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.
Utilisez cette configuration pour tokeniser la carte d’un client en vue de paiements ultérieurs (rechargements de portefeuille, paiement à l’usage, BNPL) sans afficher de libellé « abonnement ». Le client autorise son moyen de paiement une seule fois ; vous facturez ensuite des montants variables à la demande.
C’est le modèle utilisé par les applications qui facturent selon l’utilisation — par exemple une application d’astrologie qui facture chaque session à partir d’une carte préautorisée, plutôt que selon un calendrier fixe.
Les frais à la demande nécessitent un minimum de 1 USD (100 cents). Les montants inférieurs à 1 USD seront rejetés avec "value out of range". Pour une autorisation d’un montant nul, utilisez mandate_only: true comme indiqué ci-dessus, puis facturez au moins 1 USD lors des appels suivants.
Consultez Abonnements à la demande pour découvrir le flux complet des frais, les événements de webhook et les politiques de nouvelle tentative.

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 link return_url. Votre backend reçoit subscription.active lorsque l’abonnement est confirmé.
Apple Pay et Cash App sont pris en charge pour les abonnements récurrents non nuls.
Pour connaître le flux complet des webhooks côté backend, consultez le Guide d’intégration des abonnements.

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: false afin 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. Enregistrez subscription_id : vous l’utiliserez pour tous les frais ultérieurs.
Le montant minimum est de 1 USD (100 cents). Les frais à la demande inférieurs à 1 USD seront rejetés avec "value out of range". Facturez au moins 1 USD ou utilisez mandate_only: true pour autoriser le paiement sans facturer et prélever le premier montant réel ultérieurement.
Évitez les nouvelles tentatives rapprochées. Si un paiement précédent est encore en cours de traitement, un nouveau paiement sur le même abonnement échoue avec "Cannot create new charge as previous payment is not successful yet". Cela est particulièrement fréquent avec les moyens de paiement indiens (UPI, cartes de débit/crédit indiennes), pour lesquels les règles de mandat de la RBI peuvent maintenir une transaction en cours de traitement pendant 48 heures. Ajoutez une vérification de délai d’attente dans votre logique de paiement avant toute nouvelle tentative.
Consultez Abonnements à la demande pour connaître l’endpoint de paiement complet, les événements de webhook et les politiques de nouvelle tentative.

Abonnement avec essai gratuit

Transmettez subscription_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

Configuration complète du backend : flux des webhooks, attribution des accès et annulation

On-Demand Subscriptions

Autorisation des mandats, frais variables et politiques de nouvelle tentative

Upgrade / Downgrade

Stratégies de proratisation, changements de forfait et ajustements du nombre de sièges

Customer Portal

Gestion des abonnements en libre-service pour vos clients

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.email et customer.name à partir de votre session d’authentification.
  • Clients récurrents — définissez customer.customer_id pour préremplir automatiquement toutes les informations enregistrées.
  • Devise — transmettez toujours billing_currency et billing_address.country ensemble.

Outils de récupération

Abandoned Cart Recovery

Séquences d’e-mails automatisées pour les checkouts incomplets

Payment Retries

Logique intelligente de nouvelle tentative pour les renouvellements d’abonnement échoués

Subscription Dunning

E-mails de réengagement pour les abonnements arrivés à expiration

Recovery Overview

Tous les outils de récupération et leur impact cumulé sur les revenus
Testez les e-mails d’abandon de panier avant de les activer. Créez une session de checkout en mode live et saisissez des informations de carte invalides. Le paiement échoué déclenche le flux d’e-mail de récupération, ce qui vous permet de prévisualiser exactement ce que vos clients recevront.

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_url obtenu au client.
  • Autorité : considérez CheckoutResult.status comme 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 cancelled comme 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: false et minimal_address: true pour 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_currency et billing_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: false lorsque 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 returnUrl doit correspondre à celui que vous avez enregistré. Sur Android, il s’agit du placeholder de manifest dodoCallbackScheme ; sur iOS et React Native, il s’agit du type d’URL Info.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 Native Linking.
  • PLATFORM_ERROR sur Android : il s’agit le plus souvent d’une incompatibilité de schéma. Cela peut également se produire lorsque votre MainActivity définit android:taskAffinity="" (la valeur par défaut standard flutter 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 / Android WebView), 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

Pour toute question ou demande d’assistance, contactez support@dodopayments.com.
Dernière modification le 21 août 2026