Pagos con tarjeta desviados a Stripe desde el módulo de Redsys

En octubre de 2026 Rekire contó en el grupo el caso de un cliente al que acababa de migrar a PrestaShop 9: desde mayo, alguien se había llevado unos 2.800 euros sin hacer ningún ruido. Tenía la contraseña del hosting y la usaba para meter una página de pago falsa dentro del módulo de Redsys. Respuesta corta: cuadra cada pedido pagado con tarjeta con el portal de Redsys; un pedido «pagado» que no aparece allí es dinero que no tienes.

Cómo funcionaba

• Entraba por FTP con la contraseña de la cuenta del hosting (cPanel/FTP).
• Instalaba su código dentro del módulo de Redsys, esperaba a que un cliente pagase con tarjeta y después se borraba solo.
• El cliente veía una pantalla de pago normal, pero el dinero iba a una cuenta de Stripe del estafador.
• En el back-office el pedido aparecía como «Pago con tarjeta Redsys», igual que uno real.
• Estaba preparado para no actuar con los correos de prueba ni con los empleados de la tienda.

Los registros que guardaba el servidor solo llegaban a finales de agosto, y ya había cobros desviados desde el 31 de ese mes. Siempre entraba desde la misma IP.

Por qué se descubrió

Por casualidad. Tras la migración a PrestaShop 9, su código, hecho para la tienda antigua, dejó de funcionar. Al intentar instalarlo otra vez, dejó la web en blanco, y al investigar el error salió todo.

Las comprobaciones que lo habrían destapado

1. Cuadrar pedidos con el portal de Redsys. Cada pedido con tarjeta debe tener su operación en el portal del TPV con el mismo importe. Gustavo lo resumía así: hay tiendas que no revisan los pagos «porque tienen muchos pedidos», y es justo donde esto pasa desapercibido.
2. Recibir el aviso de cada pago. Gustavo aconseja pedir que el banco o el TPV envíe por correo la notificación de cada cobro. Si te llega un pedido y no te llega el aviso del banco, algo va mal.
3. Una compra real de vez en cuando, pequeña, desde un equipo, una conexión y un correo que la tienda no conozca. El código se escondía de los empleados y de los correos de prueba: hay que probar como un cliente cualquiera.
4. Mirar los ficheros del módulo de pago. Un cambio en la carpeta del módulo de Redsys que no venga de una actualización tuya es una alarma.

Cerrar la puerta del hosting

La entrada no fue un fallo de PrestaShop: fue la contraseña del hosting. Lo mínimo:

• Cambia las contraseñas de cPanel, FTP y base de datos, y que no sean las mismas.
• Usa SFTP en lugar de FTP y, si el panel lo permite, limita el acceso por IP o desactiva las cuentas FTP que no se usan.
• Pide al hosting que conserve los registros de acceso más tiempo. Aquí solo llegaban a finales de agosto, y el problema venía de mayo.
• Revisa los equipos desde los que se administra la tienda: una contraseña de hosting puede salir de un programa que roba lo guardado en el navegador.

Lo que hizo Rekire después

A raíz de este caso, Rekire completó su módulo Order Guard, que ya evitaba los pedidos duplicados con un solo pago, para que revise el número de operación de cada pedido (en Redsys, por su firma) y vigile los ficheros de los módulos de pago. No consulta a la pasarela por ti: un pedido sospechoso se confirma buscando la operación en su panel. Si quieres que revisemos los cobros de tu tienda o los accesos al hosting, escríbenos por el contacto.

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