Quick Start
Platform Examples
Checkout Customization
Mobile Recipes
start(...) tipada, com recuperação de sessões abandonadas integrada. Use uma WebView manual somente
se nenhuma dessas opções for adequada à sua stack.Pré-requisitos
Antes de integrar Dodo Payments ao seu aplicativo móvel, verifique se você tem:- Conta Dodo Payments: conta de comerciante ativa com acesso à API
- Credenciais da API: chave de API e chave secreta de webhook do seu dashboard
- Projeto de aplicativo móvel: aplicativo Android, iOS, React Native ou Flutter
- Servidor de backend: para lidar com segurança com a criação de sessões de checkout
Fluxo de integração
A integração móvel segue um processo seguro de 4 etapas, no qual seu backend gerencia as chamadas de API e seu aplicativo móvel gerencia a experiência do usuário.status é apenas uma dica de UI sobre o que mostrar ao usuário. Sempre conceda acesso a partir do webhook payment.succeeded / subscription.active no seu backend — nunca somente a partir do resultado móvel.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
Escolha seu SDK
Todos os SDKs móveis expõem o mesmo contrato: uma única chamadastart(...) abre o checkout hospedado da Dodo na superfície de navegador nativa da plataforma e retorna um CheckoutResult tipado cujo status é succeeded, failed, cancelled, pending ou expired. Nenhum deles armazena uma chave de API ou chama a Dodo Payments API, e os quatro oferecem suporte à recuperação de sessões abandonadas.
Android
com.dodopayments.api:checkout-android abre uma Chrome Custom Tab. Requer minSdk 23.iOS
dodopayments-mobile-sdk-ios abre SFSafariViewController. Requer iOS 16 ou superior.React Native
@dodopayments/react-native-checkout, um Turbo Module sobre os dois núcleos nativos. Requer React Native 0.76 ou superior.Flutter
dodopayments_checkout, um canal Pigeon sobre os dois núcleos nativos. Requer Flutter 3.44 ou superior.Registrando um esquema de URL de callback
Os quatro SDKs devolvem o controle ao seu aplicativo por meio de um esquema de URL personalizado que você escolhe, por exemplo,myapp://checkout/return. Registre-o uma vez por
plataforma:
- Android
- iOS
- Expo
checkout_url no navegador do sistema da plataforma (Android Custom Tabs / iOS SFSafariViewController), intercepte a navegação para seu return_url e leia os parâmetros de consulta status e payment_id. Os SDKs acima fazem exatamente isso por você.Personalização da aparência
Todos os SDKs aceitam um parâmetro opcionalcustomization em start(...) / CheckoutParams que controla a aparência e o comportamento da superfície de navegador nativa — a barra de ferramentas, os botões e a apresentação. Isso é separado do tema da própria página de checkout, que você configura no servidor por meio de customization.theme_config na sessão de checkout.
As opções são agrupadas por plataforma porque a Custom Tab do Android e a SFSafariViewController do iOS expõem controles nativos diferentes. Todos os campos são opcionais; omitir completamente customization usa a aparência padrão de cada plataforma.
Android - Custom Tab
Android - Custom Tab
default exibe o ícone de sistema “X”; back desenha uma seta de voltar.iOS - SFSafariViewController
iOS - SFSafariViewController
pageSheet é apresentado como um cartão com deslize para dispensar; fullScreen cobre a tela inteira.presentationStyle é fullScreen — pageSheet mantém as barras fixas independentemente desta configuração.- React Native
- Flutter
- Android (Kotlin)
- iOS (Swift)
Personalização da página de checkout
A seção Personalização da aparência acima controla a superfície de navegador nativa — barra de ferramentas, botões e esquema de cores. A própria página de checkout — quais campos aparecem, o tema e quais métodos de pagamento são exibidos — é configurada no servidor quando você cria a sessão de checkout. Esses parâmetros têm o maior impacto na conversão em dispositivos móveis. Os parâmetros abaixo ficam em três locais diferentes na solicitação da sessão de checkout — a coluna Onde fica informa em qual objeto cada um deve ser colocado. Errar isso é o erro mais comum: um parâmetro colocado no objeto errado é ignorado silenciosamente.
show_order_details: false moves the contact and payment fields above the fold, instead of behind the order summary.
minimal_address: true para coletar apenas um CEP, em vez dos campos completos de rua, cidade e estado:

minimal_address: true reduces the billing address to a single postcode field.
theme: "system" para que o checkout siga a preferência de modo claro ou escuro do dispositivo:

With theme: system, the checkout follows the device's light or dark appearance automatically.
Full checkout session parameter reference
Receitas otimizadas para dispositivos móveis
Cada receita abaixo é o corpo completo de uma solicitação de sessão de checkout. Copie a que corresponde ao seu cenário, substitua pelo ID do seu produto e envie-a ao endpoint de criação de sessão do seu 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 para ignorar completamente o formulário de checkout.- Node.js SDK
- Python SDK
status no retorno do deep link é apenas uma dica de UI. Confirme o acesso monitorando o webhook payment.succeeded no seu backend.Subscription with Free Trial - trial before first charge
Subscription with Free Trial - trial before first charge
- Node.js SDK
- Python SDK
subscription.active — não quando o SDK móvel retornar. Consulte o Guia de integração de assinaturas para ver o fluxo completo do 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
Fluxos de assinatura em dispositivos móveis
As assinaturas são criadas por meio do mesmo fluxo de sessão de checkout usado para pagamentos únicos — o SDK móvel abre o checkout hospedado, o cliente assina e seu aplicativo processa o retorno do deep link. O ciclo de vida da assinatura é então gerenciado inteiramente no backend.Assinaturas recorrentes regulares
Para cobranças em intervalos fixos (mensais ou anuais), crie uma sessão de checkout com um produto de assinatura e um deep linkreturn_url. Seu backend recebe subscription.active quando a assinatura é confirmada.
Assinaturas sob demanda
As assinaturas sob demanda permitem autorizar o método de pagamento de um cliente uma vez e cobrar valores variáveis posteriormente — ideal para recargas de carteira, pay-as-you-go e qualquer cenário em que o valor da cobrança não seja conhecido antecipadamente. Consulte a receita On-Demand Mandate acima para ver o corpo completo da solicitação. Considerações móveis importantes:- Defina
show_on_demand_tag: falsepara que a página de checkout não exiba a linguagem de “assinatura” ou “sob demanda”. Em casos de uso de tokenização de cartão, os clientes não esperam terminologia de assinatura. - Depois que o mandato for autorizado, seu backend receberá
subscription.active. Armazenesubscription_id— você o usará em todas as cobranças futuras.
Assinatura com teste gratuito
Passesubscription_data.trial_period_days na sessão de checkout para oferecer um período de teste antes do primeiro ciclo de cobrança. O cliente autoriza seu método de pagamento durante a inscrição no teste; a primeira cobrança ocorre automaticamente quando o teste termina. Consulte a receita Subscription with Free Trial acima para ver o corpo completo da solicitação.
Upgrades e downgrades
As alterações de plano são feitas por API no seu backend, não por meio de uma nova sessão de checkout. Dodo Payments calcula o rateio proporcional automaticamente. Para oferecer uma opção de autoatendimento aos clientes, incorpore ou vincule ao Customer Portal.Subscription Integration Guide
On-Demand Subscriptions
Upgrade / Downgrade
Customer Portal
Reduzindo abandonos no checkout
Os checkouts móveis apresentam mais abandonos do que os checkouts na web — telas menores, mais distrações e formulários mais longos contribuem para isso. As melhorias mais rápidas vêm da própria configuração da sessão de checkout.Otimize o formulário
Preencha previamente os dados do cliente
Cada campo que o cliente não precisa digitar é um motivo a menos para abandonar o checkout:- Novos clientes — defina
customer.emailecustomer.namea partir da sua sessão de autenticação. - Clientes recorrentes — defina
customer.customer_idpara preencher automaticamente todos os dados armazenados. - Moeda — sempre passe
billing_currencyebilling_address.countryjuntos.
Ferramentas de recuperação
Abandoned Cart Recovery
Payment Retries
Subscription Dunning
Recovery Overview
Práticas recomendadas
- Segurança: nunca inclua uma chave de API no aplicativo. Crie sessões de checkout no backend e passe ao cliente apenas o
checkout_urlresultante. - Autoridade: trate
CheckoutResult.statuscomo uma dica de UI. Conceda acesso somente depois que o backend confirmar o pagamento. - Experiência do usuário: mostre um estado de carregamento enquanto o backend cria a sessão e trate
cancelledcomo um resultado normal, não como um erro. - Testes: use o modo de teste e cartões de teste e verifique o ciclo completo da URL de retorno em um dispositivo real e também em um simulador.
- Conversão: defina
show_order_details: falseeminimal_address: truepara obter as melhores taxas de conclusão de checkout móvel. Mover os métodos de pagamento para acima da dobra e reduzir os campos do formulário são as duas mudanças de maior impacto que você pode fazer. - Moeda: sempre passe explicitamente
billing_currencyebilling_address.country— se um deles estiver ausente, Adaptive Currency poderá alterar a moeda de cobrança com base no endereço IP do cliente. - Cobrança sob demanda: defina
show_on_demand_tag: falseao usar assinaturas sob demanda para tokenização de cartão. Clientes que usam um fluxo de recarga de carteira não esperam ver a linguagem de “assinatura”. - Recuperação: ative a recuperação de carrinhos abandonados no seu dashboard do Dodo Payments para reengajar automaticamente os clientes que não concluírem o checkout.
Solução de problemas
Problemas comuns
- O callback nunca chega: o esquema em
returnUrldeve corresponder ao que você registrou. No Android, esse é o placeholder de manifestdodoCallbackScheme; no iOS e no React Native, é o tipo de URLInfo.plist. - O checkout retorna ao navegador em vez de retornar ao aplicativo (iOS): você não encaminhou a URL recebida. Chame
DodoCheckout.handleOpenURL(url)de.onOpenURL,scene(_:openURLContexts:)ou de um listenerLinkingdo React Native. PLATFORM_ERRORno Android: geralmente é uma incompatibilidade de esquema. Também pode ocorrer seMainActivitydefinirandroid:taskAffinity=""(o padrãoflutter create), fazendo com que algumas versões de OEM percam o checkout em andamento.ALREADY_IN_PROGRESS: ainda há um checkout aberto. Aguarde ou dispense o anterior antes de iniciar outro.- A compilação falha com um placeholder não resolvido: você adicionou o SDK do Android, mas nunca definiu
manifestPlaceholders["dodoCallbackScheme"]. - O pagamento foi concluído, mas o acesso não foi concedido: isso é esperado se você estiver usando o resultado móvel como referência. Conceda acesso a partir do webhook
payment.succeeded/subscription.active. - Apple Pay / Google Pay não aparecem no dispositivo móvel: o checkout está sendo carregado dentro de uma WebView incorporada (
WKWebView/ AndroidWebView), que impede o funcionamento das carteiras e pode interromper o 3-D Secure. Em vez disso, abra-o com o SDK ou no navegador do sistema (Custom Tabs /SFSafariViewController).
Recursos adicionais
- Guia de integração de pagamentos
- Documentação de webhook
- Processo de testes
- Perguntas frequentes técnicas
- Personalização da sessão de checkout
- Assinaturas sob demanda
- Upgrade/downgrade de assinatura
- Recuperação de carrinho abandonado
- Customer Portal
