PrestaShop está construido en torno a un acto único: un carrito, un pedido, un pago. La suscripción supone lo contrario, un compromiso que produce pagos en el tiempo sin que el cliente vuelva. Estos dos modelos no se encuentran de forma natural.
Aquí está la arquitectura que funciona, y los puntos donde las implementaciones se rompen.
Quién posee la verdad
Primera decisión, y condiciona todo lo demás.
Una plataforma de pago como Stripe dispone de un motor de facturación recurrente completo: suscripciones, vencimientos, reintentos, gestión de tarjetas caducadas. Reconstruir eso en PrestaShop sería un error.
El reparto que se sostiene: Stripe posee la suscripción, es decir el ciclo, los vencimientos y el cobro. PrestaShop posee el catálogo, el cliente y los pedidos generados en cada vencimiento.
En concreto, cada cobro exitoso crea un pedido en PrestaShop, que sigue después tu proceso normal de preparación y envío. Es lo que permite mantener coherentes tus estadísticas, tus facturas y tu logística.
Los webhooks que hay que escuchar
Es el corazón de la integración, y el punto donde está realmente el trabajo.
Cinco eventos deben tratarse, cada uno con un comportamiento preciso.
- El pago de vencimiento exitoso. Crea el pedido en PrestaShop, decrementa el stock, dispara el correo de confirmación.
- El pago fallido. No crea pedido, pone la suscripción en espera, dispara la secuencia de reclamación.
- La suscripción actualizada. Cambio de plan, de cantidad, de fecha. Debe repercutirse del lado de la tienda.
- La suscripción cancelada. Corta el acceso si vendes contenido, detiene los envíos si vendes producto físico.
- El medio de pago próximo a caducar. Dispara un aviso antes del fallo, lo que evita la interrupción.
Tres reglas técnicas sobre los webhooks. Verifica la firma de cada notificación, si no cualquiera puede crear pedidos en tu tienda. Trátalos de forma idempotente: el mismo evento puede entregarse varias veces, y no debes crear dos pedidos. Y responde rápido acusando recibo, y luego procesa en segundo plano, o la plataforma considera la llamada fallida y la repite.
DataFirefly Subscriptions — Suscripciones y pago recurrente Stripe para PrestaShop 8 y 9El módulo de suscripciones para PrestaShop 8 y 9: Stripe card-on-file, dunning, área de cliente self-service.€169,00
Las tarjetas caducadas, primera fuente de pérdida
En una suscripción, la mayoría de las bajas sufridas vienen de un medio de pago que ha dejado de ser válido, no de una decisión del cliente.
Tres mecanismos se acumulan para limitar los daños. La actualización automática de las tarjetas, ofrecida por las redes y trasladada por las plataformas de pago, que recupera el nuevo número sin intervención. El aviso antes de la caducidad, disparado un mes antes de la fecha de fin de validez. Y la secuencia de reintento tras un fallo, repartida a lo largo de una o dos semanas en lugar de repetirse al día siguiente.
Prevé un periodo de gracia durante el cual el servicio sigue activo pese al fallo. Cortar de inmediato transforma un incidente bancario en una baja definitiva.
El proceso de compra: no mezclar
Cuestión de diseño resuelta a menudo demasiado tarde. Un carrito que contiene una suscripción y productos de compra única plantea un problema: la primera crea un compromiso recurrente, los segundos no.
Dos enfoques aceptables. El proceso dedicado, donde la suscripción se contrata sola, sin posibilidad de añadir otra cosa. Más simple, más claro para el cliente, y es la opción por defecto recomendada.
O el carrito mixto, donde el pedido inicial contiene ambos, con un pago único que cubre los productos y activa la suscripción. Técnicamente más pesado, y hay que ser muy claro sobre lo que se cobrará después.
Lo que no hay que hacer: dejar dos suscripciones diferentes en el mismo carrito. Los ciclos de facturación divergen de inmediato y la gestión se vuelve inextricable.
La autenticación reforzada
La normativa europea sobre pagos impone una autenticación del titular para numerosas transacciones. En una suscripción, el primer pago lo autentica el cliente, los siguientes dependen de un marco diferente puesto que los inicia el comerciante.
Dos consecuencias prácticas. El mandato debe registrarse correctamente en el primer pago, cosa que las plataformas gestionan siempre que la intención de pago se cree con los parámetros adecuados. Y algunos vencimientos pueden exigir a pesar de todo una autenticación, lo que supone un recorrido previsto para devolver al cliente a una página de autenticación, en lugar de un fallo silencioso.
El marco legal
Tres obligaciones, controladas y regularmente incumplidas.
La información antes de la contratación: duración, importe, periodicidad y modalidades de baja deben verse en la página de compra, no solo en las condiciones generales.
La baja en línea, tan sencilla como el alta, accesible desde el área de cliente sin tener que escribir ni telefonear.
La información antes de la renovación para las suscripciones de renovación tácita, con un plazo que deje al cliente tiempo de rechazarla.
Las tres cifras del modelo
El ingreso recurrente mensual, que da la base económica. La tasa de bajas mensual, distinguiendo las bajas voluntarias de los fallos de pago, porque los remedios difieren. Y la duración de vida media de un suscriptor, que se deduce de la segunda y que determina cuánto puedes gastar en captar uno.
El módulo DataFirefly Subscriptions para PrestaShop pone en marcha esta arquitectura en PrestaShop 8 y 9: suscripciones apoyadas en Stripe, creación automática de los pedidos en cada vencimiento, tratamiento de los webhooks con verificación de firma, gestión de los fallos de pago y área de cliente para modificar o dar de baja.