Replay de los 5 recorridos tipo
Carrito simple, carrito con combinaciones, carrito con código promo, carrito B2C / B2B, carrito envío internacional. Cada recorrido se replay con el inspector de red Chrome abierto.
💸 Cada día que pasa = ingresos perdidos
¿Tu embudo PrestaShop
¿Tu embudo PrestaShop
pierde pedidos?
lo auditamos y lo reparamos.
Auditoría y corrección del embudo de compra PrestaShop
Carrito que se vacía, paso en bucle, botón de pago que no reacciona, webhook Stripe no recibido, pedido pagado pero nunca registrado: hacemos replay de tu recorrido, identificamos la fuga, corregimos en 24 h. Última auditoría: +48 carritos recuperados/mes.
✓ Pre-auditoría gratuita 30 min
✓ Presupuesto en 24 h laborables
✓ Desde 60 €/h sin IVA
✓ Cálculo de los ingresos recuperados
💸 Cuánto te cuesta realmente
Un bug checkout son ingresos que se fugan, en silencio
Haz el cálculo. El coste de la inacción es casi siempre superior al coste de la intervención.
~50
carritos abandonados / mes
causas puramente técnicas (media auditorías 2025-2026)
causas puramente técnicas (media auditorías 2025-2026)
× 60 €
carrito medio
tienda B2C estándar
tienda B2C estándar
3 000 €
ingresos / mes recuperables
tras corrección del bug
tras corrección del bug
💡 Intervención tipo 2-4 h bajo presupuesto (desde 60 €/h sin IVA) · ROI desde el primer mes tras el fix.
🔎 Los bugs típicos
Los 8 bugs checkout más frecuentes
Identificados en 30 auditorías checkout PrestaShop 2025-2026. Reconoce el tuyo.
1. Carrito que se vacía entre paso dirección y pago
Causa típica: cookies SameSite incompatibles desde Chrome 80. El cliente es redirigido a Stripe / Redsys / PayPal, vuelve a tu sitio, la sesión es nula. Fix: forzar SameSite=None; Secure en la cookie de sesión, verificar que todo está en HTTPS, probar en 3 navegadores.
2. Paso «Envío» en bucle
Causa típica: ningún transportista disponible para el peso/zona del carrito. El botón «Siguiente» no valida el paso porque el array de transportistas está vacío. Fix: auditoría completa de los transportistas (zonas, pesos, dimensiones), creación de un transportista fallback «por defecto» para evitar el caso cero.
3. Pedido pagado pero no creado (webhook Stripe / Redsys / PayPal)
Causa típica: endpoint webhook bloqueado o en error. El cliente paga en Stripe o Redsys, el PSP envía un POST de confirmación a tu tienda, tu WAF o Cloudflare bloquea la petición (o el endpoint PHP cae). Fix: verificación logs Stripe/Redsys dashboard, whitelist de las IP del PSP en el WAF, debug del handler PHP.
4. Total carrito que se vuelve negativo
Causa típica: módulo de promoción o código promo que aplica mal un descuento sobre productos ya rebajados, cálculo IVA mal redondeado, o acumulación de descuentos no gestionada. PrestaShop rechaza entonces el pedido silenciosamente. Fix: auditoría del módulo promo, añadir una validación en Cart::getOrderTotal().
5.
max_input_vars demasiado bajo
Causa típica: límites PHP alcanzados en un carrito con muchas combinaciones. max_input_vars por defecto = 1000, lo que es insuficiente para un carrito de 8 artículos × varias combinaciones. La petición POST se trunca, el carrito se corrompe. Fix: php_value max_input_vars 4000 en .htaccess o pool PHP-FPM.
6. Módulo de pago que hace timeout
Causa típica: llamada API del módulo de pago (Stripe, Redsys, Bizum, PayPal, Klarna, Adyen) que supera max_execution_time PHP, o DNS que resuelve lentamente hacia la API del PSP. El cliente ve un spinner infinito y luego un error. Fix: aumentar timeout, optimización llamada API (caché del token PSP), monitoring del tiempo de respuesta.
7. JavaScript bloqueado por otro módulo
Causa típica: módulo de tracking que inyecta un JS con un error de sintaxis, lo que impide la ejecución del JS del checkout. El formulario no se envía. Fix: inspección consola Chrome (F12 → Console), desactivación del módulo defectuoso, reporte al editor.
8. Stock negativo → pedido rechazado silenciosamente
Causa típica: varios clientes piden el mismo producto a la vez, el stock pasa a -1 entre la validación del carrito y el registro del pedido, PrestaShop rechaza silenciosamente. Fix: activación del modo «permitir pedidos sin stock», o lock SQL sobre el stock durante la transacción.
🩺 Método de auditoría
Cómo auditamos tu checkout
3 a 4 horas de diagnóstico estructural. Sin conjeturas, sin checklist genérica.
Auditoría de los módulos que tocan el checkout
Módulos de pago, transportistas, cálculo de gastos, promoción, fidelidad, impuestos. Para cada uno: versión, última actualización, hooks enganchados, JS inyectado, superficie de error potencial.
Lectura de los logs de servidor
Logs Apache, PHP-FPM, PrestaShop (
/var/logs/), webhooks PSP. Identificación de los errores silenciosos y de las peticiones fallidas.
Análisis Analytics + carritos abandonados
Embudo de conversión GA4 por paso, identificación del paso de fuga. Si está disponible el export de carritos abandonados: cruce con los logs de servidor para identificar el momento exacto del abandono.
Tests multi-navegador y multi-dispositivo
Chrome desktop, Safari iOS, Chrome Android, Firefox. Cada combinación expone bugs específicos (cookies SameSite Safari, Apple Pay iOS, navegador in-app de WhatsApp, etc.).
Informe + cálculo de los ingresos recuperables
Lista de los bugs encontrados, severidad, fix propuesto, tiempo estimado, ingresos mensuales recuperables. Tú decides qué corregimos.
💰 Tarifas
Tarifas anunciadas de antemano
Pre-auditoría gratuita. Para la intervención, sabes exactamente cuánto cuesta antes de que toque el código.
🔍 Pre-auditoría
Pre-auditoría
encontrar la fuga del embudo
0€gratis
30 min · sin compromiso
- Replay de un recorrido de compra tipo
- 2 bugs más probables identificados
- Presupuesto cifrado + ingresos recuperables estimados
- Tú decides si continúas
⚡ El más demandado
🔧 Intervención
Intervención dirigida
reparar el embudo de compra
desde 60€sin IVA
según diagnóstico · precio anunciado de antemano
- Backup ficheros + BBDD antes de la intervención
- Corrección del bug (cookies, hook, webhook, transportista...)
- Tests en 5 carritos tipo + multi-navegador
- Informe escrito causa + ingresos recuperables
- Garantía 30 días sobre el fix
🛡️ Mantenimiento
Mantenimiento Performance
test del embudo cada mes
desde 50€/ mes
vigilancia 24/7 · sin compromiso
- Replay automatizado del recorrido de compra mensual
- Backups auto diarios externalizados
- Seguimiento carritos abandonados + alerta si pico anormal
- Intervención prioritaria si bug checkout
❓ FAQ
Bug checkout PrestaShop — preguntas frecuentes
Cinco causas: (1) cookies SameSite incompatibles desde Chrome 80, (2) módulo de promoción que modifica el carrito en
actionCartSave, (3) token de carrito regenerado por un override mal escrito, (4) max_input_vars PHP alcanzado, (5) sesión PHP que expira (gc_maxlifetime demasiado bajo). El diagnóstico real requiere un replay con inspector de red + logs de servidor.Tres indicadores a cruzar: (1) tasa de conversión checkout en GA4, el paso con caída anormal revela el bug, (2) logs de servidor: los POST
/order-opc en 500 o redirect inesperado, (3) emails de carrito abandonado. Último caso cliente: 48 carritos/mes × 60 € = 2 880 €/mes perdidos, mucho más que el coste de la intervención.Pre-auditoría gratis (30 min) y después intervención bajo presupuesto, desde 60 €/h sin IVA. La mayoría de los bugs checkout estándar (cookies, sesión, hook defectuoso, transportista, webhook) se resuelven en 2 a 4 h una vez identificada la causa. El presupuesto se envía en 24 h laborables antes de cualquier inicio: sabes lo que pagas antes de que toquemos el sitio. Para casos complejos (rehacer el embudo, refactorización módulo de pago), el encuadre es más largo y el importe se precisa tras la auditoría.
Bug webhook clásico. Stripe/Redsys/PayPal/Bizum envían un POST a tu sitio tras el pago. Si la petición falla (firewall WAF, SSL inválido, endpoint en 500/timeout), tu sitio no registra el pedido aunque el cliente haya pagado. Fix: (1) verificar los logs webhooks dashboard PSP, (2) probar el endpoint con curl, (3) corregir el error PHP o whitelist IP. Bug silencioso pero costoso.
Cuatro causas por frecuencia: (1) ningún transportista disponible para la zona/peso, (2) módulo de cálculo de gastos de envío que falla silenciosamente, (3) JavaScript bloqueado por otro módulo, (4) validación servidor que rechaza sin retorno explícito. Diagnóstico siempre en replay con Network Chrome abierto.
Sí, acceso FTP o SSH basta. Diagnosticamos la mayoría de los bugs leyendo los logs Apache +
/var/logs/ + inspección del código módulos pago/transportistas. Para los fix que exigen una intervención BO (activación módulo, config transportista), recuperamos una cuenta admin en SQL si es necesario.¿Estás perdiendo pedidos ahora mismo?
Pre-auditoría gratuita 30 min: hacemos replay de tu recorrido, te decimos qué falla. Presupuesto en 24 h laborables, intervención desde 60 €/h sin IVA.