Pedidos que se pierden en el checkout de PrestaShop: cómo encontrar el error

El pedido que nunca existió

Hay una diferencia enorme entre un cliente que abandona el carrito y un cliente al que tu tienda no le dejó pagar. En la analítica se parecen: los dos son visitas que llegaron al checkout y no terminaron.

Solo que el primero decidió, y el segundo lo intentó.

Y ese segundo caso tiene una variante todavía peor: el cliente sí pagó, tiene el cargo en su tarjeta, y en tu back office no hay ningún pedido. Eso no se descubre mirando informes. Se descubre cuando esa persona escribe, y para entonces ya has perdido algo más que un pedido.

Esta guía va de encontrar esos fallos en PrestaShop 8 y 9 antes de que te los cuenten.

Los tres sitios donde se pierde un pedido

Conviene separarlos, porque cada uno se investiga en un sitio distinto:

Carrito sin pedido. Puede ser abandono normal o puede ser que el checkout no dejara avanzar. Aquí están los transportistas y las direcciones.

Pedido sin pago confirmado. El pedido existe, en estado de espera, y nunca cambia. Aquí están los tiempos de espera de la pasarela y las notificaciones que no llegan.

Pago sin pedido. El dinero se cobró, el pedido no se creó. Es el más grave y el más silencioso.

Lo primero: cobros que no tienen pedido

Este es el que hay que mirar antes que ningún otro, aunque sea el menos frecuente.

La causa habitual es que la notificación del proveedor de pago —la llamada que confirma que el cobro salió bien— no llegó o llegó y falló. Y cuando falla, muchas integraciones devuelven un error genérico al proveedor, que reintenta unas cuantas veces y se rinde.

Los motivos, por orden de frecuencia:

El punto de retorno no es accesible. Un cortafuegos que bloquea por país, un servicio anti-bots que exige JavaScript o una autenticación básica dejada puesta en producción. El proveedor recibe un error y tu tienda nunca se entera.

El pedido se valida con el carrito ya modificado. Si entre el pago y la confirmación el carrito cambió, validateOrder puede fallar por importe distinto.

Se agotó el stock durante el pago. Dos personas comprando la última unidad a la vez. Una paga, la otra paga y se queda sin pedido.

La comprobación es cruzar los cobros del proveedor con tus pedidos del día. Con hacerlo una vez a la semana ya sales del silencio; con hacerlo a diario, detectas el fallo el mismo día que empieza.

SameSite: el fallo que aparece solo

Este merece sección propia porque es el que más desconcierta: nadie ha tocado nada y de pronto los pagos dejan de completarse.

Cuando el cliente vuelve de la pasarela por POST desde otro dominio, el navegador aplica la política SameSite de las cookies. Con SameSite=Lax, la cookie de sesión de PrestaShop no viaja en esa petición. Resultado: el cliente vuelve, la tienda no lo reconoce, el carrito está vacío y el pedido no se crea.

Se manifiesta de forma irregular —depende del navegador y de la versión— y por eso se investiga fatal. Si tu pasarela hace retorno por POST:

; php.ini
session.cookie_samesite = "None"
session.cookie_secure = 1     ; obligatorio con None: sin HTTPS el navegador la descarta

Y comprueba que la cabecera sale de verdad, porque un proxy delante puede reescribirla:

curl -sI https://tutienda.es/ | grep -i "set-cookie"

Si tu integración no necesita retorno por POST, mejor no tocar esto: Lax es una protección real contra falsificación de peticiones. Se cambia cuando hace falta, no por si acaso.

El cliente que se queda sin transportista

Silencioso y bastante común. El cliente introduce una dirección correcta, llega al paso de envío y no hay ninguna opción. No aparece un mensaje de error: aparece un checkout que no avanza.

Las causas están repartidas por tres pantallas distintas de PrestaShop:

• Zonas de entrega sin cubrir. Baleares, Canarias, Ceuta y Melilla se quedan fuera por olvido con mucha frecuencia.
• Rangos de peso o de precio con hueco: un transportista cubre hasta 10 kg y el siguiente empieza en 10,01 kg, y un pedido de exactamente 10 kg no encaja en ninguno.
• Restricciones por grupo de cliente que nadie recuerda haber puesto.

La consulta que enseña el agujero antes de que lo encuentre un cliente:

-- Zonas activas sin ningún transportista asociado: cada fila es una
-- provincia entera que no puede comprar.
SELECT z.id_zone, z.name
FROM ps_zone z
LEFT JOIN ps_carrier_zone cz ON cz.id_zone = z.id_zone
LEFT JOIN ps_carrier c ON c.id_carrier = cz.id_carrier
                      AND c.active = 1 AND c.deleted = 0
WHERE z.active = 1
GROUP BY z.id_zone, z.name
HAVING COUNT(c.id_carrier) = 0;

Prueba además a mano un pedido a Canarias y otro a Baleares cada vez que toques transportistas. Cinco minutos.

Direcciones que el validador rechaza

PrestaShop valida el formato del código postal según el país y, en España, muchas tiendas activan el campo de documento de identidad como obligatorio.

Los dos fallos que producen abandonos y no dejan rastro:

Mensaje de error genérico. Si el cliente ve “dirección no válida” sin saber qué campo es, se va. El texto tiene que decir el campo concreto.

Validaciones más estrictas de la cuenta. Un apellido con guion, una dirección con caracteres que la expresión regular no contempla, un código postal correcto de un país que la tienda no tiene bien configurado. Cada regla de más es una puerta cerrada.

Revisa esto en Internacional → Ubicaciones geográficas país por país, y no dejes activos países a los que no vendas: es una fuente inagotable de formatos raros.

Cómo encontrarlo en los registros

PrestaShop tiene su propio registro en Parámetros avanzados → Registros, y los módulos de pago suelen escribir ahí. Ordena por severidad y agrupa por mensaje: cien errores idénticos son una causa, no cien.

Para lo que no aparezca ahí, los registros de PHP del servidor. Y si estás depurando una integración de pago, escribir en el registro de PrestaShop desde el módulo cuesta una línea:

PrestaShopLogger::addLog(
    'Pago devuelto sin referencia de carrito: ' . json_encode($datosRecibidos),
    3,                       // 3 = error
    null,
    'Cart',
    (int) $idCarrito,
    true
);

Lo que no hay que hacer es activar el modo depuración en producción para investigar. Enseña rutas, consultas y detalles internos a cualquiera que pase por ahí.

Lo que no funciona

Mirar solo la tasa de conversión. Baja igual por abandono que por fallo técnico, y no distingue.

Reinstalar el módulo de pago. Suele borrar la configuración y perder la pista de lo que estaba pasando.

Fiarse de las pruebas en modo de pruebas. El entorno de pruebas de las pasarelas no reproduce ni los tiempos de espera ni las notificaciones tardías, que es donde está la mitad de los fallos.

Esperar a que se queje alguien. De los clientes a los que les falla el checkout, la mayoría no escribe. Se van.

Culpar al navegador del cliente. A veces es verdad. Casi siempre es una cookie, un transportista o una validación.

Una comprobación diaria en cuatro consultas

No hace falta un sistema de monitorización para salir del silencio. Con esto puesto en un cron diario ya te enteras el mismo día:

-- 1. Pedidos que llevan más de una hora esperando el pago.
SELECT COUNT(*) FROM ps_orders
WHERE current_state = 3 AND date_add < NOW() - INTERVAL 1 HOUR;

-- 2. Pedidos en estado de error de pago en las últimas 24 horas.
SELECT COUNT(*) FROM ps_orders
WHERE current_state = 8 AND date_add > NOW() - INTERVAL 1 DAY;

-- 3. Carritos con producto, con dirección elegida y sin pedido:
--    llegaron al final y no pudieron terminar.
SELECT COUNT(*) FROM ps_cart c
LEFT JOIN ps_orders o ON o.id_cart = c.id_cart
WHERE o.id_order IS NULL
  AND c.id_address_delivery > 0
  AND c.date_upd > NOW() - INTERVAL 1 DAY;

-- 4. Productos vendidos por debajo de cero: señal de carrera en el stock.
SELECT id_product, quantity FROM ps_stock_available WHERE quantity < 0;

Los identificadores de estado varían entre instalaciones: comprueba los tuyos en Parámetros de pedidos → Estados. La consulta número tres es la que más avisa, porque un cliente que ya eligió dirección no estaba dudando.

Si te apañas con esto, no necesitas nada más

Las consultas están arriba y el cron son dos líneas. Si tu volumen es pequeño y miras los pedidos todos los días, es probable que detectes los fallos por tu cuenta antes de que importen.

Lo que cansa no es escribir las consultas: es acordarse de mirarlas cada mañana durante meses, y saber si el número de hoy es raro o normal sin tener con qué compararlo.