Redsys cobra pero el pedido no entra en PrestaShop: 5 causas

El cliente paga, Redsys dice que todo ha ido bien y en PrestaShop no aparece el pedido. En el grupo salió una y otra vez entre 2023 y 2024, a veces en varias tiendas el mismo día. La respuesta corta: casi nunca falla el cobro, falla el aviso que Redsys manda a tu tienda para que cree el pedido.

Cómo llega el pedido a PrestaShop

Cuando el banco autoriza el pago, Redsys llama por detrás a una dirección de tu tienda, la URL de notificación. El módulo de pago comprueba la firma y crea el pedido. Si esa llamada no llega, llega cuando la tienda está atascada o la tienda responde con un error, el dinero está cobrado y el pedido no existe.

Gustavo, de la comunidad, lo resumía en enero de 2024, con varios clientes afectados a la vez: Redsys da un margen de unos pocos segundos para que la tienda conteste, y en esas semanas ni siquiera esperaba lo que dice esperar. Todo lo que haga lenta esa respuesta es candidato.

1. La tienda tarda demasiado en contestar

Es la causa más repetida. Un compañero encontró en el registro del servidor un (32)Broken pipe: mod_fcgid justo al volver del pago: el servidor cortó la conexión antes de que PHP terminara. Sospechó de unos límites de tiempo y de recursos de PHP demasiado bajos y los subió para ver si se repetía. Otro miembro contó, en enero de 2024, que con el módulo oficial de Redsys el pedido no se crea cuando Redsys da un timeout hacia la tienda, y que cada vez se lo encontraba más a menudo.

Si pasa a menudo, mide cuánto tarda tu tienda en validar un pedido: módulos enganchados a la validación, envío de correos por un SMTP lento o un servidor saturado suman segundos.

2. Un override desfasado rompe la validación

Otro caso: el pago se procesaba y el pedido no se generaba. En el registro aparecía esto:

PHP Warning: Declaration of Cart::updateQty(...) should be compatible with
CartCore::updateQty(..., $skipAvailabilityCheckOutOfStock = false, $wishlist = false)
in /override/classes/Cart.php

El override de Cart lo había copiado un módulo de una versión anterior de PrestaShop. Al actualizar, la función del núcleo ganó un parámetro y el override se quedó atrás. Abre el fichero del override: encima de cada función modificada se indica qué módulo la añadió. Actualiza ese módulo o corrige la firma de la función, y vacía la caché para que PrestaShop vuelva a leer las clases.

3. Un módulo enganchado al pedido falla

Un tercer compañero tenía pagos cobrados sin pedido y sin correos, y en el registro solo esto: Frontcontroller::init - Cart cannot be loaded or an order has already been placed using this cart. Gustavo le apuntó a un módulo que rompe el guardado o el cambio de estado del pedido. Revisa los módulos enganchados a la validación y a la confirmación del pedido y desactívalos de uno en uno en una copia de la tienda.

4. La notificación no llega: SSL, DNS o la URL

• Mira la pantalla de notificaciones en el portal de Redsys (canales Redsys). Ahí ves si el aviso llegó y qué respondió tu tienda: un 200 es correcto; un 500 es un error de tu tienda.
• Un miembro sospechaba de una URL de notificación en HTTP en lugar de HTTPS y de un error de SSL. En otro caso, un servidor antiguo con los certificados y librerías de SSL sin actualizar tardó tres días en diagnosticarse.
• Después de cambiar de servidor, los pedidos entraban unas veces sí y otras no: las DNS aún no se habían propagado en todas partes y parte de los avisos iban a la IP vieja.

5. Dos tiendas con el mismo terminal

Gustavo avisó en septiembre de 2023 de que, con el módulo nuevo de Redsys en dos tiendas o dominios distintos, la URL de confirmación que se usa parecía ser la de la configuración del terminal en Redsys, de modo que los avisos de una tienda podían acabar en la otra. Él mismo dijo que no podía confirmarlo al 100 %: era lo que parecía pasarle a una tienda. Si compartes terminal, comprueba a qué URL notifica cada tienda.

Qué hacer con los pagos que ya se han quedado sin pedido

• Compara cada día los cobros de Redsys con los pedidos de PrestaShop. Con volumen, hazlo con el identificador de la transacción, no a ojo.
• Crea el pedido a mano desde el back-office con los mismos productos y el pago ya recibido, y avisa al cliente.
• Vigila también lo contrario: un compañero tuvo pedidos duplicados con el mismo código de autorización. Si los envías los dos, envías dos veces la mercancía.

Si quieres enterarte de estos errores antes que tus clientes, el módulo Centinela de Rekire avisa por Telegram de los errores de la web, y Order Guard evita pedidos y estados de pago duplicados.

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