Skip to main content
El adaptador @dodopayments/fastify proporciona a tu aplicación Fastify tres controladores de rutas: Checkout devuelve URL de checkout, CustomerPortal envía a un cliente al Customer Portal y Webhooks verifica las solicitudes de webhook y llama a tus controladores de eventos.

Checkout Handler

Crea enlaces de pago y sesiones de checkout desde tu aplicación Fastify.

Customer Portal

Permite que los clientes gestionen sus suscripciones y datos.

Webhooks

Verifica y procesa eventos de webhook de Dodo Payments.

Instalación

1

Install the Package

Ejecuta el siguiente comando en la raíz de tu proyecto:
El paquete requiere Fastify 5.4.0 o posterior.
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 secreto de firma en DODO_PAYMENTS_WEBHOOK_KEY. Mientras desarrollas, utiliza una API key de modo de prueba con DODO_PAYMENTS_ENVIRONMENT=test_mode, porque una key de modo de prueba solo funciona con el modo de prueba. DODO_PAYMENTS_RETURN_URL es opcional.
Nunca confirmes tu archivo .env ni tus secretos en el control de versiones.

Ejemplos de controladores de rutas

Los ejemplos registran rutas en una instancia de Fastify creada con Fastify(). La ruta de webhook necesita el cuerpo sin procesar de la solicitud, por lo que su ejemplo añade un analizador de cuerpo de tipo string dentro de un plugin que contiene únicamente la ruta de webhook.
Utiliza este controlador para integrar el checkout de Dodo Payments en tu aplicación Fastify. Admite flujos de pago estáticos (GET), dinámicos (POST) y de sesión (POST). Checkout() devuelve un getHandler para el flujo estático y un postHandler para los flujos dinámico y de sesión. Registra cada flujo POST en su propia ruta.

Controlador de rutas de checkout

El adaptador admite los tres flujos de checkout de Dodo Payments. Define type en la configuración del controlador para elegir el flujo que sirve una ruta. Cada flujo responde con JSON que contiene un checkout_url que el cliente puede abrir.
  • Enlaces de pago estáticos: type: "static", GET. Crea un enlace de pago para un producto a partir de parámetros de consulta, después de comprobar que el producto existe.
  • Enlaces de pago dinámicos: type: "dynamic", POST. Crea un pago único o una suscripción con un enlace de pago, según si el producto es recurrente.
  • Sesiones de checkout: type: "session", POST. Crea una sesión de checkout a partir de un carrito de productos y los datos del cliente. Utiliza este flujo para nuevas integraciones.
Checkout acepta estas opciones: Checkout devuelve un objeto con dos controladores. Registra getHandler para GET cuando type sea static, y postHandler para POST cuando type sea dynamic o session.

Parámetros de consulta admitidos

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
Dirección postal del cliente.
string
Ciudad del cliente.
string
Estado o provincia del cliente.
string
Código postal del cliente.
boolean
Define true para desactivar el campo de nombre completo.
boolean
Define true para desactivar el campo de nombre.
boolean
Define true para desactivar el campo de apellido.
boolean
Define true para desactivar el campo de correo electrónico.
boolean
Define true para desactivar el campo de país.
boolean
Define true para desactivar el campo de dirección.
boolean
Define true para desactivar el campo de ciudad.
boolean
Define true para desactivar el campo de estado.
boolean
Define true para desactivar el campo de código postal.
string
La moneda de pago, por ejemplo USD.
boolean
predeterminado:"true"
Muestra u oculta el selector de moneda.
number
Fija el importe cobrado, en unidades principales 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 al checkout como metadata, por ejemplo metadata_orderId=123.
Una bandera de desactivación solo tiene efecto cuando es true y el campo correspondiente tiene un valor, por ejemplo email con disableEmail. El controlador pasa estos parámetros a un enlace de pago estático.
Si falta productId, el controlador devuelve una respuesta 400. Los parámetros de consulta no válidos o un producto que no exista en tu cuenta también producen una respuesta 400.

Formato de respuesta

El checkout estático devuelve una respuesta JSON con la URL de checkout:
  • Envía los parámetros como un cuerpo JSON en una solicitud POST.
  • Admite pagos únicos y recurrentes. El controlador recupera el producto y crea una suscripción si el producto es recurrente; de lo contrario, crea un pago único.
  • El cuerpo necesita billing (con street, city, state, country y zipcode) e customer, además de product_id (con un quantity opcional) o product_cart. Las suscripciones necesitan product_id.
  • El controlador también reenvía metadata, allowed_payment_method_types, billing_currency, discount_codes (o el obsoleto discount_code), return_url, show_saved_payment_methods e tax_id. Para las suscripciones, también reenvía addons, on_demand e trial_period_days. Ignora los demás campos.
  • Para obtener detalles de los campos, consulta:
El checkout dinámico llama a los endpoints obsoletos POST /payments e POST /subscriptions. Utiliza Checkout Sessions para nuevas integraciones.

Formato de respuesta

El checkout dinámico devuelve una respuesta JSON con el enlace de pago como URL de checkout:
Envía un payload de sesión de checkout como cuerpo JSON. El controlador crea una sesión de checkout que gestiona el flujo de pago completo para compras únicas y suscripciones, y devuelve su checkout_url. product_cart es obligatorio y debe contener al menos un producto.Cada checkout_url funciona una vez y caduca después de 24 horas, o después de 15 minutos cuando pasas confirm: true. Una sesión creada con payment_method_id no devuelve checkout_url, por lo que el controlador responde con 400.Consulta la Guía de integración de Checkout Sessions para obtener más información y la lista completa de campos admitidos.

Formato de respuesta

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

Controlador de rutas de Customer Portal

El controlador de rutas de Customer Portal crea una sesión de Customer Portal para el cliente en customer_id y redirige la solicitud al enlace del portal. CustomerPortal acepta las opciones bearerToken e environment, igual que Checkout. Si Dodo Payments no puede crear la sesión, el controlador devuelve 500.

Parámetros de consulta

string
requerido
El ID del cliente para la sesión del portal, por ejemplo ?customer_id=cus_123.
boolean
Si se define como true, envía al cliente un correo electrónico con el enlace del portal.
Devuelve 400 si falta customer_id. El controlador no autentica la solicitud y abre el portal para cualquier customer_id que reciba, por lo que debes proteger la ruta con tu propia autenticación y pasar únicamente el ID de cliente del usuario que ha iniciado sesión.

Controlador de rutas de webhook

El controlador de webhook verifica cada solicitud con tu secreto de webhook, proporcionado como webhookKey, y después llama a tus controladores de eventos.
El controlador de webhook necesita el cuerpo sin procesar de la solicitud como string, por lo que debes añadir un analizador de tipo de contenido para application/json con parseAs: 'string'. Fastify aplica un analizador a todas las rutas del ámbito en el que lo añadas. Añádelo dentro de un plugin que registre únicamente la ruta de webhook, como en el ejemplo. En la instancia raíz, también pasaría un string a los controladores POST de checkout, que devolverían 400.
  • 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, siguiendo la especificación de Standard Webhooks. Devuelve 401 si la verificación falla.
  • Validación del payload: Se valida con Zod. Devuelve 400 para payloads no válidos.
  • Gestión de errores:
    • 401: Firma no válida
    • 400: Payload no válido
    • 500: Error interno durante la verificación
  • Enrutamiento de eventos: Llama a onPayload para cada evento, después al controlador correspondiente al tipo de evento y devuelve 200 cuando terminan. El controlador no captura los errores que arrojen tus controladores de eventos.

Controladores de eventos de webhook admitidos

Todos los controladores son opcionales y asíncronos. Para consultar el payload de cada evento, consulta la Guía de eventos de webhook.

Prompt para LLM

Última modificación el 28 de septiembre de 2026