¿Cómo crear un checkout de Dodo Payments con referidos?

Para crear un checkout de Dodo Payments en Next.js con códigos de referido en Supabase, valida el código en un endpoint del servidor, elige allí el producto correcto y envía al navegador únicamente la URL de pago alojada. El cliente nunca debe decidir el descuento ni ver la clave de servicio de Supabase.

¿Qué flujo evita descuentos falsos?

El flujo seguro es volver a comprobar cada código en el servidor justo antes de crear el checkout. Puedes enseñar una confirmación visual al usuario, pero esa validación de interfaz no autoriza el precio: una petición manipulada podría saltársela.

Normaliza el código —por ejemplo, quitando espacios, pasándolo a mayúsculas y limitando su longitud— y consulta una fila activa en Supabase. Si existe, selecciona el identificador del producto con descuento; si no existe o Supabase no está configurado, usa el precio completo. Ese fallo cerrado evita regalar el producto cuando un servicio auxiliar no responde.

¿Qué debe hacer exactamente el endpoint de checkout?

El endpoint debe aceptar un email y un código opcional, validar ambos, consultar Supabase con credenciales solo de servidor y crear el checkout en Dodo Payments. Guarda las claves, el entorno y los identificadores de producto en variables de entorno; el navegador recibe únicamente una URL a la que redirigir.

Incluye en los metadatos una fuente reconocible y el código ya validado. También conviene configurar una URL de retorno. No marques una compra como completada al volver a esa página: la fuente de verdad debe ser el webhook firmado. Si vienes de Stripe, la separación entre checkout y webhook se explica también en la guía de suscripciones con Next.js.

¿Cómo se modela el referido sin exponer Supabase?

El referido se modela con una tabla que contenga al menos el código, su estado activo y el porcentaje aplicable. La consulta privilegiada se ejecuta desde el servidor con la clave de servicio; nunca copies esa clave a una variable pública ni la incluyas en JavaScript del navegador.

Tras validar, conserva el código en los metadatos del pago. El webhook podrá asociar comprador, importe, identificador de pago y referido en una segunda tabla. Esto deja una pista auditable y permite que los reintentos se traten por el identificador único del pago, no por el email.

¿Qué hay que revisar antes de cobrar de verdad?

Antes de cobrar debes probar el precio completo, el código válido, el código inválido, la ausencia de configuración y una respuesta fallida de la pasarela. Comprueba también que el IVA mostrado y la documentación comercial corresponden a tu modelo; un merchant of record simplifica la operativa, pero tu caso empresarial sigue mereciendo revisión profesional. La guía sobre facturación de SaaS en España sirve como mapa inicial, no como asesoramiento personalizado.

IndiePack reúne este flujo con el resto del stack para que el checkout no sea una isla: auth, datos, deploy y entrega avanzan con las mismas convenciones.