Skip to main content

Quick Start

Pon en marcha tu integración de pagos móviles en 4 sencillos pasos

Platform Examples

Ejemplos de código completos para Android, iOS, React Native y Flutter

Checkout Customization

Configura temas, prellenado y 14 parámetros específicos para móviles

Mobile Recipes

Configuraciones de checkout listas para copiar y pegar para 5 escenarios móviles habituales
Dodo Payments ofrece un SDK oficial de checkout para Android, iOS, React Native, y Flutter. Cada uno encapsula el patrón documentado a continuación (abrir la URL del checkout, capturar el retorno y analizar el resultado) detrás de una única llamada tipada start(...), con recuperación de sesiones abandonadas integrada. Usa un WebView manual únicamente si ninguno se adapta a tu stack.

Requisitos previos

Antes de integrar Dodo Payments en tu aplicación móvil, asegúrate de tener:
  • Cuenta de Dodo Payments: Cuenta de comerciante activa con acceso a la API
  • Credenciales de API: Clave de API y clave secreta de webhook desde tu dashboard
  • Proyecto de aplicación móvil: Aplicación Android, iOS, React Native o Flutter
  • Servidor backend: Para gestionar de forma segura la creación de sesiones de checkout

Flujo de integración

La integración móvil sigue un proceso seguro de 4 pasos en el que tu backend gestiona las llamadas a la API y tu aplicación móvil administra la experiencia del usuario.
El status del deep link es únicamente una indicación de UI sobre lo que debes mostrar al usuario. Concede siempre el acceso desde el webhook payment.succeeded / subscription.active en tu backend, nunca basándote solo en el resultado móvil.
1

Backend: Create Checkout Session

Checkout Session API Docs

Aprende a crear una sesión de checkout en tu backend usando Node.js, Python y más. Consulta ejemplos completos y referencias de parámetros en la documentación específica de Checkout Sessions API.
Seguridad: Las sesiones de checkout deben crearse en tu servidor backend, nunca en la aplicación móvil. Esto protege tus claves de API y garantiza una validación adecuada.
2

Mobile: Get Checkout URL

Tu aplicación móvil llama a tu backend para obtener la URL del checkout. Autentica esta solicitud con el token de sesión propio del usuario que ha iniciado sesión.
Seguridad: Las aplicaciones móviles solo se comunican con tu backend, nunca directamente con la API de Dodo Payments.
3

Mobile: Open Checkout in Browser

Abre la URL del checkout en un navegador seguro dentro de la aplicación para procesar el pago. O evita por completo la configuración manual con el SDK oficial de checkout para tu plataforma.

Pick your mobile SDK

Pasos de instalación e instrucciones de configuración para Android, iOS, React Native y Flutter.
4

Backend: Handle Payment Completion

Procesa la finalización del pago mediante webhooks y URLs de redirección para confirmar el estado del pago.

Elige tu SDK

Cada SDK móvil expone el mismo contrato: una llamada start(...) abre el checkout alojado de Dodo en la superficie de navegador nativa de la plataforma y devuelve un CheckoutResult tipado cuyo status es succeeded, failed, cancelled, pending o expired. Ninguno contiene una clave de API ni llama a la API de Dodo Payments, y los cuatro admiten la recuperación de sesiones abandonadas.

Android

com.dodopayments.api:checkout-android abre una pestaña personalizada de Chrome. Requiere minSdk 23.

iOS

dodopayments-mobile-sdk-ios abre SFSafariViewController. Requiere iOS 16 o posterior.

React Native

@dodopayments/react-native-checkout, un Turbo Module sobre ambos núcleos nativos. Requiere React Native 0.76 o posterior.

Flutter

dodopayments_checkout, un canal Pigeon sobre ambos núcleos nativos. Requiere Flutter 3.44 o posterior.
El status que recibes es una indicación de UI, no una prueba de pago. Confirma cada pago desde tu backend mediante el webhook payment.succeeded / subscription.active, o recuperando el pago con tu clave secreta.

Registrar un esquema de URL de callback

Los cuatro SDK devuelven el control a tu aplicación mediante un esquema de URL personalizado que tú eliges, por ejemplo myapp://checkout/return. Regístralo una vez por plataforma:
android/app/build.gradle
El manifest del propio SDK ya declara la actividad de redirección, por lo que no tienes que añadir XML al manifest.
¿Prefieres implementarlo por tu cuenta? Abre checkout_url en el navegador del sistema de la plataforma (Android Custom Tabs / iOS SFSafariViewController) e intercepta la navegación hacia tu return_url; después, lee los parámetros de consulta status y payment_id. Los SDK anteriores hacen exactamente esto por ti.
No abras el checkout dentro de un WebView integrado (WKWebView / Android WebView). Este es el problema más habitual en las integraciones móviles: un WebView integrado suprime Apple Pay y Google Pay y también puede interrumpir los desafíos de 3-D Secure y el autocompletado de tarjetas guardadas, por lo que los clientes ven menos opciones de pago y más errores. Usa siempre el SDK o abre checkout_url en el navegador del sistema (Custom Tabs / SFSafariViewController). Precisamente por usar esa superficie de navegador nativa, Apple Pay y Google Pay siguen funcionando.

Personalización de la apariencia

Cada SDK acepta un parámetro opcional customization en start(...) / CheckoutParams que controla la apariencia y el comportamiento de la superficie de navegador nativa: la barra de herramientas, los botones y la presentación. Esto es independiente del tema propio de la página de checkout, que configuras en el servidor mediante customization.theme_config en la sesión de checkout. Las opciones se agrupan por plataforma porque Android Custom Tab e iOS SFSafariViewController exponen controles nativos diferentes. Todos los campos son opcionales; omitir por completo customization utiliza la apariencia predeterminada de cada plataforma.
Color
Color de fondo de la barra de herramientas.
Color
Color de la barra de navegación.
Color
Color del separador situado sobre la barra de navegación.
'default' | 'back'
default muestra el icono de sistema «X»; back dibuja una flecha de retroceso en su lugar.
'start' | 'end'
Indica en qué lado de la barra de herramientas aparece el botón de cierre.
boolean
Muestra el icono de compartir de la barra de herramientas.
boolean
Muestra el título de la página debajo de la URL en la barra de herramientas.
boolean
Permite que la barra de herramientas se oculte automáticamente al desplazarse por la página.
boolean
Muestra «Añadir esta página a marcadores» en el menú de opciones.
boolean
Muestra «Descargar página» en el menú de opciones.
'system' | 'light' | 'dark'
Fuerza la apariencia clara u oscura independientemente de la configuración del sistema del dispositivo.
'done' | 'close' | 'cancel'
Etiqueta o icono del botón de cierre.
'pageSheet' | 'fullScreen'
pageSheet se presenta como una tarjeta que se puede cerrar deslizando; fullScreen cubre toda la pantalla.
boolean
Permite que la barra de herramientas se contraiga al desplazarse. Solo es visible cuando presentationStyle es fullScreen; pageSheet mantiene las barras fijadas independientemente de esta configuración.
'system' | 'light' | 'dark'
Fuerza la apariencia clara u oscura independientemente de la configuración del sistema del dispositivo.

Personalización de la página de checkout

La sección Personalización de la apariencia anterior controla la superficie del navegador nativo: barra de herramientas, botones y combinación de colores. La propia página de checkout —los campos que aparecen, el tema y los métodos de pago visibles— se configura en el servidor al crear la sesión de checkout. Estos parámetros tienen el mayor impacto en la conversión móvil. Los parámetros siguientes se encuentran en tres ubicaciones diferentes de la solicitud de la sesión de checkout; la columna Dónde se incluye indica a qué objeto pertenece cada uno. Equivocarse aquí es el error más habitual: un parámetro incluido en el objeto incorrecto se ignora silenciosamente.
Pasa siempre billing_currency y billing_address.country juntos. Si omites cualquiera de ellos, Adaptive Currency puede cambiar silenciosamente la moneda de facturación según la dirección IP del cliente. Un comerciante vio cómo una suscripción de EE. UU. cambiaba a EUR cuando su cliente viajó a Europa porque el país de facturación no se había establecido explícitamente.
La mayor mejora individual de conversión en móviles: establece show_order_details: false y minimal_address: true. Mover los métodos de pago above the fold y reducir los campos del formulario son los dos cambios de mayor impacto que puedes realizar.
Checkout lado a lado: detalles del pedido expandidos (campos below the fold) frente a contraídos (campos en la parte superior)

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

Establece minimal_address: true para recopilar solo un código postal en lugar de los campos completos de calle, ciudad y estado:
Checkout lado a lado: formulario de dirección de facturación completo frente a solo código postal

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

Establece theme: "system" para que el checkout siga la preferencia de modo claro u oscuro del dispositivo:
Checkout lado a lado: la misma página representada en modo claro y modo oscuro

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

La disponibilidad de los métodos de pago varía según el tipo de producto. Apple Pay y Cash App son compatibles con suscripciones recurrentes no gratuitas. Para pagos únicos, están disponibles todos los métodos habilitados.

Full checkout session parameter reference

Consulta todos los parámetros disponibles, sus tipos y valores predeterminados en la guía de Checkout Sessions.

Recetas optimizadas para móviles

Cada receta siguiente es el cuerpo completo de una solicitud de sesión de checkout. Copia la que coincida con tu escenario, sustituye el ID de tu producto y pásala al endpoint de creación de sesiones de tu backend.
Úsala cuando quieras el formulario más corto posible: métodos de pago en la parte superior, solo se requiere un código postal para la dirección, sin campo de descuento y con un tema que coincide con el dispositivo.
Consulta Checkout Sessions para ver todos los parámetros disponibles y sus valores predeterminados.
Úsala cuando la página de checkout deba sentirse integrada en tu aplicación. Establece los colores de tu marca, una fuente personalizada y una etiqueta localizada para el botón de pago.
Checkout móvil de marca con una paleta azul marino oscuro personalizada aplicada mediante theme_config
theme_config acepta objetos separados dark y light para que la paleta se adapte a la apariencia actual del dispositivo. Consulta Checkout Sessions para ver la referencia completa de las claves de color.
Úsala para usuarios autenticados que ya hayan pagado anteriormente. Combina un ID de cliente, su método de pago guardado e confirm: true para omitir por completo el formulario de checkout.
El status del retorno mediante deep link es únicamente una indicación de UI. Confirma el acceso escuchando el webhook payment.succeeded en tu backend.
Úsala para productos de suscripción que ofrecen un periodo de prueba gratuito antes del primer ciclo de facturación.
Concede acceso a las funcionalidades cuando tu backend reciba el webhook subscription.active, no cuando el SDK móvil devuelva el resultado. Consulta la Subscription Integration Guide para ver el flujo completo del webhook.
Úsala para tokenizar la tarjeta de un cliente para cargos posteriores (recargas de wallet, pago por uso, BNPL) sin mostrar la etiqueta «subscription». El cliente autoriza su método de pago una vez; después puedes realizar cargos variables on-demand.
Este es el patrón utilizado por las aplicaciones que cobran según el uso, por ejemplo, una aplicación de astrología que cobra por sesión desde una tarjeta preautorizada, en lugar de hacerlo según un calendario fijo.
Los cargos on-demand requieren un mínimo de 1 USD (100 centavos). Los importes inferiores a 1 USD se rechazarán con "value out of range". Para una autorización de importe cero, usa mandate_only: true como se muestra arriba y, después, cobra al menos 1 USD en las llamadas posteriores.
Consulta On-Demand Subscriptions para ver el flujo completo de cargos, los eventos de webhook y las políticas de reintento.

Flujos de suscripción desde dispositivos móviles

Las suscripciones se crean mediante el mismo flujo de sesión de checkout utilizado para los pagos únicos: el SDK móvil abre el checkout alojado, el cliente se suscribe y tu aplicación gestiona el retorno mediante deep link. Después, el ciclo de vida de la suscripción se administra íntegramente en el backend.

Suscripciones recurrentes normales

Para facturación a intervalos fijos (mensual o anual), crea una sesión de checkout con un producto de suscripción y un deep link return_url. Tu backend recibe subscription.active cuando se confirma la suscripción.
Apple Pay y Cash App son compatibles con suscripciones recurrentes no gratuitas.
Para consultar el flujo completo del webhook del backend, visita la Subscription Integration Guide.

Suscripciones on-demand

Las suscripciones on-demand permiten autorizar una vez el método de pago de un cliente y cobrar importes variables posteriormente; son ideales para recargas de wallet, pago por uso y cualquier escenario en el que el importe del cargo no se conozca de antemano. Consulta la receta On-Demand Mandate anterior para ver el cuerpo completo de la solicitud. Consideraciones móviles importantes:
  • Establece show_on_demand_tag: false para que la página de checkout no muestre lenguaje relacionado con «subscription» u «on-demand». En casos de tokenización de tarjetas, los clientes no esperan terminología de suscripción.
  • Después de autorizar el mandato, tu backend recibe subscription.active. Guarda subscription_id; lo utilizarás para todos los cargos futuros.
El cargo mínimo es de 1 USD (100 centavos). Los cargos on-demand inferiores a 1 USD se rechazarán con "value out of range". Cobra al menos 1 USD o usa mandate_only: true para autorizar sin realizar un cargo y cobrar el primer importe real más adelante.
Evita los reintentos rápidos y consecutivos. Si un cargo anterior todavía se está procesando, un nuevo cargo en la misma suscripción fallará con "Cannot create new charge as previous payment is not successful yet". Esto es especialmente habitual con métodos de pago indios (UPI y tarjetas de débito/crédito indias), cuyos mandatos RBI pueden mantener una transacción en estado de procesamiento hasta 48 horas. Añade una comprobación de espera en la lógica de cargos antes de reintentar.
Consulta On-Demand Subscriptions para ver el endpoint de cargos completo, los eventos de webhook y las políticas de reintento.

Suscripción con prueba gratuita

Pasa subscription_data.trial_period_days en la sesión de checkout para ofrecer una prueba antes del primer ciclo de facturación. El cliente autoriza su método de pago durante el registro de la prueba; el primer cargo se realiza automáticamente cuando termina la prueba. Consulta la receta Subscription with Free Trial anterior para ver el cuerpo completo de la solicitud.

Mejoras y reducciones de plan

Los cambios de plan se realizan mediante la API en tu backend, no mediante una nueva sesión de checkout. Dodo Payments calcula automáticamente el prorrateo. Para ofrecer una opción de autoservicio a los clientes, inserta un enlace al Customer Portal o intégralo.

Subscription Integration Guide

Configuración completa del backend: flujo de webhooks, provisión de acceso y cancelación

On-Demand Subscriptions

Autorización de mandatos, cargos variables y políticas de reintento

Upgrade / Downgrade

Estrategias de prorrateo, cambios de plan y ajustes de plazas

Customer Portal

Gestión de suscripciones de autoservicio para tus clientes

Reducir el abandono del checkout

Los checkouts móviles presentan un abandono mayor que los web: las pantallas más pequeñas, las distracciones y los formularios más largos contribuyen a ello. Las mejoras más rápidas provienen de la propia configuración de la sesión de checkout.

Optimizar el formulario

Prellenar los datos del cliente

Cada campo que el cliente no tiene que escribir es un motivo menos para abandonar:
  • Clientes nuevos: establece customer.email e customer.name desde tu sesión de autenticación.
  • Clientes recurrentes: establece customer.customer_id para prellenar automáticamente todos los datos guardados.
  • Moneda: pasa siempre billing_currency y billing_address.country juntos.

Herramientas de recuperación

Abandoned Cart Recovery

Secuencias de correo automatizadas para checkouts incompletos

Payment Retries

Lógica de reintento inteligente para renovaciones de suscripción fallidas

Subscription Dunning

Correos de reactivación para suscripciones vencidas

Recovery Overview

Todas las herramientas de recuperación y su impacto combinado en los ingresos
Prueba los correos de abandono del carrito antes de activarlos. Crea una sesión de checkout en modo live e introduce datos de tarjeta no válidos. El pago fallido activa el flujo de correo de recuperación y te permite previsualizar exactamente lo que recibirán tus clientes.

Prácticas recomendadas

  • Seguridad: Nunca incluyas una clave de API en tu aplicación. Crea sesiones de checkout en tu backend y pasa al cliente únicamente la checkout_url resultante.
  • Autoridad: Trata CheckoutResult.status como una indicación de UI. Concede acceso solo después de que tu backend confirme el pago.
  • Experiencia de usuario: Muestra un estado de carga mientras tu backend crea la sesión y gestiona cancelled como un resultado normal, no como un error.
  • Pruebas: Usa el modo de prueba y tarjetas de prueba, y verifica el recorrido de ida y vuelta de la return-URL en un dispositivo real y en un simulador.
  • Conversión: Establece show_order_details: false e minimal_address: true para obtener las mejores tasas de finalización del checkout móvil. Mover los métodos de pago above the fold y reducir los campos del formulario son los dos cambios de mayor impacto que puedes realizar.
  • Moneda: Pasa siempre explícitamente billing_currency y billing_address.country; si falta cualquiera de ellos, Adaptive Currency puede cambiar la moneda de facturación según la dirección IP del cliente.
  • Facturación on-demand: Establece show_on_demand_tag: false al utilizar suscripciones on-demand para tokenizar tarjetas. Los clientes que usan un flujo de recarga de wallet no esperan ver lenguaje relacionado con «subscription».
  • Recuperación: Activa la recuperación de carritos abandonados en tu dashboard de Dodo Payments para volver a captar automáticamente a los clientes que no completan el checkout.

Solución de problemas

Problemas habituales

  • El callback nunca llega: El esquema de returnUrl debe coincidir con el que registraste. En Android es el placeholder de manifest dodoCallbackScheme; en iOS y React Native es el tipo de URL Info.plist.
  • El checkout vuelve al navegador en lugar de a tu aplicación (iOS): No has reenviado la URL entrante. Llama a DodoCheckout.handleOpenURL(url) desde .onOpenURL, scene(_:openURLContexts:) o un listener Linking de React Native.
  • PLATFORM_ERROR en Android: Normalmente se debe a una discrepancia en el esquema. También puede aparecer si MainActivity establece android:taskAffinity="" (el valor predeterminado estándar flutter create), lo que puede hacer que algunos builds de OEM pierdan el checkout en curso.
  • ALREADY_IN_PROGRESS: Hay un checkout abierto. Espera a que finalice o descarta el anterior antes de iniciar otro.
  • El build falla por un placeholder no resuelto: Añadiste el SDK de Android, pero nunca estableciste manifestPlaceholders["dodoCallbackScheme"].
  • El pago se realizó correctamente, pero no se concedió acceso: Es lo esperado si te basas en el resultado móvil. Concede el acceso desde el webhook payment.succeeded / subscription.active.
  • Apple Pay / Google Pay no aparecen en móviles: El checkout se está cargando dentro de un WebView integrado (WKWebView / Android WebView), que suprime las wallets y puede interrumpir 3-D Secure. Ábrelo con el SDK o en el navegador del sistema (Custom Tabs / SFSafariViewController).

Recursos adicionales

Si tienes preguntas o necesitas asistencia, contacta con support@dodopayments.com.
Última modificación el 21 de agosto de 2026