Cobros recurrentes: estados, impagos y reintentos explicados

Los cobros recurrentes fiables requieren desacoplar la ejecución del pago respecto al acceso del usuario, gestionando tres estados fundamentales: activo, en periodo de gracia e impagado. La lógica se sustenta en escuchar webhooks de la pasarela, aplicar reintentos automáticos con retroceso exponencial durante catorce días y pausar privilegios sin borrar datos de la cuenta.

El ciclo de vida de una suscripción y sus tres estados clave

Un modelo de cobro recurrente bien estructurado nunca pasa directamente de un fallo transaccional a la cancelación total del servicio. Si una tarjeta es rechazada un lunes por la mañana y tu sistema revoca el acceso de inmediato, estás transformando un error técnico o temporal de liquidez en una baja voluntaria forzada.

El ciclo de vida estándar consta de tres fases bien delimitadas:

1. Estado activo: La última factura asociada al periodo corriente está liquidada. La fecha de renovación futura está fijada en la base de datos y el usuario disfruta de todos los privilegios de su plan.
2. Periodo de gracia (past due): El cobro automático ha fallado, pero la aplicación mantiene los accesos operativos durante una ventana de tiempo predefinida (habitualmente entre 7 y 14 días). El sistema inicia la secuencia de recuperación sin bloquear la operativa del cliente.
3. Estado impagado o suspendido: Tras agotar los reintentos programados sin éxito, el sistema degrada la cuenta a un modo de solo lectura o congela el acceso a funciones avanzadas, pero conserva intactos los datos del usuario para facilitar una reactivación futura.

Separar la entidad comercial de la suscripción de la entidad de acceso en tu base de datos evita inconsistencias. Tu tabla de usuarios no debería tener un booleano is_pro, sino una relación con una tabla de suscripciones que registre el estado devuelto por la pasarela y la fecha de expiración del acceso garantizado.

Estrategias de reintento automático frente a fallos transaccionales

El 80 % de los fallos de tarjeta en pagos periódicos corresponden a errores recuperables como fondos insuficientes temporales o bloqueos preventivos por antifraude del banco emisor. Reintentar el cobro a los cinco minutos del primer fallo suele ser un desperdicio de peticiones que además puede activar alarmas de fraude en la entidad bancaria.

Para optimizar la recuperación de ingresos involuntarios, aplica las siguientes reglas de programación:

• Retroceso exponencial escalonado: Programa los reintentos en intervalos crecientes, por ejemplo a las 24 horas, a los 3 días, a los 7 días y a los 12 días del fallo inicial.
• Sincronización con ciclos de nómina: Gran parte de las suscripciones B2C y para profesionales independientes fallan por liquidez a finales de mes. Programar un reintento entre el día 1 y el día 3 del mes siguiente aumenta drásticamente la tasa de liquidación exitosa.
• Diferenciación entre fallos suaves y duros: Un error de fondos insuficientes (insufficient_funds) es un fallo suave que justifica reintentos; una tarjeta reportada como robada o perdida (stolen_card) es un fallo duro que debe cancelar los reintentos automáticos de forma fulminante.

Puedes orquestar esta secuencia desacoplada programando tareas en background con tu base de datos, encolando eventos de cobro sin necesidad de introducir dependencias complejas en tu infraestructura.

Comparativa de políticas de reintento según el código de fallo bancario

Las respuestas que devuelven redes como Visa o Mastercard determinan si tiene sentido volver a procesar la tarjeta o si debes exigir una intervención directa del titular.

Manejo estricto de webhooks e idempotencia en renovaciones

La pasarela de pago procesa las renovaciones de forma asíncrona y emite múltiples eventos de webhook para una misma factura cuando la red experimenta latencia o reintentos de entrega. Si tu endpoint de webhooks procesa dos veces el evento invoice.paid, corres el riesgo de generar facturas duplicadas, emitir notificaciones redundantes o desajustar los registros contables.

Para garantizar la idempotencia en tu backend:

1. Registra los identificadores de evento: Guarda cada event_id entrante en una tabla de PostgreSQL con una restricción de unicidad (UNIQUE). Si la base de datos rechaza la inserción por clave duplicada, responde con un código HTTP 200 OK inmediatamente sin reejecutar la lógica de negocio.
2. Opera sobre el estado de la factura: No sumes días de acceso ciegamente a la fecha actual. Establece la nueva fecha de vencimiento utilizando la marca temporal que la pasarela especifica en el campo current_period_end del evento.
3. Verifica la firma criptográfica: Comprueba la firma del payload mediante la clave secreta de webhook compartida para evitar inyecciones maliciosas que simulen renovaciones falsas.

En entornos de producción donde interactúas con plataformas de facturación y pagos con Cifrago, este tratamiento determinista resulta crítico para asegurar que los asientos contables y los registros fiscales coincidan al milímetro con el dinero liquidado en el banco.

Dunning y comunicación durante el periodo de gracia

El proceso de dunning engloba todas las comunicaciones automatizadas diseñadas para recuperar un cobro fallido antes de suspender el servicio al cliente. La efectividad del dunning no reside en la insistencia del mensaje, sino en reducir la fricción técnica para que el usuario solucione el problema.

Un correo que dice «Tu pago ha fallado, inicia sesión, ve a Ajustes, pulsa en Facturación y cambia la tarjeta» genera un abandono altísimo. En su lugar, envía un enlace directo firmado criptográficamente y con caducidad temporal que dirija al usuario a una página segura donde pueda introducir el nuevo método de pago en dos clics, sin necesidad de recordar contraseñas complejas.

Asimismo, refuerza la comunicación dentro de la propia aplicación web. Un banner superior sutil que alerte de la incidencia durante el periodo de gracia suele tener el doble de conversión que las notificaciones por correo electrónico, que a menudo terminan en bandejas de promociones o spam. Recuperar este tipo de bajas involuntarias protege los ingresos base con un coste marginal prácticamente nulo, superando en eficiencia a las estrategias centradas exclusivamente en perseguir métricas críticas de retención mediante campañas de reactivación tardías.

Arquitectura de datos para evitar desincronizaciones de cobro

Almacenar únicamente el estado devuelto por la pasarela en una columna de texto crea condiciones de carrera entre la interfaz y el backend. Si el usuario actualiza su tarjeta en tu frontend mientras la pasarela está reintentando un cobro en segundo plano, dos procesos concurrentes intentarán modificar el mismo registro.

Diseña un esquema basado en eventos o mantén un registro de auditoría (payment_attempts) donde cada intento de cobro guarde su propio registro con marca de tiempo, código de error devuelto y estado resultante. De esta manera, el estado de la suscripción se calcula como una función determinista del último intento procesado y la fecha de gracia acordada.

Cuando estructures este flujo, asegúrate de que la degradación de cuenta a modo restringido nunca destruya configuraciones, claves de API ni historiales de trabajo. La mayoría de los usuarios que sufren un impago involuntario vuelven a pagar cuando necesitan la herramienta; ponérselo fácil el día que decidan regresar es la mejor optimización de retención que puedes implementar.