No presupongas una renovación automática de tarjetas. Consulta el resultado del pago, envía un enlace seguro cuando corresponda y verifica qué importe solicita. En el flujo actual de PagosRecurrentes, el enlace de actualización prepara un cobro de la cuota completa: actualizar no debe confundirse con guardar una tarjeta sin cargo.
1. Confirma el resultado, no solo la fecha impresa
Que una tarjeta haya alcanzado su fecha de caducidad es una señal para revisar la suscripción del cliente, no una razón para dar todos sus pagos por fallidos. Consulta el último intento, el importe, la fecha, el proveedor y la respuesta recibida. Puede haber una cuota ya cobrada, otra todavía no vencida o una incidencia distinta de la caducidad.
No traduzcas cualquier rechazo a «tarjeta caducada». El emisor puede devolver otros motivos o una respuesta poco concluyente. Si la causa no está confirmada, comunícala como incidencia de pago y solicita al cliente que revise su método, sin inventar una explicación.
Relaciona el intento con el periodo pendiente. Una operación fallida no crea una mensualidad nueva: es un intento de satisfacer un importe concreto. Mantener esa relación evita que un proceso de recuperación termine cobrando dos veces el mismo mes.
2. Entiende qué se guarda para los cargos posteriores
En una operativa tokenizada, el sistema utiliza una referencia del proveedor para los cargos posteriores, no una fotografía de la tarjeta. La documentación de Redsys sobre tokenización MIT explica ese contexto de credenciales y pagos iniciados por el comercio.
Cuando el cliente sustituye su tarjeta, no basta con cambiar un dato visible en una ficha. Debe completarse el recorrido adecuado para el proveedor y la autorización correspondiente. La posibilidad de cobrar de nuevo también depende de la configuración del comercio y de la respuesta de la entidad.
Algunos emisores o proveedores pueden ofrecer mecanismos de actualización, pero no deben presentarse como una garantía general del producto. Diseña el procedimiento para detectar la incidencia, permitir una actualización segura y verificar el resultado, incluso si en ocasiones el método sigue funcionando sin intervención.
3. Comunica el problema sin pedir información sensible
El mensaje debe indicar el negocio, el periodo, el importe y el siguiente paso. Utiliza el canal habitual y un enlace cuyo origen pueda verificarse. No solicites el número completo de tarjeta, el código de seguridad, claves bancarias ni capturas de autenticación.
Un ejemplo ficticio sería: «Necesitamos revisar el pago de septiembre de 29 €. Te facilitamos un enlace seguro para actualizar el método y abonar esa cuota. Si ya la has pagado por otra vía, avísanos antes de continuar». El mensaje debe corresponder al importe y a la función real del enlace.
Si el cliente duda de la comunicación, ofrécele confirmar su origen por el contacto conocido del negocio. Evita presionarlo para que complete un enlace inesperado. La seguridad del recorrido también depende de que se entienda quién solicita el pago y por qué.
4. Revisa qué hace realmente el enlace de actualización
En el flujo actual de PagosRecurrentes, la actualización prepara un enlace asociado a la suscripción existente, con su proveedor y entorno. La opción configurada es un pago inmediato por el importe completo de la cuota. No lo describas como una simple actualización gratuita de datos.
Antes de generarlo o enviarlo, revisa el saldo pendiente y el importe de la suscripción. Si no hay nada vencido, o existe un pago parcial, no utilices a ciegas un enlace que solicite una cuota completa. Confirma el procedimiento adecuado para ese caso con soporte.
El recorrido también contempla caducidad del enlace y sustitución de enlaces anteriores no usados. Comprueba cuál es el enlace vigente; un mensaje antiguo puede haber dejado de servir. La generación y el envío de correo son pasos distintos, por lo que un problema de email no permite inferir que no se haya creado el enlace.
Puedes revisar las funcionalidades de seguimiento y gestión de suscripciones para situar este proceso dentro de la operativa completa. No es una promesa de recuperación automática de cualquier impago.
5. Comprueba la operación y el siguiente vencimiento
Cuando el cliente complete el recorrido, consulta la referencia del pago y su resultado en el sistema. No cierres el caso solo porque haya regresado a una página de confirmación o enviado una captura. Verifica también que estás mirando el entorno de producción y la suscripción correcta.
| Comprobación | Qué permite saber |
|---|---|
| Resultado del cargo | Si esa operación se ha aprobado o requiere revisión. |
| Importe y periodo | Qué cuota se está regularizando. |
| Estado de la suscripción | Cómo queda el seguimiento operativo. |
| Próxima fecha | Qué vencimiento debes comprobar después. |
Revisa los intentos pendientes y cualquier cobro preparado fuera de la plataforma. Una actualización correcta no cancela por sí sola una transferencia acordada, una orden bancaria o una reclamación que otro miembro del equipo esté gestionando.
6. Ejemplo ficticio: una cuota de 29 € pendiente
Un servicio ficticio tiene una cuota mensual de 29 €. El cargo de septiembre falla y el cliente informa de que ha recibido una tarjeta nueva. El negocio confirma que no existe otro pago de septiembre y revisa que el enlace de actualización solicite precisamente 29 €.
El cliente completa el flujo seguro y la operación se comprueba como aprobada. La persona responsable vincula el resultado con septiembre y revisa el siguiente vencimiento antes de cerrar la incidencia. No crea una segunda suscripción para la misma persona ni vuelve a reclamar el periodo resuelto.
Si el cliente hubiera transferido ya los 29 €, el procedimiento cambiaría: primero se contrastaría ese abono y después se buscaría el modo adecuado de actualizar la tarjeta sin duplicar el importe. El ejemplo describe una secuencia de revisión, no un resultado garantizado ni un caso real.
7. Organiza las revisiones y los reintentos
Asigna una persona responsable de las incidencias y una frecuencia de consulta. El objetivo es que cada caso tenga un siguiente paso, no que se acumulen mensajes automáticos. Una tarea concreta puede ser comprobar si el enlace fue completado y revisar el resultado antes de volver a contactar.
No reintentes indefinidamente sobre un método que el cliente ya ha indicado que no es válido. Respeta las reglas del proveedor, la clasificación del fallo y los límites configurados. Un rechazo persistente necesita revisión, no más frecuencia.
Separa además la disponibilidad técnica de la recurrencia de un cargo aceptado. Aunque el método se haya guardado, la activación del comercio puede requerir comprobaciones específicas. La comunicación al cliente debe limitarse a lo verificado en su operación.
8. Checklist para cerrar la actualización
- La causa se ha contrastado o se comunica como no confirmada.
- El periodo y el saldo pendiente están identificados.
- El cliente sabe que el enlace puede cobrar la cuota completa.
- Se utiliza el enlace vigente y un canal verificado.
- No se recogen datos sensibles fuera del proveedor.
- Se han comprobado resultado, suscripción y próximo vencimiento.
- Las otras vías de cobro se han revisado para evitar duplicados.
El trabajo termina cuando puedes explicar qué pago se resolvió y qué queda programado, no cuando se envía el enlace. Esa diferencia protege al cliente y hace más fiable el seguimiento.
Preguntas frecuentes
¿Las tarjetas de las suscripciones se renuevan automáticamente?
No debes darlo por hecho. Puede haber servicios del emisor o proveedor, pero PagosRecurrentes no promete una actualización automática de todas las tarjetas. La validez del método y el resultado de cada cargo necesitan su propia comprobación.
¿El enlace de actualización puede realizar un cobro?
Sí. El flujo actual prepara la cuota completa de la suscripción para pago inmediato. Revisa el importe y el periodo antes de enviarlo, informa al cliente y comprueba que esa cuota no se haya satisfecho ya por otro medio.
¿Basta con que el cliente me envíe la nueva fecha de caducidad?
No. No recojas datos de tarjeta por correo, mensajes o fotografías. El pagador debe completar el flujo seguro del proveedor, incluida la autenticación que se le solicite, para que el método quede actualizado correctamente.
¿Enviar el correo confirma que el método se ha actualizado?
No. La generación del enlace, el envío del mensaje, su recepción y la operación del cliente son pasos distintos. Debes revisar la operación y el estado posterior; si el correo falla, comprueba el enlace antes de comunicarlo por un canal verificado.
¿Una tarjeta nueva garantiza los próximos cargos?
No. Todavía pueden existir límites, falta de fondos, rechazos del emisor o una configuración recurrente no disponible. Un cargo aprobado confirma esa operación, no todos los pagos futuros ni la capacidad de recurrencia en cualquier circunstancia.
Ordena la actualización y el seguimiento de tus cobros
Revisamos un caso representativo y el calendario antes de ampliar el proceso. La prioridad es conocer qué está pendiente y qué cobrará exactamente el siguiente enlace.