Cloudflare y los bloqueos de LaLiga: pagos de Redsys sin pedido

«Entra el pago en Redsys pero no en la web; le dices que reintente y no lo consigue.» Así lo describió un compañero en abril de 2025, y no fue el único. Cuando Redsys cobra y la tienda no crea el pedido, casi siempre es que la notificación de Redsys no llega a la tienda. Ese año la causa estrella fue Cloudflare.

Por qué depende de la notificación

Al terminar el pago, Redsys avisa a la tienda con una llamada de servidor a servidor a la URL de notificación del módulo. Con esa llamada el módulo valida la firma y crea el pedido, o le cambia el estado si lo creó antes. Si la llamada no llega, el banco ha cobrado y PrestaShop no sabe nada. Que el cliente vuelva a la tienda no basta.

Cloudflare y los bloqueos de LaLiga

Durante 2025, los bloqueos contra IP de Cloudflare en España en días de partido dejaron sin servicio a webs legítimas que estaban detrás de esa red. Algunas tiendas con el proxy de Cloudflare activado dejaron de recibir las notificaciones de Redsys justo en esas franjas.

Lo que se hizo en el grupo:

• Quitar el proxy de Cloudflare al dominio de la tienda. Un cliente prefirió renunciar a Cloudflare antes que seguir perdiendo pedidos.
• Comprobar si de verdad pasa por Cloudflare. Si el registro A del dominio está en «solo DNS» (nube gris), el tráfico no pasa por su red, como confirmó un compañero.
• Antes de quitar Cloudflare del todo, apuntar los registros DNS que tienes allí. Si cambias los servidores de nombres, tienes que llevártelos todos, correo incluido. Era la duda de quien tenía que hacerlo: «veo que tienen puestos muchos registros».

La URL de notificación con http

Otro caso de mayo: pagos hechos, pedidos sin crear y errores en el log de Redsys. La sugerencia fue revisar en el panel de Redsys la URL del comercio y pedir que esté con https. Con http la notificación depende de una redirección a https, y en esa redirección se puede perder. Esa URL no la cambias tú: la cambia Redsys o tu banco si se lo pides.

Gustavo matizó que normalmente el propio módulo envía su URL en cada operación y que casi nunca hace falta tocar el panel. Si tienes URL escritas a mano de una configuración antigua, revísalas igualmente.

El importe que llega sin descuento

En junio, a los clientes de un grupo con un 5 % de descuento no se les aplicaba al pagar con tarjeta. En el log del módulo se veía que DS_MERCHANT_AMOUNT llegaba con el importe completo. Gustavo dio con la causa: el checkout de una página no refrescaba los bloques de pago al aplicar el descuento y la versión del módulo de Redsys era antigua. Su método para comprobarlo:

1. Abre una ventana de incógnito, entra con un cliente del grupo y añade productos.
2. En el checkout, inspecciona el formulario de pago de Redsys: el importe va codificado en base64 en el campo Ds_MerchantParameters. Descodifícalo y mira el total que se va a enviar; repite después de aplicar el descuento.
3. Si no coincide con el total del carrito, actualiza el módulo de pago y revisa el del checkout.

Pedidos creados antes del pago

Hay módulos de Redsys que crean el pedido antes del pago con un estado de «pendiente» y lo actualizan según el resultado, o que detectan pagos correctos sin pedido y los recuperan. A la pregunta obvia, qué pasa si al final no se paga, la respuesta en el grupo fue que el pedido se queda en pendiente o en error de pago. Así es más difícil que un cobro se quede sin pedido, a cambio de revisar los pendientes de vez en cuando.

Si te pasa hoy

• Busca la operación en el panel de Redsys y compara la hora con los registros de PrestaShop y del servidor.
• Mira si la tienda está detrás de un proxy o un firewall que pueda estar bloqueando las llamadas de Redsys.
• Comprueba que la URL de notificación responde por https sin redirecciones.
• Actualiza el módulo de pago antes de buscar fallos más raros.

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