@dodopayments/astro proporciona a tu proyecto de Astro tres controladores de endpoint. 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.
Checkout Handler
Crea URLs de checkout con flujos estáticos, dinámicos y de checkout session.
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 declara Astro 4 o 5 y
zod 3.25 o posterior como peer dependencies.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 destino de los clientes después del checkout. Si no pasas un entorno, los controladores usan live_mode. Una API key de test mode funciona únicamente con test_mode.Ejemplos de Route Handler
Los ejemplos son endpoints de servidor de Astro en
src/pages/api/. Los endpoints que llaman a Dodo Payments deben renderizarse bajo demanda, así que añade un server adapter a tu proyecto de Astro. En el modo de salida predeterminado static de Astro, los endpoints se renderizan en tiempo de compilación; por eso cada ejemplo exporta prerender = false para renderizar el endpoint en cada solicitud.- Checkout Handler
- Customer Portal Handler
- Webhook Handler
Usa este controlador para añadir el checkout de Dodo Payments a tu aplicación. El controlador
GET ofrece checkout estático. El controlador POST ofrece checkout sessions o checkout dinámico cuando configuras type: "dynamic". Un archivo de endpoint solo puede exportar un controlador POST, por lo que el ejemplo de checkout dinámico supone que configuras type: "dynamic".Checkout Route Handler
El controlador de checkout admite las tres formas de aceptar pagos con Dodo Payments:- Static Payment Links: URLs compartibles que recaudan pagos sin código.
- Dynamic Payment Links: enlaces de pago que generas con datos personalizados. Utilizan endpoints obsoletos.
- Checkout Sessions: checkout alojado con carrito de productos, datos del cliente y opciones de personalización. Este es el flujo recomendado.
Checkout acepta estas opciones:
El controlador ofrece checkout estático para solicitudes
GET. Para solicitudes POST, crea un enlace de pago dinámico cuando type es dynamic y una checkout session en los demás casos.
Static Checkout (GET)
Static Checkout (GET)
Parámetros de consulta compatibles
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 es inferior al precio mínimo del producto.Cualquier parámetro de consulta que comience por
metadata_ se pasa al checkout como metadata, por ejemplo metadata_orderId=123.email con disableEmail=true. El controlador añade returnUrl de su configuración al enlace como redirect_url.Formato de respuesta
El checkout estático devuelve una respuesta JSON con la URL de checkout. En test mode, la URL utilizatest.checkout.dodopayments.com:Dynamic Checkout (POST)
Dynamic Checkout (POST)
- Envía los parámetros como un body JSON en una solicitud POST.
- Admite pagos únicos y recurrentes. El controlador recupera el producto; después crea una suscripción si el producto es recurrente y un pago único en caso contrario.
- El body necesita
billing(constreet,city,state,countryezipcode) ecustomer, además deproduct_idoproduct_cart. Las suscripciones necesitanproduct_id. - Para consultar todos los campos de body compatibles, visita:
Formato de respuesta
El checkout dinámico devuelve una respuesta JSON con el enlace de pago como URL de checkout:Checkout Sessions (POST)
Checkout Sessions (POST)
Checkout sessions 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 body no contiene return_url, el controlador utiliza 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 pasas confirm: true. Una session creada con payment_method_id no devuelve checkout_url, por lo que el controlador 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
Checkout sessions devuelven una respuesta JSON con la URL de checkout:Customer Portal Route Handler
El route handler de Customer Portal crea una session de Customer Portal para el cliente que indiques y redirige el navegador a ella.CustomerPortal acepta las mismas opciones bearerToken e environment que Checkout.
Parámetros de consulta
Si se establece en
true, Dodo Payments también envía por correo electrónico el enlace del portal al cliente.customer_id y 500 si no se puede crear la session del portal.
Webhook Route Handler
El route handler de webhook verifica cada solicitud con tu secreto de webhook, pasado comowebhookKey, antes de ejecutar tu código:
- Method: Solo se admiten solicitudes POST. Los demás métodos devuelven 405.
- Signature Verification: Verifica los headers
webhook-id,webhook-timestampewebhook-signatureconwebhookKey, siguiendo la especificación 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
onPayloadpara cada evento, después al controlador correspondiente al tipo de evento y devuelve 200.