Skip to main content

Quick Start

Coloque sua integração de pagamentos móveis em funcionamento em 4 etapas simples

Platform Examples

Exemplos completos de código para Android, iOS, React Native e Flutter

Checkout Customization

Configure temas, preenchimento automático e 14 parâmetros específicos para dispositivos móveis

Mobile Recipes

Configurações de checkout prontas para copiar e colar para 5 cenários móveis comuns
Dodo Payments disponibiliza um SDK oficial de checkout para Android, iOS, React Native e Flutter. Cada um encapsula o padrão documentado abaixo (abrir a URL de checkout, capturar o retorno e analisar o resultado) por trás de uma única chamada 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.
O deep link 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.
1

Backend: Create Checkout Session

Checkout Session API Docs

Saiba como criar uma sessão de checkout no seu backend usando Node.js, Python e outras linguagens. Consulte exemplos completos e referências de parâmetros na documentação dedicada da Checkout Sessions API.
Segurança: as sessões de checkout devem ser criadas no seu servidor de backend, nunca no aplicativo móvel. Isso protege suas chaves de API e garante a validação adequada.
2

Mobile: Get Checkout URL

Seu aplicativo móvel chama o backend para obter a URL de checkout. Autentique essa solicitação com o token de sessão do próprio usuário conectado.
Segurança: os aplicativos móveis se comunicam apenas com seu backend, nunca diretamente com a Dodo Payments API.
3

Mobile: Open Checkout in Browser

Abra a URL de checkout em um navegador seguro dentro do aplicativo para processar o pagamento. Ou ignore completamente a configuração manual usando o SDK oficial de checkout da sua plataforma.

Pick your mobile SDK

Etapas de instalação e instruções de configuração para Android, iOS, React Native e Flutter.
4

Backend: Handle Payment Completion

Processe a conclusão do pagamento por meio de webhooks e URLs de redirecionamento para confirmar o status do pagamento.

Escolha seu SDK

Todos os SDKs móveis expõem o mesmo contrato: uma única chamada start(...) 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.
O status retornado é uma dica de UI, não uma prova de pagamento. Confirme cada pagamento no seu backend por meio do webhook payment.succeeded / subscription.active ou recuperando o pagamento com sua chave secreta.

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/app/build.gradle
O próprio manifest do SDK já declara a atividade de redirecionamento, portanto não há XML de manifest a ser adicionado.
Prefere criar a integração por conta própria? Abra 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ê.
Não abra o checkout dentro de uma WebView incorporada (WKWebView / Android WebView). Este é o problema mais comum em integrações móveis: uma WebView incorporada impede o funcionamento do Apple Pay e do Google Pay e também pode interromper desafios do 3-D Secure e o preenchimento automático de cartões salvos — fazendo com que os clientes vejam menos opções de pagamento e mais falhas. Sempre use o SDK ou abra checkout_url no navegador do sistema (Custom Tabs / SFSafariViewController). Essa superfície de navegador nativa é exatamente o motivo pelo qual Apple Pay e Google Pay continuam funcionando.

Personalização da aparência

Todos os SDKs aceitam um parâmetro opcional customization 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.
Color
Cor de fundo da barra de ferramentas.
Color
Cor da barra de navegação.
Color
Cor do divisor acima da barra de navegação.
'default' | 'back'
default exibe o ícone de sistema “X”; back desenha uma seta de voltar.
'start' | 'end'
Em qual lado da barra de ferramentas o botão de fechar aparece.
boolean
Exibe o ícone de compartilhamento da barra de ferramentas.
boolean
Exibe o título da página abaixo da URL na barra de ferramentas.
boolean
Permite que a barra de ferramentas se oculte automaticamente conforme a página é rolada.
boolean
Exibe “Adicionar esta página aos favoritos” no menu de opções.
boolean
Exibe “Baixar página” no menu de opções.
'system' | 'light' | 'dark'
Força a aparência clara ou escura, independentemente da configuração do sistema do dispositivo.
'done' | 'close' | 'cancel'
Rótulo ou ícone do botão de dispensar.
'pageSheet' | 'fullScreen'
pageSheet é apresentado como um cartão com deslize para dispensar; fullScreen cobre a tela inteira.
boolean
Permite que a barra de ferramentas seja recolhida durante a rolagem. Só fica visível quando presentationStyle é fullScreenpageSheet mantém as barras fixas independentemente desta configuração.
'system' | 'light' | 'dark'
Força a aparência clara ou escura, independentemente da configuração do sistema do dispositivo.

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.
Sempre passe billing_currency e billing_address.country juntos. Se um deles for omitido, Adaptive Currency poderá alterar silenciosamente a moeda de cobrança com base no endereço IP do cliente. Um comerciante viu uma assinatura nos EUA mudar para EUR quando o cliente viajou para a Europa — porque o país de cobrança não havia sido definido explicitamente.
Maior aumento individual de conversão em dispositivos móveis: defina show_order_details: false e minimal_address: true. 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.
Checkout lado a lado: detalhes do pedido expandidos (campos abaixo da dobra) versus recolhidos (campos no topo)

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

Defina minimal_address: true para coletar apenas um CEP, em vez dos campos completos de rua, cidade e estado:
Checkout lado a lado: formulário completo de endereço de cobrança versus somente CEP

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

Defina theme: "system" para que o checkout siga a preferência de modo claro ou escuro do dispositivo:
Checkout lado a lado: mesma página exibida no modo claro e no modo escuro

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

A disponibilidade dos métodos de pagamento varia conforme o tipo de produto. Apple Pay e Cash App são compatíveis com assinaturas recorrentes não gratuitas. Para pagamentos únicos, todos os métodos ativados estão disponíveis.

Full checkout session parameter reference

Consulte todos os parâmetros, tipos e valores padrão disponíveis no guia Checkout Sessions.

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.
Use esta opção quando quiser o formulário mais curto possível: métodos de pagamento no topo, apenas o CEP obrigatório para o endereço, nenhum campo de desconto e tema correspondente ao dispositivo.
Consulte Checkout Sessions para ver todos os parâmetros disponíveis e seus valores padrão.
Use esta opção quando a página de checkout precisar parecer parte do seu aplicativo. Defina as cores da sua marca, uma fonte personalizada e um rótulo localizado para o botão de pagamento.
Checkout móvel com a marca e uma paleta azul-marinho escura personalizada aplicada por meio de theme_config
theme_config aceita objetos separados dark e light para que a paleta se adapte à aparência atual do dispositivo. Consulte Checkout Sessions para obter a referência completa das cores.
Use esta opção para usuários conectados que já pagaram anteriormente. Combine um ID de cliente, o método de pagamento salvo e confirm: true para ignorar completamente o formulário de checkout.
O status no retorno do deep link é apenas uma dica de UI. Confirme o acesso monitorando o webhook payment.succeeded no seu backend.
Use esta opção para produtos de assinatura que oferecem um período de teste gratuito antes do primeiro ciclo de cobrança.
Conceda acesso ao recurso quando seu backend receber o webhook 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.
Use esta opção para tokenizar o cartão de um cliente para cobranças posteriores (recargas de carteira, pay-as-you-go e BNPL) sem exibir um rótulo de “assinatura”. O cliente autoriza o método de pagamento uma vez; posteriormente, você cobra valores variáveis sob demanda.
Este é o padrão usado por aplicativos que cobram com base no uso — por exemplo, um aplicativo de astrologia que cobra por sessão a partir de um cartão pré-autorizado, em vez de seguir uma agenda fixa.
As cobranças sob demanda exigem um mínimo de 1 USD (100 centavos). Valores abaixo de 1 USD serão rejeitados com "value out of range". Para uma autorização de valor zero, use mandate_only: true conforme mostrado acima e, depois, cobre pelo menos 1 USD nas chamadas subsequentes.
Consulte Assinaturas sob demanda para ver o fluxo completo de cobrança, os eventos de webhook e as políticas de novas tentativas.

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 link return_url. Seu backend recebe subscription.active quando a assinatura é confirmada.
Apple Pay e Cash App são compatíveis com assinaturas recorrentes não gratuitas.
Para consultar o fluxo completo de webhook do backend, veja o Guia de integração de assinaturas.

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: false para 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. Armazene subscription_id — você o usará em todas as cobranças futuras.
A cobrança mínima é de 1 USD (100 centavos). Cobranças sob demanda abaixo de 1 USD serão rejeitadas com "value out of range". Cobre pelo menos 1 USD ou use mandate_only: true para autorizar sem cobrar e coletar o primeiro valor real posteriormente.
Evite novas tentativas em sequência rápida. Se uma cobrança anterior ainda estiver sendo processada, uma nova cobrança na mesma assinatura falhará com "Cannot create new charge as previous payment is not successful yet". Isso é especialmente comum com métodos de pagamento indianos (UPI, cartões de débito/crédito indianos), nos quais as regras de mandato do RBI podem manter uma transação em processamento por até 48 horas. Adicione uma verificação de intervalo de espera à sua lógica de cobrança antes de tentar novamente.
Consulte Assinaturas sob demanda para ver o endpoint de cobrança completo, os eventos de webhook e as políticas de novas tentativas.

Assinatura com teste gratuito

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

Configuração completa do backend: fluxo de webhook, provisionamento de acesso e cancelamento

On-Demand Subscriptions

Autorização de mandato, cobranças variáveis e políticas de novas tentativas

Upgrade / Downgrade

Estratégias de rateio proporcional, alterações de plano e ajustes de quantidade de assentos

Customer Portal

Gerenciamento de assinaturas por autoatendimento para seus clientes

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.email e customer.name a partir da sua sessão de autenticação.
  • Clientes recorrentes — defina customer.customer_id para preencher automaticamente todos os dados armazenados.
  • Moeda — sempre passe billing_currency e billing_address.country juntos.

Ferramentas de recuperação

Abandoned Cart Recovery

Sequências automatizadas de e-mails para checkouts incompletos

Payment Retries

Lógica inteligente de novas tentativas para renovações de assinatura com falha

Subscription Dunning

E-mails de reengajamento para assinaturas canceladas por inadimplência

Recovery Overview

Todas as ferramentas de recuperação e seu impacto combinado na receita
Teste os e-mails de abandono de carrinho antes de ativá-los. Crie uma sessão de checkout no modo de produção e insira dados de cartão inválidos. O pagamento com falha acionará o fluxo de e-mail de recuperação, permitindo visualizar exatamente o que seus clientes receberão.

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_url resultante.
  • Autoridade: trate CheckoutResult.status como 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 cancelled como 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: false e minimal_address: true para 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_currency e billing_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: false ao 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 returnUrl deve corresponder ao que você registrou. No Android, esse é o placeholder de manifest dodoCallbackScheme; no iOS e no React Native, é o tipo de URL Info.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 listener Linking do React Native.
  • PLATFORM_ERROR no Android: geralmente é uma incompatibilidade de esquema. Também pode ocorrer se MainActivity definir android:taskAffinity="" (o padrão flutter 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 / Android WebView), 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

Para dúvidas ou suporte, entre em contato pelo e-mail support@dodopayments.com.
Última modificação em 21 de agosto de 2026