Skip to main content

Quick Start

Attiva l’integrazione dei pagamenti mobile in 4 semplici passaggi

Platform Examples

Esempi di codice completi per Android, iOS, React Native e Flutter

Checkout Customization

Configura temi, precompilazione e 14 parametri specifici per dispositivi mobili

Mobile Recipes

Configurazioni del checkout da copiare e incollare per 5 scenari mobile comuni
Dodo Payments fornisce un SDK ufficiale per il checkout per Android, iOS, React Native, e Flutter. Ognuno incapsula il pattern documentato di seguito (aprire l’URL del checkout, acquisire il ritorno e analizzare il risultato) dietro una singola chiamata 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.
Il deep link 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.
1

Backend: Create Checkout Session

Checkout Session API Docs

Scopri come creare una sessione di checkout nel backend usando Node.js, Python e altro. Consulta gli esempi completi e i riferimenti ai parametri nella documentazione dedicata dell’API Checkout Sessions.
Sicurezza: le sessioni di checkout devono essere create sul server backend, mai nell’app mobile. In questo modo proteggi le chiavi API e garantisci una validazione corretta.
2

Mobile: Get Checkout URL

La tua app mobile chiama il backend per ottenere l’URL del checkout. Autentica questa richiesta con il token di sessione dell’utente che ha effettuato l’accesso.
Sicurezza: le app mobili comunicano solo con il backend, mai direttamente con l’API Dodo Payments.
3

Mobile: Open Checkout in Browser

Apri l’URL del checkout in un browser in-app sicuro per elaborare il pagamento. Oppure evita del tutto la configurazione manuale usando l’SDK ufficiale per il checkout della tua piattaforma.

Pick your mobile SDK

Passaggi di installazione e istruzioni di configurazione per Android, iOS, React Native e Flutter.
4

Backend: Handle Payment Completion

Gestisci il completamento del pagamento tramite webhook e URL di reindirizzamento per confermare lo stato del pagamento.

Scegli il tuo SDK

Ogni SDK mobile espone lo stesso contratto: una singola chiamata start(...) 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+.
L’status restituito è un suggerimento per l’interfaccia, non una prova del pagamento. Conferma ogni pagamento dal backend tramite il webhook payment.succeeded / subscription.active, o recuperando il pagamento con la tua chiave segreta.

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 esempio myapp://checkout/return. Registralo una volta per piattaforma:
android/app/build.gradle
Il manifest dello SDK dichiara già l’attività di reindirizzamento, quindi non è necessario aggiungere XML al manifest.
Preferisci costruirlo autonomamente? Apri 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.
Non aprire il checkout all’interno di una WebView incorporata (WKWebView / Android WebView). Questo è il problema più comune nelle integrazioni mobile: una WebView incorporata disabilita Apple Pay e Google Pay e può anche interrompere le verifiche 3-D Secure e la compilazione automatica delle carte salvate, così i clienti vedono meno opzioni di pagamento e più errori. Usa sempre lo SDK oppure apri checkout_url nel browser di sistema (Custom Tabs / SFSafariViewController). Questa superficie browser nativa è esattamente il motivo per cui Apple Pay e Google Pay continuano a funzionare.

Personalizzazione dell’aspetto

Ogni SDK accetta un parametro opzionale customization 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.
Color
Colore di sfondo della barra degli strumenti.
Color
Colore della barra di navigazione.
Color
Colore del divisore sopra la barra di navigazione.
'default' | 'back'
default mostra l’icona di sistema “X”; back disegna invece una freccia indietro.
'start' | 'end'
Lato della barra degli strumenti in cui appare il pulsante di chiusura.
boolean
Mostra l’icona di condivisione della barra degli strumenti.
boolean
Mostra il titolo della pagina sotto l’URL nella barra degli strumenti.
boolean
Consente alla barra degli strumenti di nascondersi automaticamente durante lo scorrimento della pagina.
boolean
Mostra “Aggiungi pagina ai preferiti” nel menu overflow.
boolean
Mostra “Scarica pagina” nel menu overflow.
'system' | 'light' | 'dark'
Forza l’aspetto chiaro o scuro indipendentemente dall’impostazione di sistema del dispositivo.
'done' | 'close' | 'cancel'
Etichetta o icona per il pulsante di chiusura.
'pageSheet' | 'fullScreen'
pageSheet viene presentato come una scheda con scorrimento per chiudere; fullScreen copre l’intero schermo.
boolean
Consente alla barra degli strumenti di comprimersi durante lo scorrimento. Visibile solo quando presentationStyle è fullScreen; pageSheet mantiene le barre fissate indipendentemente da questa impostazione.
'system' | 'light' | 'dark'
Forza l’aspetto chiaro o scuro indipendentemente dall’impostazione di sistema del dispositivo.

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.
Passa sempre billing_currency e billing_address.country insieme. Se uno dei due viene omesso, Adaptive Currency può cambiare silenziosamente la valuta di fatturazione in base all’indirizzo IP del cliente. Un commerciante ha visto un abbonamento statunitense passare a EUR quando il cliente si è recato in Europa, perché il paese di fatturazione non era stato impostato esplicitamente.
Il maggiore incremento singolo della conversione su mobile: imposta show_order_details: false e minimal_address: true. Spostare i metodi di pagamento above the fold e ridurre i campi del modulo sono le due modifiche con il maggiore impatto.
Confronto affiancato del checkout: dettagli dell'ordine espansi (campi sotto la piega) e compressi (campi in alto)

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

Imposta minimal_address: true per raccogliere solo un CAP invece dei campi completi per via, città e stato:
Confronto affiancato del checkout: modulo completo dell'indirizzo di fatturazione e solo CAP

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

Imposta theme: "system" affinché il checkout segua la preferenza del dispositivo per la modalità chiara o scura:
Confronto affiancato del checkout: la stessa pagina visualizzata in modalità chiara e scura

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

La disponibilità dei metodi di pagamento varia in base al tipo di prodotto. Apple Pay e Cash App sono supportati per gli abbonamenti ricorrenti non a importo zero. Per i pagamenti una tantum, sono disponibili tutti i metodi abilitati.

Full checkout session parameter reference

Consulta ogni parametro disponibile, il tipo e il valore predefinito nella guida Checkout Sessions.

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.
Usalo quando vuoi il modulo più breve possibile: metodi di pagamento in alto, solo il CAP richiesto per l’indirizzo, nessun campo per gli sconti e tema corrispondente al dispositivo.
Consulta Checkout Sessions per tutti i parametri disponibili e i relativi valori predefiniti.
Usalo quando la pagina di checkout deve sembrare parte della tua app. Imposta i colori del brand, un carattere personalizzato e un’etichetta localizzata per il pulsante di pagamento.
Checkout mobile brandizzato con una palette blu navy scuro personalizzata applicata tramite theme_config
theme_config accetta oggetti separati dark e light, così la palette si adatta all’aspetto attuale del dispositivo. Consulta Checkout Sessions per il riferimento completo ai colori.
Usalo per gli utenti autenticati che hanno già effettuato un pagamento. Combina un ID cliente, il relativo metodo di pagamento salvato e confirm: true per saltare completamente il modulo di checkout.
L’status nel ritorno del deep link è solo un suggerimento per l’interfaccia. Conferma l’accesso ascoltando il webhook payment.succeeded sul backend.
Usalo per i prodotti in abbonamento che offrono un periodo di prova gratuito prima del primo ciclo di fatturazione.
Concedi l’accesso alla funzionalità quando il backend riceve il webhook subscription.active, non quando ritorna lo SDK mobile. Consulta Subscription Integration Guide per il flusso completo dei webhook.
Usalo per tokenizzare la carta di un cliente per addebiti futuri (ricariche del wallet, pay-as-you-go, BNPL) senza mostrare l’etichetta “subscription”. Il cliente autorizza una volta il metodo di pagamento; in seguito addebiti importi variabili on demand.
Questo è il pattern usato dalle app che addebitano in base all’utilizzo, ad esempio un’app di astrologia che addebita ogni sessione da una carta preautorizzata, anziché secondo una pianificazione fissa.
Gli addebiti on-demand richiedono un minimo di 1 USD (100 centesimi). Gli importi inferiori a 1 USD verranno rifiutati con "value out of range". Per un’autorizzazione a importo zero, usa mandate_only: true come mostrato sopra, quindi addebita almeno 1 USD nelle chiamate successive.
Consulta On-Demand Subscriptions per il flusso completo degli addebiti, gli eventi webhook e le policy di retry.

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 un return_url deep link. Il backend riceve subscription.active quando l’abbonamento viene confermato.
Apple Pay e Cash App sono supportati per gli abbonamenti ricorrenti non a importo zero.
Per il flusso completo dei webhook backend, consulta la Subscription Integration Guide.

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: false affinché 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. Salva subscription_id: lo userai per tutti gli addebiti futuri.
L’addebito minimo è di 1 USD (100 centesimi). Gli addebiti on-demand inferiori a 1 USD verranno rifiutati con "value out of range". Addebita almeno 1 USD oppure usa mandate_only: true per autorizzare senza addebitare e riscuotere il primo importo effettivo in seguito.
Evita i retry ravvicinati. Se un addebito precedente è ancora in elaborazione, un nuovo addebito sullo stesso abbonamento fallisce con "Cannot create new charge as previous payment is not successful yet". Questo è particolarmente comune con i metodi di pagamento indiani (UPI, carte di debito/credito indiane), per i quali le regole RBI possono mantenere una transazione nello stato di elaborazione fino a 48 ore. Aggiungi un controllo di cooldown alla logica degli addebiti prima di riprovare.
Consulta On-Demand Subscriptions per l’endpoint completo degli addebiti, gli eventi webhook e le policy di retry.

Abbonamento con prova gratuita

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

Configurazione completa del backend: flusso webhook, concessione dell’accesso e annullamento

On-Demand Subscriptions

Autorizzazione del mandato, addebiti variabili e policy di retry

Upgrade / Downgrade

Strategie di prorating, modifiche al piano e adeguamenti dei posti

Customer Portal

Gestione self-service degli abbonamenti per i clienti

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.email e customer.name dalla sessione di autenticazione.
  • Clienti abituali: imposta customer.customer_id per precompilare automaticamente tutti i dati salvati.
  • Valuta: passa sempre billing_currency e billing_address.country insieme.

Strumenti di recupero

Abandoned Cart Recovery

Sequenze email automatizzate per checkout incompleti

Payment Retries

Logica di retry intelligente per rinnovi di abbonamenti falliti

Subscription Dunning

Email di re-engagement per abbonamenti scaduti

Recovery Overview

Tutti gli strumenti di recupero e il loro impatto combinato sui ricavi
Testa le email di abbandono del carrello prima di abilitarle. Crea una sessione di checkout in modalità live e inserisci dati di una carta non validi. Il pagamento fallito attiva il flusso email di recupero, consentendoti di visualizzare in anteprima esattamente ciò che riceveranno i clienti.

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_url risultante.
  • Autorità: tratta CheckoutResult.status come 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 cancelled come 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: false e minimal_address: true per 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_currency e billing_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: false quando 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 returnUrl deve corrispondere a quello registrato. Su Android è il placeholder del manifest dodoCallbackScheme; su iOS e React Native è il tipo URL Info.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 listener Linking di React Native.
  • PLATFORM_ERROR su Android: nella maggior parte dei casi si tratta di una mancata corrispondenza dello schema. Può anche comparire se MainActivity imposta android:taskAffinity="" (il valore predefinito standard flutter 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 / Android WebView), 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

Per domande o assistenza, contatta support@dodopayments.com.
Ultima modifica il 21 agosto 2026