@dodopayments/sveltekit proporciona a tu aplicación de SvelteKit tres controladores de rutas. Checkout devuelve URL de checkout, CustomerPortal envía al cliente a Customer Portal y Webhooks verifica los eventos de webhook y los dirige a tu código.
Checkout Handler
Crea URL de checkout desde tu aplicación de SvelteKit.
Customer Portal
Permite que los clientes gestionen 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 SvelteKit 2 (
@sveltejs/kit 2.20.3 o posterior) y zod 3.25 o posterior como dependencias peer.2
Set Up Environment Variables
Crea un archivo Crea la clave de API en Developer → API Keys. Añade tu endpoint de webhook en Developer → Webhooks y copia su secreto de firma en
.env en la raíz de tu proyecto:DODO_PAYMENTS_WEBHOOK_KEY. DODO_PAYMENTS_RETURN_URL es el destino al que llegan los clientes después del checkout. Si no pasas un entorno, los controladores usan live_mode.Ejemplos de controladores de rutas
Los ejemplos son endpoints
+server.ts de SvelteKit en src/routes/api/. Importan tus credenciales desde $env/static/private, que SvelteKit mantiene fuera del código del cliente.- Checkout Handler
- Customer Portal Handler
- Webhook Handler
Usa este controlador para añadir el checkout de Dodo Payments a tu aplicación de SvelteKit.
Checkout devuelve un controlador GET para checkout estático y un controlador POST para sesiones de checkout, o para checkout dinámico cuando estableces type: "dynamic". Exporta GET desde un controlador creado con type: "static" o sin type, porque el controlador GET de un controlador session o dynamic devuelve 400.POST proviene de un controlador creado con type: "dynamic". Con type: "session", como en la ruta de ejemplo, envía la solicitud de sesión de checkout.Controlador de rutas de checkout
El controlador de checkout admite las tres formas de aceptar pagos con Dodo Payments:- Enlaces de pago estáticos: URL que se pueden compartir y que recaudan pagos sin código.
- Enlaces de pago dinámicos: Enlaces de pago que generas con datos personalizados. Utilizan endpoints obsoletos.
- Sesiones de checkout: Checkout alojado con un carrito de productos, datos del cliente y opciones de personalización. Este es el flujo recomendado.
Checkout acepta estas opciones:
Static Checkout (GET)
Static Checkout (GET)
Parámetros de consulta admitidos
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.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 modo de prueba, la URL utilizatest.checkout.dodopayments.com.Dynamic Checkout (POST)
Dynamic Checkout (POST)
Checkout Sessions (POST)
Checkout Sessions (POST)
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 controlador utiliza returnUrl de su configuración.Para obtener más detalles y consultar todos los campos admitidos, visita la Guía de integración de Checkout Sessions.Una sesión creada con payment_method_id no devuelve ninguna URL de checkout, por lo que el controlador responde con 400. Para cobrar mediante 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:Controlador de rutas de Customer Portal
El controlador 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 302.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.Controlador de rutas de webhook
El controlador de rutas de webhook verifica cada solicitud antes de ejecutar tu código:- Método: Solo se admiten solicitudes POST. Otros métodos devuelven 405.
- Verificación de firma: Verifica el cuerpo sin procesar de la solicitud y los encabezados
webhook-id,webhook-timestampywebhook-signatureconwebhookKey, siguiendo la especificación de Standard Webhooks. Devuelve 401 si la verificación falla. - Validación de payload: Valida el payload con Zod. Devuelve 400 para un payload no válido.
- 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
onPayloadpara cada evento, después al controlador correspondiente al tipo de evento y devuelve 200.