Quick Start
Platform Examples
Checkout Customization
Mobile Recipes
start(...)
tipizzata, con il recupero delle sessioni abbandonate integrato. Utilizza una WebView manuale solo
se nessuna di queste opzioni è adatta al tuo stack.Prerequisiti
Prima di integrare Dodo Payments nella tua app mobile, assicurati di avere:- Account Dodo Payments: account commerciante attivo con accesso API
- Credenziali API: chiave API e chiave segreta webhook dalla dashboard
- Progetto dell’app mobile: applicazione Android, iOS, React Native o Flutter
- Server backend: per gestire in modo sicuro la creazione delle sessioni di checkout
Flusso di integrazione
L’integrazione mobile segue un processo sicuro in 4 passaggi, in cui il backend gestisce le chiamate API e l’app mobile gestisce l’esperienza utente.status è solo un suggerimento per l’interfaccia su cosa mostrare all’utente. Concedi sempre l’accesso dal payment.succeeded / subscription.active webhook sul backend, mai dal solo risultato 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
Scegli il tuo SDK
Ogni SDK mobile espone lo stesso contratto: una singola chiamatastart(...) apre il
checkout ospitato di Dodo nella superficie browser nativa della piattaforma e restituisce un CheckoutResult tipizzato il cui status è succeeded, failed, cancelled,
pending o expired. Nessuno contiene una chiave API o chiama l’API Dodo
Payments e tutti e quattro supportano il recupero delle sessioni abbandonate.
Android
com.dodopayments.api:checkout-android apre una Chrome Custom Tab. Richiede minSdk 23.iOS
dodopayments-mobile-sdk-ios apre SFSafariViewController. Richiede iOS 16+.React Native
@dodopayments/react-native-checkout, un Turbo Module su entrambi i core nativi. Richiede React Native 0.76+.Flutter
dodopayments_checkout, un canale Pigeon su entrambi i core nativi. Richiede Flutter 3.44+.Registrazione di uno schema URL di callback
Tutti e quattro gli SDK restituiscono il controllo alla tua app tramite uno schema URL personalizzato che scegli tu, ad esempiomyapp://checkout/return. Registralo una volta per
piattaforma:
- Android
- iOS
- Expo
checkout_url nel browser di sistema
della piattaforma (Android Custom Tabs / iOS SFSafariViewController) e intercetta la
navigazione verso return_url, quindi leggi i parametri di query status e payment_id. Gli SDK sopra indicati fanno esattamente questo per te.Personalizzazione dell’aspetto
Ogni SDK accetta un parametro opzionalecustomization su start(...) /
CheckoutParams che controlla l’aspetto e il comportamento della superficie browser nativa: barra degli strumenti, pulsanti e presentazione. È separato dal tema della
pagina di checkout, che configuri lato server tramite
customization.theme_config nella
sessione di checkout.
Le opzioni sono raggruppate per piattaforma perché la Custom Tab di Android e
SFSafariViewController di iOS espongono controlli nativi diversi. Tutti i campi sono
opzionali; omettere completamente customization usa l’aspetto predefinito di ciascuna
piattaforma.
Android - Custom Tab
Android - Custom Tab
default mostra l’icona di sistema “X”; back disegna invece una freccia indietro.iOS - SFSafariViewController
iOS - SFSafariViewController
pageSheet viene presentato come una scheda con scorrimento per chiudere; fullScreen copre l’intero schermo.presentationStyle è fullScreen; pageSheet mantiene le barre fissate indipendentemente da questa impostazione.- React Native
- Flutter
- Android (Kotlin)
- iOS (Swift)
Personalizzazione della pagina di checkout
La sezione Personalizzazione dell’aspetto precedente controlla la superficie browser nativa: barra degli strumenti, pulsanti e combinazione di colori. La pagina di checkout in sé, ovvero i campi visualizzati, il tema e i metodi di pagamento mostrati, viene configurata lato server quando crei la sessione di checkout. Questi parametri hanno il maggiore impatto sulla conversione mobile. I parametri seguenti si trovano in tre posizioni diverse nella richiesta della sessione di checkout: la colonna Dove va inserito indica a quale oggetto appartiene ciascuno. Sbagliare questo punto è l’errore più comune: un parametro inserito nell’oggetto sbagliato viene ignorato silenziosamente.
show_order_details: false moves the contact and payment fields above the fold, instead of behind the order summary.
minimal_address: true per raccogliere solo un CAP invece dei campi completi per via, città e stato:

minimal_address: true reduces the billing address to a single postcode field.
theme: "system" affinché il checkout segua la preferenza del dispositivo per la modalità chiara o scura:

With theme: system, the checkout follows the device's light or dark appearance automatically.
Full checkout session parameter reference
Ricette ottimizzate per dispositivi mobili
Ogni ricetta seguente è un body completo della richiesta di una sessione di checkout. Copia quella corrispondente al tuo scenario, sostituisci il tuo ID prodotto e passala all’endpoint di creazione della sessione del 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 per saltare completamente il modulo di checkout.- Node.js SDK
- Python SDK
status nel ritorno del deep link è solo un suggerimento per l’interfaccia. Conferma l’accesso ascoltando il webhook payment.succeeded sul backend.Subscription with Free Trial - trial before first charge
Subscription with Free Trial - trial before first charge
- Node.js SDK
- Python SDK
subscription.active, non quando ritorna lo SDK mobile. Consulta Subscription Integration Guide per il flusso completo dei webhook.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
Flussi di abbonamento da dispositivi mobili
Gli abbonamenti vengono creati tramite lo stesso flusso di sessione di checkout usato per i pagamenti una tantum: lo SDK mobile apre il checkout ospitato, il cliente sottoscrive l’abbonamento e l’app gestisce il ritorno del deep link. Il ciclo di vita dell’abbonamento viene quindi gestito interamente dal backend.Abbonamenti ricorrenti standard
Per la fatturazione a intervalli fissi (mensile, annuale), crea una sessione di checkout con un prodotto in abbonamento e unreturn_url deep link. Il backend riceve subscription.active quando l’abbonamento viene confermato.
Abbonamenti on-demand
Gli abbonamenti on-demand consentono di autorizzare una volta il metodo di pagamento del cliente e di addebitare in seguito importi variabili: sono ideali per ricariche del wallet, pay-as-you-go e qualsiasi scenario in cui l’importo dell’addebito non sia noto in anticipo. Consulta la ricetta On-Demand Mandate sopra per il body completo della richiesta. Considerazioni mobile principali:- Imposta
show_on_demand_tag: falseaffinché la pagina di checkout non mostri il linguaggio “subscription” o “on-demand”. Nei casi d’uso di tokenizzazione delle carte, i clienti non si aspettano la terminologia degli abbonamenti. - Dopo l’autorizzazione del mandato, il backend riceve
subscription.active. Salvasubscription_id: lo userai per tutti gli addebiti futuri.
Abbonamento con prova gratuita
Passasubscription_data.trial_period_days nella sessione di checkout per offrire una prova prima del primo ciclo di fatturazione. Il cliente autorizza il metodo di pagamento durante la registrazione alla prova; il primo addebito avviene automaticamente al termine della prova. Consulta la ricetta Subscription with Free Trial sopra per il body completo della richiesta.
Upgrade e downgrade
Le modifiche al piano vengono effettuate tramite API sul backend, non attraverso una nuova sessione di checkout. Dodo Payments calcola automaticamente il prorating. Per offrire un’opzione self-service ai clienti, incorpora o collega al Customer Portal.Subscription Integration Guide
On-Demand Subscriptions
Upgrade / Downgrade
Customer Portal
Riduzione degli abbandoni durante il checkout
I checkout mobile registrano un abbandono maggiore rispetto al web: schermi più piccoli, più distrazioni e moduli più lunghi contribuiscono tutti al problema. I miglioramenti più rapidi derivano dalla configurazione della sessione di checkout stessa.Ottimizza il modulo
Precompila i dati del cliente
Ogni campo che il cliente non deve digitare è un motivo in meno per abbandonare:- Nuovi clienti: imposta
customer.emailecustomer.namedalla sessione di autenticazione. - Clienti abituali: imposta
customer.customer_idper precompilare automaticamente tutti i dati salvati. - Valuta: passa sempre
billing_currencyebilling_address.countryinsieme.
Strumenti di recupero
Abandoned Cart Recovery
Payment Retries
Subscription Dunning
Recovery Overview
Best practice
- Sicurezza: non inserire mai una chiave API nella tua app. Crea le sessioni di checkout sul backend e passa al client solo il
checkout_urlrisultante. - Autorità: tratta
CheckoutResult.statuscome un suggerimento per l’interfaccia. Concedi l’accesso solo dopo che il backend ha confermato il pagamento. - Esperienza utente: mostra uno stato di caricamento mentre il backend crea la sessione e gestisci
cancelledcome un risultato normale, non come un errore. - Test: usa la modalità test e le carte di test e verifica il percorso completo dell’URL di ritorno su un dispositivo reale e su un simulatore.
- Conversione: imposta
show_order_details: falseeminimal_address: trueper ottenere i migliori tassi di completamento del checkout mobile. Spostare i metodi di pagamento above the fold e ridurre i campi del modulo sono le due modifiche con il maggiore impatto. - Valuta: passa sempre esplicitamente
billing_currencyebilling_address.country; se manca uno dei due, Adaptive Currency può modificare la valuta di fatturazione in base all’indirizzo IP del cliente. - Fatturazione on-demand: imposta
show_on_demand_tag: falsequando usi abbonamenti on-demand per la tokenizzazione delle carte. I clienti che utilizzano un flusso di ricarica del wallet non si aspettano di vedere il linguaggio “subscription”. - Recupero: abilita il recupero dei carrelli abbandonati nella dashboard di Dodo Payments per coinvolgere nuovamente in modo automatico i clienti che non completano il checkout.
Risoluzione dei problemi
Problemi comuni
- Il callback non arriva mai: lo schema in
returnUrldeve corrispondere a quello registrato. Su Android è il placeholder del manifestdodoCallbackScheme; su iOS e React Native è il tipo URLInfo.plist. - Il checkout torna al browser invece che all’app (iOS): non hai inoltrato l’URL in arrivo. Chiama
DodoCheckout.handleOpenURL(url)da.onOpenURL,scene(_:openURLContexts:)o da un listenerLinkingdi React Native. PLATFORM_ERRORsu Android: nella maggior parte dei casi si tratta di una mancata corrispondenza dello schema. Può anche comparire seMainActivityimpostaandroid:taskAffinity=""(il valore predefinito standardflutter create), consentendo ad alcune build OEM di perdere il checkout in corso.ALREADY_IN_PROGRESS: un checkout è ancora aperto. Attendi o chiudi quello precedente prima di avviarne un altro.- La build fallisce a causa di un placeholder non risolto: hai aggiunto lo SDK Android ma non hai mai impostato
manifestPlaceholders["dodoCallbackScheme"]. - Il pagamento è riuscito ma l’accesso non è stato concesso: è previsto se utilizzi il risultato mobile come riferimento. Concedi invece l’accesso dal webhook
payment.succeeded/subscription.active. - Apple Pay / Google Pay non vengono mostrati su mobile: il checkout viene caricato in una WebView incorporata (
WKWebView/ AndroidWebView), che disabilita i wallet e può interrompere 3-D Secure. Aprilo invece con lo SDK o nel browser di sistema (Custom Tabs /SFSafariViewController).
Risorse aggiuntive
- Payment Integration Guide
- Webhook Documentation
- Testing Process
- Technical FAQs
- Checkout Session Customization
- On-Demand Subscriptions
- Subscription Upgrade/Downgrade
- Abandoned Cart Recovery
- Customer Portal
