Skip to main content
El paquete @dodopayments/remix proporciona a tu aplicación Remix tres manejadores de solicitudes. Checkout devuelve URLs de checkout, CustomerPortal envía al cliente al Customer Portal y Webhooks verifica los eventos de webhook y los dirige a tu código. Cada manejador recibe un Request y devuelve un Response, por lo que debes llamarlo desde el loader o action de una ruta.

Checkout Handler

Crea URLs de checkout desde tu aplicación Remix.

Customer Portal

Permite que los clientes administren sus suscripciones y datos.

Webhooks

Recibe y verifica eventos de webhook de Dodo Payments.

Instalación

1

Install the Package

Ejecuta este comando en la raíz de tu proyecto:
El paquete incluye Remix 2 (remix 2.16.8 o posterior) y zod 3.25 o posterior como dependencias peer.
2

Set Up Environment Variables

Crea un archivo .env en la raíz de tu proyecto:
Crea la API key en Developer → API Keys. Añade tu endpoint de webhook en Developer → Webhooks y copia su signing secret en DODO_PAYMENTS_WEBHOOK_KEY. DODO_PAYMENTS_RETURN_URL es el lugar al que llegan los clientes después del checkout. Si no pasas un entorno, los manejadores usan live_mode.
Nunca subas tu archivo .env ni los secretos al control de versiones.

Ejemplos de manejadores de rutas

Los ejemplos son resource routes de Remix, que exportan un loader para solicitudes GET o un action para solicitudes POST y ningún componente. Con flat file routes, app/routes/api.checkout.tsx sirve /api/checkout.
Usa este manejador para añadir el checkout de Dodo Payments a tu aplicación Remix. loader sirve el checkout estático. action sirve aquí el checkout dinámico. Para servir sesiones de checkout, el flujo recomendado, devuelve checkoutSessionHandler(request) desde action en su lugar.
La solicitud de la sesión de checkout funciona cuando action devuelve checkoutSessionHandler(request).

Manejador de rutas de checkout

El manejador de checkout admite las tres formas de aceptar pagos con Dodo Payments:
  • Static Payment Links: URLs que puedes compartir y que recaudan pagos sin código.
  • Dynamic Payment Links: enlaces de pago que generas con detalles personalizados. Usan endpoints obsoletos.
  • Checkout Sessions: checkout alojado con un carrito de productos, datos del cliente y opciones de personalización. Este es el flujo recomendado.
Checkout acepta estas opciones:

Parámetros de consulta compatibles

string
requerido
Identificador del producto, por ejemplo ?productId=pdt_nZuwz45WAs64n3l07zpQR.
integer
predeterminado:"1"
Cantidad del producto.
string
Nombre completo del cliente. Se ignora si se proporciona firstName o lastName.
string
Nombre del cliente.
string
Apellido del cliente.
string
Dirección de correo electrónico del cliente.
string
País del cliente, como código ISO 3166-1 alpha-2.
string
Línea de dirección del cliente.
string
Ciudad del cliente.
string
Estado o provincia del cliente.
string
Código ZIP o postal del cliente.
boolean
Establece true para desactivar el campo de nombre completo.
boolean
Establece true para desactivar el campo de nombre.
boolean
Establece true para desactivar el campo de apellido.
boolean
Establece true para desactivar el campo de correo electrónico.
boolean
Establece true para desactivar el campo de país.
boolean
Establece true para desactivar el campo de línea de dirección.
boolean
Establece true para desactivar el campo de ciudad.
boolean
Establece true para desactivar el campo de estado.
boolean
Establece true para desactivar el campo de código ZIP.
string
Moneda del pago, por ejemplo USD.
boolean
predeterminado:"true"
Muestra u oculta el selector de moneda.
number
Fija el importe cobrado, en unidades mayores de moneda, por ejemplo 12.5 para $12.50. Solo funciona con productos Pay What You Want y se ignora si está por debajo del precio mínimo del producto.
boolean
predeterminado:"true"
Muestra u oculta la sección de descuentos.
string
Cualquier parámetro de consulta que comience con metadata_ se pasa como metadata.
El manejador añade returnUrl de su configuración al enlace como redirect_url.
Si falta productId, el manejador devuelve una respuesta 400. Los parámetros de consulta no válidos y los ID de producto inexistentes también devuelven 400.

Formato de respuesta

El checkout estático devuelve una respuesta JSON con la URL de checkout. En modo de prueba, la URL usa test.checkout.dodopayments.com.
El checkout dinámico actúa como proxy de los endpoints obsoletos POST /payments y POST /subscriptions. Sigue funcionando para integraciones existentes, pero las nuevas integraciones deben usar sesiones de checkout.

Formato de respuesta

El checkout dinámico devuelve una respuesta JSON con la URL de checkout:
Las sesiones de checkout crean un checkout alojado para compras únicas y suscripciones, con control total sobre la personalización. product_cart es el único campo obligatorio. Si el cuerpo no contiene return_url, el manejador usa returnUrl de su configuración.Para obtener más detalles y consultar todos los campos compatibles, consulta la Guía de integración de Checkout Sessions.Una sesión creada con payment_method_id no devuelve una URL de checkout, por lo que el manejador responde con 400. Para realizar un cargo en un método de pago guardado, crea la sesión con el SDK.

Formato de respuesta

Las sesiones de checkout devuelven una respuesta JSON con la URL de checkout:

Manejador de rutas de Customer Portal

El manejador de rutas de Customer Portal crea una sesión de Customer Portal para el cliente que indiques y redirige el navegador a ella con una respuesta 307.
El manejador no comprueba quién lo llama. Cualquiera que lo solicite con un ID de cliente obtiene el portal de ese cliente. Protege la ruta con tu propia autenticación y pasa únicamente el ID de cliente del usuario que inició sesión.

Parámetros de consulta

string
requerido
El ID de cliente de la sesión del portal, por ejemplo ?customer_id=cus_123.
boolean
Si se establece en true, Dodo Payments también envía por correo electrónico el enlace del portal al cliente.
Devuelve 400 si falta customer_id y 500 si no se puede crear la sesión del portal.

Manejador de rutas de webhook

El manejador de rutas de webhook verifica cada solicitud antes de ejecutar tu código:
  • Method: Solo se admiten solicitudes POST. Otros métodos devuelven 405.
  • Signature Verification: Verifica el cuerpo sin procesar de la solicitud y los encabezados webhook-id, webhook-timestamp y webhook-signature con webhookKey, conforme a la especificación de Standard Webhooks. Devuelve 401 si la verificación falla.
  • Payload Validation: Valida el payload con Zod. Devuelve 400 si el payload no es válido.
  • Error Handling:
    • 401: Firma no válida
    • 400: Payload no válido
    • 500: Error interno durante la verificación
  • Event Routing: Llama a onPayload para cada evento, después al manejador correspondiente al tipo de evento y devuelve 200.
El adaptor no captura los errores generados en tus manejadores. Se propagan a Remix y la solicitud falla.

Manejadores de eventos de webhook compatibles

Cada manejador recibe el payload verificado correspondiente a su tipo de evento:
Para saber qué significa cada evento, consulta la Guía de eventos de webhook.

Prompt para LLM

Copia este prompt en tu asistente de programación con IA para que añada el adaptor a tu proyecto. Para proporcionar también a tu agente la documentación y las skills de Dodo Payments, instala el Agent Plugin.
Última modificación el 26 de septiembre de 2026