Cuándo caduca RedSys en un pago con tarjeta

Un cliente llega a la pantalla bancaria de RedSys, recibe una llamada, cierra el navegador y vuelve media hora después. Entonces aparece un aviso de operación no válida, sesión finalizada o pago cancelado. En ese momento surge la duda: cuándo caduca RedSys y si el problema está en la tarjeta, en WooCommerce o en la configuración del TPV virtual.

La respuesta corta es que RedSys no tiene un único plazo de caducidad aplicable a todos los comercios. Depende de la operación, de la configuración contratada con el banco y de cómo se haya integrado la pasarela. Lo que sí conviene tener claro es que una sesión de pago no permanece abierta indefinidamente, y que confundir ese plazo con la caducidad de una tarjeta o de una autorización puede generar incidencias innecesarias.

Cuándo caduca RedSys durante un pago

En un pago habitual con RedSys, el cliente sale de la tienda o del formulario y entra en el entorno seguro del banco para completar la autenticación. Esa sesión tiene un tiempo limitado. Si el usuario tarda demasiado en introducir los datos, abandona la página o vuelve cuando la operación ya ha expirado, RedSys puede rechazar el intento y la tienda no recibirá un pago válido.

El plazo exacto no debe asumirse como una cifra universal. Puede variar según la entidad bancaria, el tipo de terminal, la configuración de seguridad y el canal utilizado. Algunos bancos aplican ventanas cortas para reducir el riesgo de fraude, mientras que otros pueden gestionar tiempos distintos en determinados productos, como enlaces de pago o cobros telefónicos.

Por este motivo, si necesitas confirmar el tiempo concreto de tu TPV, la referencia válida es la configuración facilitada por tu banco. No conviene basar una implementación en plazos publicados para otro terminal o en pruebas realizadas con una tarjeta concreta.

Cuando la sesión vence, no significa necesariamente que se haya cobrado al cliente. Lo habitual es que la operación quede cancelada o no autorizada. Aun así, antes de pedir un nuevo pago, el comercio debe revisar el estado real del pedido y la respuesta recibida desde RedSys para evitar duplicidades.

La pantalla sigue abierta, pero el pago ya no es válido

Una situación frecuente es que el navegador conserve visualmente la página bancaria, aunque la operación interna haya vencido. El cliente puede intentar confirmar el pago y recibir un error. Desde su perspectiva parece un fallo de la web, pero técnicamente la sesión ya no acepta autorizaciones.

La solución correcta no es obligar al cliente a recargar repetidamente la pantalla del banco. Debe volver al checkout, generar una nueva operación y realizar el pago desde el principio. En WooCommerce, esto requiere que el pedido mantenga un estado coherente y que la integración pueda crear un nuevo intento sin marcar como pagado un pedido pendiente.

No todas las caducidades de RedSys son la misma cosa

La expresión caducar puede referirse a varios elementos distintos. Separarlos ayuda a diagnosticar el problema con rapidez.

La primera posibilidad es la sesión de pago. Es el caso más común: el cliente tarda demasiado en completar la operación y debe iniciarla de nuevo. Aquí no hay una tarjeta vencida ni una incidencia con las claves del comercio.

La segunda es la caducidad de la tarjeta. Si la fecha de la tarjeta ya ha pasado, el banco emisor rechazará el pago. RedSys actúa como pasarela de procesamiento, pero no puede autorizar una tarjeta que ya no está vigente. También pueden producirse rechazos por límites, fondos insuficientes, restricciones de compra online o una autenticación reforzada no completada.

La tercera afecta a pagos recurrentes o tokenizados. Si una tienda guarda una referencia de pago para renovar una suscripción, la renovación puede fallar cuando la tarjeta original ha sido sustituida, ha caducado o el banco ya no permite utilizar ese identificador. En este escenario no ha expirado una sesión de checkout, sino el medio de pago asociado al cliente.

También conviene diferenciar los pagos inmediatos de las preautorizaciones. En una venta normal, el cobro se confirma en el momento de la autorización. En negocios como hoteles, alquileres o reservas, puede existir una preautorización que retiene importe durante un tiempo limitado antes de confirmarla o cancelarla. Sus plazos y reglas no son los mismos que los de un pago estándar y dependen del producto bancario contratado.

Qué ocurre en WordPress y WooCommerce al expirar el pago

En una integración bien configurada, el pedido no debería pasar a completado solo porque el cliente haya llegado a RedSys. El cambio de estado debe producirse cuando la tienda recibe y valida la notificación del banco con una firma correcta y un resultado autorizado.

Esta diferencia es esencial. El retorno del navegador puede fallar porque el cliente cierre la pestaña, pierda conexión o bloquee una redirección. La notificación servidor a servidor, en cambio, es la que permite confirmar el estado con mayor fiabilidad. Si el pago caduca o es rechazado, el pedido debe mantenerse pendiente, fallido o cancelado según la lógica definida para el proyecto.

Un error habitual es interpretar cualquier regreso a la página de gracias como un pago exitoso. Eso genera pedidos entregados sin cobro o confusión en el equipo de atención al cliente. La página de retorno mejora la experiencia del usuario, pero no sustituye la validación criptográfica de la respuesta de RedSys.

En formularios de donación, reservas y venta de entradas el criterio es el mismo. No reserves una plaza definitivamente, no emitas una entrada y no confirmes una donación solo por haber creado la solicitud de pago. Espera la confirmación válida de la pasarela o establece una reserva temporal con una caducidad controlada.

Cómo reducir pagos caducados y carritos abandonados

No es posible eliminar por completo los pagos abandonados, pero sí reducir los que se deben a una experiencia técnica deficiente. La primera medida es revisar el checkout antes de enviar al cliente al banco. Los importes, gastos, campos obligatorios y condiciones deben estar claros para que el usuario no tenga que volver atrás a buscar información.

También ayuda mostrar un mensaje breve antes de la redirección. Indicar que el pago se realizará en una página bancaria segura y que conviene completarlo sin cerrar la ventana prepara al comprador y evita que interprete el cambio de dominio como un error.

En proyectos con procesos largos, como reservas con muchos datos o formularios de inscripción, conviene guardar la información antes de iniciar el pago. Si la sesión de RedSys expira, el usuario debe poder reintentar sin rellenar todo de nuevo. La recuperación del pedido pendiente es especialmente útil cuando se venden servicios de importe alto, donde el cliente puede necesitar más tiempo para consultar su tarjeta o aprobar la compra.

Desde el punto de vista técnico, revisa que las URL de notificación y retorno sean accesibles, que WordPress no bloquee peticiones legítimas y que no existan cachés aplicadas al checkout o a las páginas de confirmación. Un sistema de seguridad mal ajustado puede confundir una notificación real con tráfico sospechoso y dejar pedidos sin actualizar, aunque el banco haya autorizado el pago.

Por último, evita reutilizar una operación vencida. Cada reintento debe generar los parámetros correctos para el nuevo contexto del pedido. Forzar el uso de una solicitud antigua puede provocar rechazos, mensajes poco claros o una conciliación más compleja.

Cómo comprobar si el pago se cobró realmente

Cuando un cliente afirma que el pago ha caducado pero ve un movimiento en su banco, no conviene responder de inmediato que se trata de un cobro definitivo. En ocasiones puede ser una retención temporal, una autorización que posteriormente se libera o un movimiento pendiente de confirmación.

La comprobación debe hacerse en este orden: revisa el pedido en WordPress o WooCommerce, consulta el registro técnico de la pasarela y verifica la operación en el panel bancario del TPV. Si los tres datos no coinciden, la información del banco y la respuesta firmada de RedSys son las referencias para decidir si se entrega el pedido, se solicita un nuevo pago o se inicia una devolución.

Guardar registros con el identificador de pedido, el número de operación, el importe y el resultado recibido facilita mucho esta tarea. También permite detectar problemas recurrentes, como usuarios que expiran la sesión durante un paso concreto o notificaciones que no llegan por un conflicto de servidor.

Una integración especializada de RedSys para WooCommerce o para formularios debe contemplar estos escenarios desde el inicio: validar la notificación, gestionar reintentos, conservar el pedido pendiente y evitar duplicar cargos. Si el flujo no está claro, revisar la configuración antes de una campaña, una apertura de reservas o un pico de ventas ahorra incidencias cuando más cuesta atenderlas.

La mejor respuesta a una sesión caducada no es prolongar artificialmente el proceso, sino permitir que el cliente vuelva a pagar con claridad y que el sistema sepa distinguir siempre entre un intento iniciado, un pago autorizado y una operación realmente confirmada.

Nota: Hay una valoración incrustada en esta entrada, por favor, visita esta entrada para valorarla.

Almacenamos las IPs desde la que se envían las valoraciones para evitar fraudes