Cuando el pago deja de funcionar en una tienda PrestaShop, el riesgo no es solo técnico. El riesgo inmediato son los pedidos perdidos mientras se prueban varias pistas al mismo tiempo.
Lo más útil es avanzar en un orden corto: síntoma exacto, modo test o producción, claves API, notificaciones o webhooks, compatibilidad tras una actualización y luego logs. Al final de esta guía sabrá qué comprobar sin enturbiar el diagnóstico, qué hacer ya mismo para limitar las pérdidas y cuándo pasar a un diagnóstico de bug de pago PrestaShop.
Empiece por identificar el tipo de fallo
Antes de cualquier acción, separe la avería en familias de síntomas. Un método de pago ausente, un clic que falla y un pago aceptado sin pedido no responden a la misma lógica técnica. Si mezcla estos casos, corre el riesgo de corregir la capa equivocada.
Este paso también le ayuda a saber si se trata de un problema de visualización del método de pago, de un bloqueo en el túnel de compra o de un defecto en la respuesta entre el proveedor de pago y la tienda. Si su duda afecta al conjunto del túnel, mire también las averías del carrito y del túnel de pedido PrestaShop.
El método de pago ha desaparecido en la etapa de pedido
Aquí, el cliente ni siquiera alcanza la etapa de validación del pago. El síntoma es visual: el método no aparece, o solo aparece en ciertos recorridos. Anote de inmediato si la desaparición afecta a todos los clientes, a todos los transportistas, a todos los países o solo a un caso concreto.
En esta situación, no empiece por los webhooks. Verifique en prioridad lo que controla la visualización del método de pago: estado del módulo, cambio reciente de configuración y evolución del túnel en la tienda.
El botón es visible pero el pago falla al clic o en la redirección
Segundo caso: el método de pago está visible, pero el clic provoca un error, un bucle, una redirección fallida o un rechazo inmediato. Aquí, las causas a verificar en primer lugar son el modo test o producción y, después, las credenciales API.
No concluya demasiado pronto que el módulo está defectuoso. Un entorno erróneo o una clave incoherente puede producir exactamente este tipo de síntoma.
El pago es aceptado por el PSP pero el pedido no aparece en PrestaShop
Este es el caso más delicado. El cliente ha pagado, el proveedor de pago indica una operación aceptada, pero no se crea ningún pedido o el estado del pedido queda incoherente. Aquí hay que pensar en la respuesta técnica del PSP hacia PrestaShop, no solo en el clic de pago.
La respuesta correcta es dejar de lado momentáneamente la cuestión del front-office y controlar las notificaciones, webhooks y registros de eventos.
Compruebe primero el modo test o producción, y luego las claves API
Es la primera clasificación que debe hacer. Mientras no haya validado el entorno y las credenciales, es demasiado pronto para culpar a una actualización o a un bug más profundo. Esta comprobación lleva poco tiempo y evita muchos idas y venidas.
Detectar una mezcla entre test y producción
La trampa clásica es simple: un módulo configurado para producción con credenciales de test, o al revés. PayPal también indica que una mezcla entre sandbox y producción forma parte de las causas habituales de errores de autenticación o configuración. Stripe distingue claramente las claves de test y de producción en su documentación oficial Authentication | Stripe API Reference (consultado el 27/10/2026).
En Stripe, una clave secreta de test comienza por sk_test_, una clave live por sk_live_ y una clave restringida live por rk_live_. Si estos prefijos no corresponden al modo activado en el módulo, tiene una pista sólida.
Comprobar las claves y credenciales sin confundirlas
Compare lo que está registrado en el módulo con lo que se espera en el entorno correcto de la cuenta del PSP. El objetivo no es reemplazar valores al azar, sino verificar que cada credencial corresponde realmente al modo activo.
Trabaje con cuidado. Anote los ajustes presentes antes de cualquier modificación. Así mantiene la posibilidad de volver al último estado funcional conocido.
Verificar si un cambio reciente reescribió la configuración
Si la avería apareció justo después de una intervención, una actualización o una migración, parta de la hipótesis de que un ajuste pudo haberse modificado. Un módulo de pago puede permanecer activo y, aun así, haber perdido parte de su configuración.
Plantee una pregunta simple: ¿qué ha cambiado desde el último pago exitoso? Este paso evita lanzar un diagnóstico demasiado amplio.
Si el pago sale pero el pedido no llega, controle las notificaciones y webhooks
Cuando el cliente paga pero PrestaShop no crea el pedido, el problema no siempre está en el momento del clic. Puede residir en la información de retorno enviada por el proveedor de pago hacia la tienda. Este tipo de incidente debe tratarse de forma específica.
Lo que realmente rompe un webhook faltante
Un webhook que no llega, que responde mal o que apunta a una URL incorrecta puede impedir que la tienda reciba la información esperada tras el pago. En PayPal, la documentación especifica que hay que registrar una URL de webhook, asociarla a una suscripción de eventos, disponer de un Webhook ID, escuchar en HTTPS en el puerto 443 y responder con un HTTP 2xx. Si no cumple esto, PayPal reintentará el envío hasta 25 veces durante 3 días Integrate webhooks | PayPal Developer (actualizado el 18/06/2026).
Dicho de otro modo, un pago puede parecer completado en el PSP mientras que la tienda no ha recibido, o no ha validado correctamente, el evento que debía crear o actualizar el pedido.
Qué comprobar en el lado de PayPal
Compruebe primero la URL realmente declarada, luego la suscripción a los eventos esperados y después el identificador del webhook utilizado por el módulo. Si el módulo verifica la firma, debe apoyarse en el identificador de webhook correcto y en el cuerpo bruto de la petición.
No se limite a la mera existencia del webhook. Un webhook presente pero mal vinculado, o que no responde correctamente, suele producir el mismo resultado de negocio: pago recibido y pedido ausente o incompleto.
Por qué una simulación no basta
Una prueba de simulación puede dar una falsa tranquilidad. Puede ayudar a validar un listener, pero no demuestra que los eventos reales de producción lleguen efectivamente hasta el módulo en su cadena real.
Si tiene dudas, parta de una transacción reciente, busque el evento real en el lado del proveedor y compárelo con lo que la tienda ha registrado. Es la comprobación más fiable.
Compruebe después qué cambió justo antes de la avería
Una avería de pago que aparece sin causa evidente suele seguir a un cambio reciente: actualización de PrestaShop, actualización del módulo, reactivación de un ajuste antiguo o modificación del entorno. Por eso lo más rentable es revisar el historial inmediato.
Tras una actualización de PrestaShop, vuelva a comprobar el Module Manager
La documentación oficial de PrestaShop recomienda, tras una actualización, verificar el Module Manager, reactivar los módulos desactivados si es necesario y luego probar el front-office con un recorrido de pedido real Post-update checklist | PrestaShop Developer Documentation (consultado el 27/10/2026).
En una tienda en producción, compruebe si el módulo de pago ha sido desactivado, si otro módulo del túnel ha cambiado de estado y si el problema apareció justo tras esa intervención.
Relea la compatibilidad y los ajustes sensibles del módulo
Si la avería empezó tras una evolución de la tienda, compare la versión de PrestaShop con la compatibilidad anunciada por el módulo y relea los ajustes sensibles. Un módulo declarado compatible con una versión dada no debe considerarse automáticamente fiable tras cada actualización.
Si quiere detectar este tipo de riesgo antes de que corte su túnel, lea también las señales de un módulo PrestaShop mal codificado.
Pruebe todo el túnel, no solo el botón de pago
Un módulo puede parecer activo y, sin embargo, fallar únicamente en el recorrido real. Por eso una prueba completa del túnel sigue siendo útil tras una actualización: carrito, dirección, transportista, pago y retorno de confirmación.
Evite también la fórmula demasiado amplia tipo “la actualización ha roto los pagos”. La pregunta correcta es más precisa: ¿qué cambio ha hecho que este módulo, en este túnel, sea incompatible o esté mal configurado?
Lea los logs útiles antes de activar el debug por todas partes
Cuando las comprobaciones anteriores no han dado resultado, pase a los logs. Es el paso que permite volver a hechos: mensaje de error, momento exacto y componente afectado. PrestaShop dispone de una página Logs en el back-office para consultar errores y acciones de la tienda Logs | PrestaShop 8 documentation (consultado el 27/10/2026).
Dónde buscar primero
Empiece por anotar la hora de un fallo real y luego busque ese periodo en los logs de la tienda y en los registros del módulo si el proveedor los facilita. El objetivo no es leer todo el diario, sino correlacionar un intento preciso con un mensaje concreto.
Si la avería muestra un error de servidor más amplio, el método se parece al de un diagnóstico de error 500 en PrestaShop: aislar el instante, el componente y la modificación reciente.
Cuándo activar el modo debug
El modo debug puede ayudar, pero no es la palanca inicial. Actívelo solo si los logs no son suficientes y únicamente durante el tiempo del diagnóstico. La documentación de PrestaShop indica que tiene un impacto significativo en el rendimiento. Una vez obtenido el mensaje útil, desactívelo.
Esta regla es importante en producción: el debug debe servir para confirmar una hipótesis, no para sustituir un método de clasificación.
Qué correlacionar entre tienda, módulo y PSP
Un diagnóstico correcto no se basa en una sola fuente. Verifique conjuntamente la hora de la acción del cliente, el error eventual en la tienda, el estado reportado por el módulo y el evento visible en el PSP. Sin esta correlación, puede confundir un rechazo al clic con una ausencia de webhook.
En este punto, resista la tentación de desactivar varios módulos en producción “para ver”. Enturbiaría el diagnóstico y perdería la pista de la causa inicial.
Durante la avería, limite las pérdidas y decida rápido si escala
Durante el incidente el objetivo es doble: evitar agravar la avería y conservar un rastro explotable de los pagos pendientes.
- Desactive solo el método de pago afectado si produce errores repetidos. No toque varios módulos a la vez.
- Si otro método de pago sigue disponible, déjelo activo para reducir la pérdida inmediata.
- Muestre un mensaje corto y claro en el checkout para explicar que un incidente temporal afecta a un método de pago concreto.
- Supervise los pagos capturados sin pedido y prepare una lista simple: hora, importe, cliente, estado en el PSP y estado en PrestaShop.
- Concilie manualmente los casos pendientes mientras la cadena automática no esté fiable.
Si el triage en este orden no basta, es mejor pasar a una intervención dirigida. KLN-WEB ofrece soporte PrestaShop puntual o mensual, con diagnóstico gratuito, respuesta en 24 h y presupuesto en 24 h hábiles.
Preguntas frecuentes
¿Por qué el módulo de pago ha desaparecido en la etapa de pedido en PrestaShop?
Cuando el método de pago desaparece, trate primero el problema como un defecto de visualización o de disponibilidad en el túnel, no como un problema de webhook. Compruebe si la desaparición afecta a todos los clientes o solo a ciertos recorridos. Un método ausente no se diagnostica igual que un pago aceptado sin pedido; esta distinción evita buscar en el lugar equivocado.
¿Cómo saber si mi módulo quedó en modo test en lugar de producción?
Compare el modo activado en el módulo con el entorno utilizado en su cuenta del PSP. En Stripe, las claves secretas de test empiezan por sk_test_ y las claves live por sk_live_. Si el módulo está en producción con claves de test, o al revés, el pago puede fallar de inmediato aunque la configuración parezca correcta.
¿Dónde comprobar las claves API de Stripe o PayPal cuando el pago no pasa?
La comprobación se hace en dos sitios: la configuración del módulo de pago en PrestaShop y el entorno correcto de la cuenta Stripe o PayPal. Lo crucial es la coherencia entre el modo activo y las credenciales registradas. Antes de modificar nada, anote los ajustes actuales para poder volver al último estado conocido.
¿Por qué el pago se acepta en la banca o PSP pero el pedido no aparece en PrestaShop?
Este caso suele indicar un problema de retorno técnico entre el proveedor de pago y la tienda. Hay que controlar las notificaciones o webhooks, la URL declarada, la suscripción a los eventos esperados y la manera en que el módulo procesa ese retorno. Un pago validado en el PSP no garantiza por sí solo que PrestaShop haya recibido el evento necesario para crear el pedido.
¿Qué hay que comprobar justo después de una actualización de PrestaShop o del módulo de pago?
Tras una actualización, verifique primero el estado del módulo en el Module Manager y su compatibilidad anunciada con la versión de la tienda. Luego pruebe un recorrido de pedido real en el front-office. Lo esencial es no concluir demasiado pronto que la actualización “ha roto” el pago sin haber identificado el ajuste o la incompatibilidad responsable.
¿Dónde encontrar los logs útiles en PrestaShop para diagnosticar un fallo de pago?
PrestaShop ofrece una página Logs en el back-office. Úselos con un método simple: anote la hora exacta de un fallo y busque las entradas correspondientes en los logs de la tienda, del módulo y del proveedor si tiene acceso. Si activa el modo debug, hágalo solo durante el diagnóstico y desactívelo en cuanto obtenga la información necesaria.