Una aplicación generaba enlaces de Stripe Checkout para varios planes mensuales. El cliente necesitaba una nueva suscripción de 90 €, pero no recordábamos cómo se habían creado los enlaces anteriores. Antes de modificar código, estudié el recorrido completo.
El importe no se definía en la URL
La aplicación no aceptaba cualquier cantidad enviada como parámetro. Eso habría permitido manipular precios. Cada plan público se correspondía con un identificador price_... creado previamente en Stripe.
El enlace solo enviaba una clave interna, por ejemplo plan-6. El servidor la validaba contra una lista privada y utilizaba el identificador real para crear la sesión de Checkout.
El proceso correcto
- Abrir el producto correspondiente en Stripe.
- Crear un precio de 90 €, EUR, recurrente y mensual.
- Copiar el identificador del precio.
- Añadirlo al mapa privado de planes de la aplicación.
- Generar el enlace utilizando únicamente la clave interna.
- Completar una prueba y revisar el webhook.
Por qué utilizo un mapa cerrado
Evita que alguien modifique el importe desde el navegador. También permite retirar un plan, cambiar su nombre visible o mantener distintos precios para un mismo producto sin exponer secretos.
Checkout no termina el trabajo
La aplicación solicitaba nombre, documento y datos de facturación. Después del pago, el webhook debe confirmar la suscripción de forma independiente. No conviene confiar únicamente en la página de éxito, porque el usuario puede cerrarla o abrirla manualmente.
Qué verifico al añadir un plan
- Moneda, periodicidad e impuestos.
- Entorno de pruebas frente a producción.
- Estado de la suscripción después del webhook.
- Correos y portal de cliente.
- Qué sucede con impagos, cancelaciones y reintentos.
La lección
Un enlace de pago parece una cadena de texto, pero representa reglas comerciales y estados posteriores. Documentar la relación entre producto, precio, plan interno y webhook evita depender de la memoria la próxima vez.