Skip to main content
El paquete @dodopayments/bun proporciona a tu servidor Bun tres manejadores de solicitudes. Checkout devuelve URLs de checkout, CustomerPortal envía al cliente a Customer Portal y Webhooks verifica los eventos de webhook y los redirige a tu código. Cada manejador recibe un Request estándar y devuelve un Response, por lo que debes llamarlo desde el manejador fetch de Bun.serve().

Checkout Handler

Crea URLs de checkout mediante flujos estáticos, dinámicos y de sesiones de checkout.

Customer Portal

Permite que los clientes gestionen sus suscripciones y datos.

Webhooks

Recibe y procesa eventos de webhook de Dodo Payments.

Instalación

1

Install the Package

Ejecuta este comando en la raíz de tu proyecto:
El paquete también necesita zod 3.25 o posterior, que aparece como dependencia entre pares.
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:
Bun lee automáticamente los archivos .env, por lo que los ejemplos leen estos valores desde process.env. DODO_PAYMENTS_RETURN_URL es el destino al que llegan los clientes después del checkout. Si no proporcionas un entorno, los manejadores usan live_mode. Una API key del modo de prueba solo funciona con test_mode.
Nunca confirmes tu archivo .env ni tus secretos en el control de versiones.

Ejemplos de manejadores de rutas

Todos los ejemplos usan el servidor nativo de Bun, Bun.serve(), y enrutan las solicitudes según la ruta y el método en su manejador fetch.
Usa este manejador para añadir el checkout de Dodo Payments a tu servidor Bun. El manejador estático sirve las solicitudes GET. Los manejadores de sesión y dinámico sirven las solicitudes POST. El ejemplo de checkout dinámico supone que el servidor devuelve dynamicCheckoutHandler(request) para las solicitudes POST.

Manejador de rutas de checkout

El manejador de checkout admite las tres formas de aceptar pagos con Dodo Payments:
  • Static Payment Links: URLs que se pueden 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: El manejador sirve el checkout estático para las solicitudes GET. Para las solicitudes POST, crea un enlace de pago dinámico cuando type es dynamic, y una sesión de checkout en los demás casos.

Parámetros de consulta compatibles

string
requerido
Identificador del producto, por ejemplo ?productId=pdt_xxx.
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
Dirección postal del cliente.
string
Ciudad del cliente.
string
Estado o provincia del cliente.
string
Código postal del cliente.
boolean
Establécelo en true para desactivar el campo de nombre completo.
boolean
Establécelo en true para desactivar el campo de nombre.
boolean
Establécelo en true para desactivar el campo de apellido.
boolean
Establécelo en true para desactivar el campo de correo electrónico.
boolean
Establécelo en true para desactivar el campo de país.
boolean
Establécelo en true para desactivar el campo de dirección.
boolean
Establécelo en true para desactivar el campo de ciudad.
boolean
Establécelo en true para desactivar el campo de estado.
boolean
Establécelo en true para desactivar el campo de código postal.
string
Moneda del pago, por ejemplo USD.
boolean
predeterminado:"true"
Muestra u oculta el selector de moneda.
number
Fija el importe cobrado, en unidades principales de la 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 por metadata_ se envía al checkout como metadata, por ejemplo metadata_orderId=123.
Una marca de desactivación solo tiene efecto cuando el campo correspondiente tiene un valor, por ejemplo email con disableEmail=true. 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 o un producto que no exista en tu cuenta también devuelven 400.

Formato de respuesta

El checkout estático devuelve una respuesta JSON con la URL de checkout. En el modo de prueba, la URL usa test.checkout.dodopayments.com:
  • Envía los parámetros como un cuerpo JSON en una solicitud POST.
  • Admite pagos únicos y recurrentes. El manejador recupera el producto y después crea una suscripción si el producto es recurrente, o un pago único en caso contrario.
  • El cuerpo necesita billing (con street, city, state, country y zipcode) e customer, además de product_id o product_cart. Las suscripciones necesitan product_id.
  • Para consultar todos los campos compatibles del cuerpo, visita:
El checkout dinámico actúa como proxy de los endpoints obsoletos POST /payments y POST /subscriptions. Sigue funcionando para las integraciones existentes, pero las integraciones nuevas deben usar sesiones de checkout.

Formato de respuesta

El checkout dinámico devuelve una respuesta JSON con el enlace de pago como 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 y necesita al menos un producto. Si el cuerpo no contiene return_url, el manejador usa returnUrl de su configuración.Cada checkout_url funciona una vez y caduca después de 24 horas, o después de 15 minutos cuando proporcionas confirm: true. Una sesión creada con payment_method_id no devuelve checkout_url, por lo que el manejador responde con 400.Para obtener más información y consultar todos los campos compatibles, visita la Guía de integración de Checkout Sessions.

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 proporcionado y redirige el navegador a ella. CustomerPortal acepta las mismas opciones bearerToken e environment que Checkout.
El manejador no comprueba quién lo está llamando. 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 ha iniciado sesión.

Parámetros de consulta

string
requerido
El ID de cliente para 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.
El manejador 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 con tu secreto de webhook, proporcionado como webhookKey, antes de ejecutar tu código:
  • Método: Solo se admiten solicitudes POST. Los demás métodos devuelven 405.
  • Verificación de firma: Verifica los encabezados webhook-id, webhook-timestamp e webhook-signature con webhookKey, conforme a la especificación Standard Webhooks. Devuelve 401 si la verificación falla.
  • Validación de la carga útil: Analiza el cuerpo como JSON y lo valida con Zod. Devuelve 400 si el JSON o la carga útil no son válidos.
  • Gestión de errores:
    • 401: Firma no válida
    • 400: Carga útil no válida
    • 500: Error interno durante la verificación
  • Enrutamiento de eventos: Llama a onPayload para cada evento, después al manejador correspondiente al tipo de evento y devuelve 200.
El adaptador no captura los errores lanzados en tus manejadores. Se propagan a Bun.serve() y la solicitud falla.

Manejadores de eventos de webhook compatibles

Todos los manejadores son opcionales y asíncronos, y reciben la carga útil verificada 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 adaptador 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