Cuántas veces reintentar un cobro fallido y en qué días

1. Comprueba qué ocurrió antes de decidir

El primer paso no es elegir una hora para volver a cobrar, sino verificar el resultado de la operación anterior. Debes distinguir pago confirmado, fallo confirmado y resultado incierto. Si hay una operación en curso o falta una respuesta concluyente, investiga su referencia antes de iniciar otra: la ausencia de una pantalla de éxito no demuestra por sí sola que el cargo no exista.

Relaciona el intento con la obligación, el cliente, el importe y el periodo. Revisa si el cliente ha pagado por otra vía desde el fallo. Una recuperación manual sobre una deuda que ya se resolvió por transferencia puede producir una duplicidad aunque el intento anterior con tarjeta hubiera fallado correctamente.

Conserva el código o explicación disponible, pero no interpretes más de lo que permite. Un resultado ambiguo no acredita automáticamente falta de fondos ni un problema de activación del comercio. La siguiente acción debe corresponder a la evidencia y a la situación actual, no a una suposición basada solo en el nombre del estado.

2. La política vigente: tres intentos ordinarios en total

En la versión revisada para esta guía, el proceso recurrente de PagosRecurrentes incrementa el contador ante un fallo ordinario. Si todavía no ha alcanzado el límite, reprograma el siguiente vencimiento para el día siguiente. Al llegar a tres intentos fallidos ordinarios en total, la suscripción se marca como fallida.

El primer fallo ya cuenta. Por tanto, no debe explicarse como tres reintentos adicionales después del inicial. La regla describe el tratamiento ordinario del proceso programado; no es una autorización para lanzar manualmente tres cargos seguidos ni una promesa de recuperación.

La fecha programada se calcula con la zona horaria de la operativa. Que el vencimiento se sitúe al comenzar el día siguiente no garantiza que el cargo se ejecute exactamente a las 00:00: depende también de la ejecución del proceso y de las condiciones que permitan realizarlo. Consulta el próximo vencimiento registrado en vez de deducir una hora exacta a partir del texto de esta guía.

3. Los errores del comercio tienen otro tratamiento

El sistema distingue determinados errores de configuración bancaria del comercio y de construcción de la petición de integración. Esos errores identificados no se contabilizan como fallos ordinarios del cliente. Se mantiene el tratamiento específico de la incidencia y se programa una revisión posterior conforme al proceso, pero la causa puede necesitar una actuación del comercio, del banco o de la plataforma.

Pedir otra tarjeta no arregla necesariamente una operativa recurrente que el banco no ha habilitado para ese comercio. Tampoco resuelve una petición técnica mal construida. Por eso la comunicación debe dirigirse a quien puede corregir el problema y no presentar al cliente como responsable de una situación ajena.

No todos los códigos permiten una conclusión única. Algunos resultados son ambiguos y requieren contrastar configuración, referencias y respuesta del proveedor. Esta guía no pretende ofrecer una tabla universal de errores ni sustituir una revisión técnica. Que un caso quede fuera del contador ordinario tampoco significa que convenga iniciar intentos manuales indefinidos.

4. Identifica cuándo hace falta una actuación previa

Una tarjeta caducada, una autenticación requerida o una indicación de usar otro método pueden exigir que el cliente complete un paso seguro. En esos casos, esperar un día no sustituye esa actuación. Revisa el mensaje del proveedor y facilita el circuito correspondiente sin pedir por correo números completos de tarjeta, códigos de seguridad o contraseñas bancarias.

La explicación de qué ocurre cuando caduca una tarjeta de suscripción desarrolla la actualización del método. Después hay que comprobar el cobro pendiente: actualizar datos y recuperar dinero son hitos distintos. No anuncies un pago correcto únicamente porque se haya completado el cambio de tarjeta.

También puede existir una incidencia temporal sin información suficiente sobre cuándo se resolverá. En lugar de prometer que mañana funcionará, explica la próxima revisión y las acciones disponibles. Coordina cualquier intervención manual con el proceso programado para no crear dos vías de recuperación simultáneas sobre la misma obligación.

5. Ejemplo ficticio del ciclo ordinario

Una suscripción ficticia tiene una cuota pendiente de 30 €. El 8 de septiembre se registra el primer fallo ordinario. Si procede continuar, el siguiente vencimiento queda programado para el 9. Si ese segundo intento también falla ordinariamente, el siguiente se programa para el 10. Un tercer fallo ordinario alcanza el límite y marca la suscripción como fallida.

Este ejemplo presupone que el proceso se ejecuta y que no intervienen excepciones ni cambios de estado. No es una recomendación universal para todos los proveedores. La deuda del ejemplo sigue siendo 30 €, no 90 €: tres intentos sobre una obligación no multiplican el importe que debía pagarse.

6. No confundas esta política con Smart Retries

Stripe Billing dispone de una función propia llamada Smart Retries, con reglas y configuración descritas en su documentación. No debe atribuirse esa función a PagosRecurrentes por el hecho de que una operativa pueda utilizar Stripe como pasarela.

La política aquí explicada es la comprobada en el proceso recurrente de PagosRecurrentes. No anuncia una selección predictiva del mejor momento, un calendario adaptativo ni un porcentaje garantizado de recuperación. Si comparas herramientas, distingue el procesamiento del pago de las funciones específicas de gestión de suscripciones y recuperación que hayas contratado.

Tampoco traslades automáticamente a tu caso una recomendación de días o número de intentos publicada para otro sistema. La causa del fallo, las condiciones del proveedor, la configuración y las acciones requeridas pueden cambiar el tratamiento. Antes de modificar una operativa, revisa qué controla realmente cada componente y quién es responsable de la decisión.

7. Cierra la incidencia con un resultado comprobado

Tras una recuperación, verifica operación, importe y obligación. Revisa el estado de la suscripción y el próximo vencimiento, especialmente si hubo una intervención manual. Guarda una referencia que permita explicar por qué el caso se considera resuelto y evita dejar avisos pendientes que sigan reclamando el mismo importe.

Si se alcanza el estado fallido, la cuestión pasa a revisión; no significa que la deuda desaparezca ni que el contrato quede jurídicamente resuelto por sí solo. La continuidad del servicio, la comunicación y cualquier decisión posterior deben seguir el acuerdo y las reglas aplicables.

La página de funcionalidades permite revisar el alcance de la herramienta de cobro. No incluye una promesa de conciliación bancaria automática ni sustituye las decisiones sobre bajas o devoluciones. Separa el resultado técnico del cargo, el saldo económico y la relación con el cliente para no convertir un único estado en una respuesta a todas esas preguntas.

8. Checklist antes de un nuevo intento

• El resultado anterior está comprobado y no permanece incierto.
• La obligación, el periodo y el importe siguen pendientes.
• Se han revisado pagos por otras vías.
• El contador se interpreta como intentos totales, incluido el inicial.
• Se distingue fallo ordinario de error identificado del comercio.
• Las acciones requeridas por el proveedor están atendidas o identificadas.
• La intervención manual está coordinada con el proceso programado.
• El resultado final y el siguiente vencimiento se revisarán después.

La mejor siguiente acción puede ser esperar el proceso previsto, pedir una actualización segura o corregir la configuración. No elijas únicamente por el deseo de recuperar el importe cuanto antes. Un control claro del resultado anterior protege frente a duplicidades y permite dar al cliente una explicación más útil que una sucesión de avisos idénticos.