Redsys cobra pero no crea el pedido: la reputación de tu IP

Un cliente de Gustavo dejó de recibir pedidos de Redsys de un día para otro: el banco cobraba y PrestaShop no se enteraba. La causa no estaba en la tienda. Redsys consulta la reputación de la IP y de la URL de tu servidor y, si es mala, no valida la notificación. Te contamos cómo comprobarlo y qué más revisar cuando un pago no se convierte en pedido.

El síntoma: dinero en el TPV y nada en el back-office

Es una de las consultas que más se repiten en el grupo, con Redsys y con otras pasarelas. El cliente paga, el banco autoriza la operación, pero en PrestaShop solo queda un carrito abandonado. Otras veces el pedido aparece sin estado o no se ve en el listado aunque exista.

El mecanismo es casi siempre el mismo. El pedido no se crea cuando el cliente vuelve a la tienda, sino cuando la pasarela llama a la URL de notificación del módulo de pago. Si esa llamada no llega, llega tarde o se corta a medias, tienes el cobro y no tienes el pedido.

Caso 1: la reputación de tu servidor

A finales de diciembre de 2024 Gustavo pidió fijar un aviso en el grupo. Un cliente suyo llevaba días sin que se guardaran los pedidos pagados con Redsys. Tras hablar con Redsys, la explicación fue que desde hace un tiempo usan un servicio de reputación de IP y dominios, el de Talos (Cisco). Si la IP o la URL de tu tienda tienen mala reputación, Redsys no confirma la notificación y el pedido no se crea.

• Busca la IP de tu servidor y tu dominio en el centro de reputación de Talos Intelligence.
• Si salen con mala reputación, pide la revisión desde allí. Es tarea del dueño de la tienda o de quien gestiona el servidor, no del comprador.
• En un hosting compartido la IP es de todos: lo que hagan las otras webs del servidor afecta a la tuya. Otro miembro del grupo añadió que, incluso cambiando de IP, tuvo que esperar a que se limpiaran cachés de DNS.

Caso 2: la notificación tarda demasiado

Otro compañero tenía, de vez en cuando, errores de tiempo agotado en el retorno del TPV, aunque había subido el tiempo máximo de ejecución de PHP. Eso no sirve: según se comentó en el hilo, Redsys espera solo unos segundos y, si tu servidor no responde a tiempo, corta la conexión aunque tu tienda termine el trabajo después.

• Si usas Cloudflare u otro proxy, prueba a dejar fuera la URL de notificación del módulo. A un miembro del grupo se le acabaron los errores al quitar Cloudflare.
• Revisa qué módulos se ejecutan al validar el pedido. Gustavo aconseja ir a Diseño → Posiciones, buscar los hooks de validación (actionValidateOrder y parecidos) y desactivar de uno en uno los que no sean imprescindibles. Un módulo lento o con un error en ese punto interrumpe la creación del pedido. Por eso, explicaba Rekire, a veces el pedido queda guardado pero sin su historial de estados.
• Ante un caso de notificaciones de Redsys que acababan en error 500 por tiempo agotado, Gustavo apuntó a ps_eventbus, que le había dado problemas en varias tiendas con PrestaShop 8.

Caso 3: el cliente no terminó el pago

No todo es un fallo técnico. Un compañero preguntó al soporte de su banco por varias operaciones «sin finalizar» y la respuesta fue clara: el cliente no completó la autenticación en la app de su banco y no volvió a la pasarela. Ahí no hay cobro ni pedido que recuperar.

Y al revés: si cuando un cliente cancela en Redsys te aparece un pedido «Cancelado», Gustavo recordó que el módulo nuevo de Redsys tiene en su configuración una opción para devolver al cliente al checkout cuando el pago da error o se cancela (no recordaba su nombre exacto).

Con otras pasarelas: la lista blanca de IPs

A otro miembro del grupo le pasaba lo mismo con Paycomet: cobros sin pedido. El soporte de la pasarela le pidió añadir sus IPs a la lista blanca del servidor, para que el cortafuegos no bloquee sus notificaciones. Si tu hosting tiene un WAF o un sistema antibots, es lo primero que hay que mirar.

Cómo recuperar los pedidos que ya has cobrado

1. Entra en el portal de administración de Redsys y filtra las operaciones autorizadas del periodo.
2. Cada operación lleva el número de pedido que envió la tienda; con el módulo de Redsys suele corresponder al id del carrito.
3. Localiza esos carritos en el back-office y crea el pedido desde ese carrito con el método de pago correcto.
4. Comprueba el importe de cada uno antes de confirmarlo y apunta lo que conviertes. A un compañero, una venta masiva le tumbó el servidor y le dejó pedidos corruptos, y pasó horas cruzando autorizaciones a mano: mejor despacio.

Si los pagos sin pedido se repiten y no das con la causa, en Rekire lo revisamos dentro de un bono de horas de soporte.

Esto salió en @PrestashopEsp, la mayor comunidad PrestaShop de España en Telegram. Ver la conversación