¿Cómo solucionar problemas de compatibilidad con pasarelas de pago en PrestaShop?

El problema no siempre está donde duele

Cuando una pasarela de pago falla en PrestaShop, la tentación inmediata es culpar al módulo. Es humano. También es cómodo. Pero en comercio electrónico, como en ciertas novelas policiales, el culpable rara vez aparece con una etiqueta en la solapa. El error puede nacer en una versión de PHP incompatible, en una llamada AJAX bloqueada, en una regla de firewall demasiado entusiasta, en una moneda no permitida por el banco o en una actualización de PrestaShop que dejó a un módulo antiguo mirando al futuro como quien mira llover desde una estación abandonada.

PrestaShop funciona como un ecosistema. Núcleo, módulos, tema, servidor, métodos de transporte, reglas de impuestos, caché, idioma, moneda, proveedor de pago y navegador del cliente participan en una danza delicada. La pasarela de pago no es una isla; es un puente. Y si un puente tiembla, no siempre se arregla pintando la barandilla.

La paradoja es conocida: cuanto más “simple” parece un botón de pago, más capas técnicas tiene debajo. Un clic puede activar validaciones de carrito, sesiones, tokens, redirecciones, APIs REST, callbacks, webhooks, estados de pedido, reglas antifraude y autenticación reforzada del cliente. Minimalismo en la pantalla, complejidad en las entrañas. La modernidad nos prometió comprar en dos clics; discretamente olvidó mencionar los veinte sistemas negociando en la sombra.

Idea clave: solucionar problemas de compatibilidad con pasarelas de pago en PrestaShop exige separar síntomas de causas. Un “pago rechazado” puede ser un rechazo bancario real, pero también un fallo de comunicación entre la pasarela y la tienda, un problema de SSL, un error de configuración del módulo o una incompatibilidad del checkout.

Síntomas habituales: cuando la tienda habla en susurros ⚠️

Antes de tocar configuraciones, conviene escuchar. PrestaShop suele dejar pistas; algunas son claras, otras parecen escritas por un oráculo con prisa. Estos son los síntomas más frecuentes cuando hay problemas de compatibilidad con métodos de pago en PrestaShop:

El método de pago no aparece

El cliente llega al checkout y la pasarela no se muestra. Puede deberse a restricciones por país, moneda, grupo de clientes, transportista, importe mínimo/máximo, modo sandbox, permisos del módulo o errores JavaScript.

Redirección rota o pantalla en blanco

Al hacer clic en pagar, aparece una página en blanco, un error 500, una URL incorrecta o un bucle de redirección. Suele apuntar a incompatibilidad de módulo, override conflictivo, caché, versión de PHP o error en plantilla.

Pedido creado pero sin pago confirmado

El cliente paga, pero PrestaShop deja el pedido como “pendiente”, “error de pago” o ni siquiera lo crea correctamente. Aquí suelen intervenir webhooks, IPN, URLs de retorno, estados de pedido y validación de firma.

Pagos rechazados sin motivo evidente

Puede ser una tarjeta realmente rechazada, pero también un problema con 3D Secure, SCA, credenciales API, modo de pruebas, límites antifraude, moneda no aceptada o configuración del comercio en el proveedor.

Una anécdota mínima: una vez vi una tienda que llevaba tres días culpando a Stripe por pagos fallidos. Al final, el problema era un módulo de optimización que retrasaba JavaScript “para mejorar la velocidad”. La tienda iba más rápida, sí; tan rápida que el formulario de pago no alcanzaba a cargar. La optimización, ese arte noble que a veces se comporta como un camarero que retira el plato antes de servir la comida.

Versiones de PrestaShop, PHP y módulos: el triángulo donde se pierden muchas tardes 🔧

La compatibilidad técnica empieza por una pregunta aburrida, por tanto imprescindible: ¿qué versiones exactas estás usando? No basta con decir “PrestaShop 1.7” o “el módulo está actualizado”. En soporte técnico, la vaguedad es niebla; los números son faros.

PrestaShop ha tenido grandes familias de versiones, como 1.6, 1.7 y 8.x. Cada una tiene requisitos distintos de PHP, dependencias y arquitectura. Además, los módulos de pago suelen apoyarse en librerías externas del proveedor: SDKs de PayPal, Stripe, Redsys, Mercado Pago, Adyen, Paycomet, Klarna, entre otros. Si una de esas piezas envejece mal, el checkout se convierte en un museo de incompatibilidades.

Atención: no actualices PrestaShop, PHP y el módulo de pago a la vez en producción “para ahorrar tiempo”. Es una de esas economías brillantes que luego se pagan con una noche larga, café malo y clientes preguntando por qué no pueden pagar. Hazlo en entorno de pruebas, con copia de seguridad y cambios controlados.

Compatibilidad con PHP: el detalle que parece técnico hasta que cuesta dinero

Los problemas de PHP son especialmente traicioneros. Una tienda puede funcionar en apariencia —catálogo, carrito, login— y fallar justo en el pago porque el módulo usa una función incompatible, una dependencia no actualizada o una librería que ya no se comporta igual.

Como regla práctica:

• Consulta siempre la matriz oficial de compatibilidad de tu versión de PrestaShop antes de cambiar PHP.
• Verifica que el módulo de pago declare compatibilidad con tu versión de PrestaShop y PHP.
• No asumas que “más nuevo” significa “mejor” para una tienda antigua. La novedad sin compatibilidad es solo una forma elegante de incendio.
• Si tu tienda está en PrestaShop 1.7 antiguo, evalúa una actualización planificada: muchos proveedores priorizan soporte para versiones mantenidas.

Método de diagnóstico paso a paso: del caos al mapa 🧭

Resolver un fallo de pago no consiste en probar cosas al azar hasta que una funcione. Eso no es mantenimiento; es espiritismo con credenciales FTP. Un buen diagnóstico sigue un orden, reduce variables y documenta hallazgos.

1. Reproduce el error con precisión

Necesitas saber exactamente qué ocurre:

• ¿El método de pago no aparece o aparece y falla?
• ¿Falla con todos los productos o solo con algunos?
• ¿Ocurre en móvil, escritorio o ambos?
• ¿Afecta a todos los clientes o solo a invitados?
• ¿Sucede con una moneda, país o transportista concreto?
• ¿El pago falla antes o después de redirigir al proveedor?
• ¿El proveedor registra el intento de pago?

Haz una compra de prueba con un producto económico o en modo sandbox. Captura pantalla, URL, hora exacta, navegador y usuario. La hora es importante: permite cruzar el evento con logs del servidor, logs de PrestaShop y panel de la pasarela.

2. Activa el modo depuración con cuidado

En PrestaShop puedes activar el modo debug desde Parámetros avanzados > Rendimiento en muchas instalaciones, o mediante configuración técnica según versión. También puedes revisar logs en:

• var/logs/ en versiones modernas.
• app/logs/ en algunas instalaciones de PrestaShop 1.7.
• Logs del servidor: Apache, Nginx, PHP-FPM, LiteSpeed.
• Logs internos del módulo de pago, si los ofrece.
• Panel del proveedor: eventos, webhooks, intentos de pago, respuestas de API.

No dejes el modo debug activado en producción más tiempo del estrictamente necesario. Puede exponer rutas internas, mensajes sensibles o detalles de configuración. En una tienda online, la transparencia excesiva no es virtud: es una ventana abierta en planta baja.

3. Diferencia error de cliente, error de tienda y error de proveedor

4. Desactiva interferencias, no funcionalidades esenciales

En un entorno de staging, desactiva temporalmente módulos que puedan tocar el checkout:

• Módulos de “one page checkout”.
• Optimizadores de JavaScript y CSS.
• Módulos de caché avanzada.
• Herramientas de consentimiento de cookies que bloqueen scripts.
• Extensiones antifraude de terceros.
• Personalizaciones del tema sobre la página de pedido.

Si el pago funciona con el tema clásico y falla con el tema personalizado, el diagnóstico acaba de ponerse interesante. No necesariamente agradable, pero sí honesto.

SSL, TLS, cURL y servidor: la fontanería invisible del pago 🔐

Una pasarela de pago moderna exige comunicación segura. Si el certificado SSL está mal instalado, si TLS es obsoleto, si cURL no puede conectarse o si el firewall bloquea una notificación, el sistema falla con la discreción de una tubería rota detrás de la pared: no se ve, pero todo se humedece.

Certificado SSL correctamente instalado

PrestaShop debe funcionar íntegramente bajo HTTPS, no solo en el checkout. Revisa:

• Certificado válido y no caducado.
• Cadena intermedia correctamente instalada.
• Redirección consistente de HTTP a HTTPS.
• Dominio canónico coherente: con o sin www, pero no ambos peleándose.
• Sin contenido mixto: scripts, imágenes o CSS cargados por HTTP.

En Back Office, revisa la configuración SSL de PrestaShop y confirma que el dominio de la tienda coincide con el dominio usado en la pasarela. Un pequeño desajuste puede bastar para que el proveedor rechace callbacks o redirecciones.

TLS y cURL

La mayoría de proveedores de pago requieren TLS moderno, habitualmente TLS 1.2 o superior. Si tu servidor todavía depende de protocolos antiguos, el problema no es que la pasarela sea exigente; es que tu servidor está intentando entrar a una reunión de 2025 vestido para 2009.

Verifica que el hosting tenga:

• Extensión cURL activa.
• OpenSSL actualizado.
• Soporte para TLS 1.2 o superior.
• Permisos de salida hacia endpoints del proveedor.
• Resolución DNS correcta.
• Sin bloqueo por WAF, mod_security, reglas anti-bot o firewall externo.

Errores típicos relacionados con servidor

Webhooks, IPN y URLs de retorno: los mensajeros que nadie ve 📬

Muchos comerciantes creen que el pago termina cuando el cliente vuelve a la tienda. No exactamente. En pasarelas modernas, la confirmación fiable suele llegar mediante una notificación servidor a servidor: webhook, IPN, callback o notificación asíncrona. Es el cartero invisible que dice: “sí, este pago existe”.

Si ese mensajero no llega, llega tarde o llama a la puerta equivocada, PrestaShop puede no cambiar el estado del pedido aunque el cliente haya pagado. Y ahí empieza el pequeño teatro del absurdo: el banco dice “cobrado”, PrestaShop dice “pendiente” y el cliente dice, con toda razón, “¿me van a enviar mi pedido o tengo que ofrecer un sacrificio?”

Qué revisar en las notificaciones

• URL de webhook correcta: debe coincidir con la URL generada por el módulo y estar accesible públicamente.
• HTTPS válido: muchos proveedores rechazan callbacks hacia HTTP o certificados inválidos.
• Modo correcto: sandbox y producción suelen tener endpoints, claves y webhooks separados.
• Firma o secreto: si la firma del webhook no coincide, el módulo rechazará la notificación.
• Respuesta HTTP: el endpoint debería devolver un código 200 o el esperado por el proveedor.
• Firewall: evita bloquear peticiones legítimas de la pasarela.
• Multi-tienda: confirma que la notificación llega a la tienda correcta.

Pedidos duplicados o estados incorrectos

Un webhook reenviado varias veces no debería crear pedidos duplicados si el módulo está bien diseñado. Aun así, pueden aparecer problemas cuando hay personalizaciones del flujo de pedido, overrides o módulos que modifican estados. Revisa la configuración de estados de pedido:

• Pago aceptado.
• Pago pendiente.
• Error de pago.
• Cancelado.
• Reembolsado.
• Autorizado pendiente de captura, si tu pasarela trabaja con autorización/captura.

En pasarelas como Stripe, PayPal o Adyen, el panel del proveedor suele mostrar eventos con gran detalle. Úsalo. Es una bitácora más fiable que muchas intuiciones.

Tema, checkout y JavaScript: la belleza también rompe cosas 🎭

El checkout de PrestaShop depende de hooks, plantillas, scripts y comportamientos dinámicos. Un tema demasiado intervenido puede convertir el pago en una delicada vajilla en una mudanza. Por fuera luce impecable; por dentro, cada pieza cruje.

Los módulos de pago suelen insertarse mediante hooks como los relacionados con opciones de pago, validación de pedido, cabecera, scripts o display de contenido. Si un tema elimina, altera o reordena esos hooks sin respetar el flujo esperado, el módulo puede no renderizar su formulario, no cargar scripts o no enviar tokens correctamente.

Conflictos frecuentes en el checkout

• One page checkout de terceros: algunos no son compatibles con todos los métodos de pago, especialmente los que requieren formularios embebidos o redirecciones complejas.
• Minificación agresiva: combinar o diferir JavaScript puede romper SDKs de Stripe, PayPal Smart Buttons, Apple Pay, Google Pay o validaciones 3D Secure.
• Errores JavaScript previos: un error en un módulo de cookies o analytics puede detener la ejecución del script de pago.
• Plantillas sobrescritas: overrides del tema pueden estar basados en una versión antigua de PrestaShop.
• Campos obligatorios personalizados: si el checkout exige datos no estándar, puede bloquear la creación de pedido.

Cómo probar si el tema es el culpable

1. Crea una copia de la tienda en staging.
2. Activa temporalmente el tema clásico compatible con tu versión de PrestaShop.
3. Desactiva módulos de optimización frontend.
4. Prueba el mismo carrito, país, moneda y transportista.
5. Revisa la consola del navegador y la pestaña Network.

Si el método de pago funciona en el tema clásico, no celebres demasiado pronto. Has encontrado la zona del incendio, no necesariamente la cerilla. Revisa hooks, plantillas del checkout, scripts diferidos, overrides y compatibilidad del módulo de checkout.

Un checkout bonito que impide pagar es como una caja registradora tallada en mármol sin cajón para el dinero: admirable, inútil y ligeramente ofensiva.

Monedas, países, impuestos y transportistas: la compatibilidad comercial también existe 🌍

No todos los problemas de pasarela son técnicos. Algunos nacen de la configuración comercial. PrestaShop permite restringir métodos de pago por moneda, país, grupo de clientes y transportista. Los módulos, a su vez, pueden imponer sus propias limitaciones. Y los proveedores de pago, por supuesto, tienen reglas: países permitidos, monedas aceptadas, importe mínimo, tipo de cuenta, métodos locales habilitados.

Cuando el método de pago no aparece

Revisa en el Back Office:

• Pago > Preferencias: restricciones por moneda, país, grupo y transportista.
• Internacional > Localización: monedas activas, países, zonas y configuración regional.
• Transporte: transportistas disponibles para la dirección del cliente.
• Clientes > Grupos: permisos o precios específicos que puedan afectar al checkout.
• Módulo de pago: importes mínimo y máximo, países habilitados, tipos de tarjeta, modo de operación.

Importes y decimales

Algunas pasarelas son estrictas con el formato de importes. Un redondeo mal configurado, una diferencia entre impuestos incluidos y excluidos, o una moneda con decimales particulares puede provocar rechazos o discrepancias. PrestaShop maneja reglas de redondeo configurables; los proveedores, en cambio, pueden exigir importes en unidades menores, como céntimos, sin decimales. Si el módulo no transforma bien esos valores, el pago puede fallar.

Presta especial atención a:

• Reglas de redondeo.
• Cupones y descuentos.
• Gastos de envío gratuitos.
• Productos virtuales.
• Pedidos con importe cero.
• Impuestos compuestos o configuraciones por zona.

Prueba útil: crea carritos con importes simples: 10 €, 10,01 €, producto con descuento, producto virtual, envío gratuito y compra internacional. Si el error aparece solo en una combinación, ya no buscas una aguja en un pajar; buscas una aguja en una esquina concreta del pajar.

Casos frecuentes por pasarela de pago en PrestaShop 💳

Cada proveedor tiene su propio temperamento. Algunos son meticulosos como notarios; otros, veloces como mensajeros en moto; otros combinan ambas cosas y llaman “experiencia de integración” a lo que uno recordará como una pequeña travesía por el desierto. Veamos problemas habituales en pasarelas populares.

Redsys / Sermepa / Bizum en PrestaShop

Redsys es muy utilizado en España para pagos con tarjeta y Bizum a través de bancos. Sus problemas más comunes suelen estar relacionados con firmas, claves, terminales y parámetros del comercio.

• Firma incorrecta: revisa la clave secreta, el algoritmo de firma y que no haya espacios copiados accidentalmente.
• Código FUC, terminal o moneda erróneos: deben coincidir con los datos proporcionados por el banco.
• Modo pruebas vs real: las credenciales de sandbox no sirven en producción, y viceversa.
• URL de notificación: debe ser accesible desde Redsys. Evita bloqueos por firewall o mantenimiento.
• Bizum no aparece: confirma que el banco lo haya habilitado para el comercio y que el módulo lo soporte.
• 3D Secure: puede requerir configuración específica según banco y módulo.

Si Redsys devuelve códigos de error, consúltalos en la documentación oficial o en el panel del banco. No todos los errores son de PrestaShop; a veces el TPV simplemente está rechazando una operación por configuración del comercio.

PayPal en PrestaShop

PayPal puede trabajar con redirección, botones inteligentes, pagos con tarjeta según país y configuración, y notificaciones IPN o webhooks según módulo. Los conflictos más frecuentes:

• Credenciales API incorrectas o cuenta no verificada.
• Moneda no aceptada por la cuenta PayPal.
• IPN desactivado o URL antigua.
• Botones que no cargan por bloqueo de JavaScript.
• Problemas con ventanas emergentes o scripts bloqueados por políticas de cookies.
• Cuenta en modo sandbox mientras la tienda espera pagos reales.

PayPal suele ofrecer buenos registros de actividad. Revisa si el pago se creó, si fue cancelado por el usuario, si quedó pendiente por revisión o si ni siquiera llegó a iniciarse.

Stripe en PrestaShop

Stripe exige especial atención a webhooks, claves publicables/secretas, Payment Intents y métodos de autenticación como 3D Secure. En Europa, por la normativa PSD2 y la autenticación reforzada del cliente, un módulo antiguo que no soporte correctamente SCA puede causar fallos de pago.

• Webhook mal configurado: Stripe debe enviar eventos al endpoint correcto del módulo.
• Secreto de webhook incorrecto: si no coincide, el módulo rechaza el evento.
• Claves mezcladas: no combines clave publicable de pruebas con clave secreta real.
• 3D Secure no finaliza: revisa scripts, iframes, políticas de seguridad y checkout personalizado.
• Métodos locales: iDEAL, Bancontact, Klarna u otros requieren configuración específica y países/monedas compatibles.

Mercado Pago, PayU, Paycomet, Adyen, Klarna y otros

En Latinoamérica, Mercado Pago y PayU son habituales; en Europa, Adyen, Klarna, Mollie, Paycomet o Checkout.com aparecen con frecuencia según mercado. Aunque cada integración tiene matices, los patrones se repiten:

• Credenciales por entorno.
• País y moneda compatibles.
• Webhooks o notificaciones correctamente registrados.
• Requisitos de identificación fiscal o dirección.
• SDKs que dependen de JavaScript no bloqueado.
• Revisión antifraude que deja pagos en estado pendiente.

Seguridad, PSD2 y cumplimiento: vender no justifica bajar la guardia 🛡️

Cuando el pago falla, alguien siempre propone una solución peligrosa: “desactiva eso de seguridad a ver si funciona”. La frase parece inocente, pero tiene la elegancia técnica de apagar la alarma de incendios porque hace ruido. En pagos online, la seguridad no es un adorno; es el suelo.

PCI DSS y datos de tarjeta

La norma PCI DSS regula el tratamiento de datos de tarjetas. En la práctica, la mayoría de tiendas PrestaShop deberían evitar almacenar datos sensibles de tarjeta y usar pasarelas tokenizadas, formularios alojados, redirecciones seguras o componentes embebidos del proveedor. Si tu tienda captura directamente datos de tarjeta, el nivel de responsabilidad aumenta mucho.

Buenas prácticas:

• No guardes números de tarjeta, CVV ni datos sensibles en logs.
• Usa módulos oficiales o mantenidos por proveedores confiables.
• Mantén PrestaShop, módulos y servidor actualizados.
• Restringe accesos al Back Office con contraseñas fuertes y doble factor si está disponible.
• Audita permisos de archivos y carpetas.
• Elimina módulos antiguos no usados.

PSD2, SCA y 3D Secure

En el Espacio Económico Europeo, la PSD2 impulsó la autenticación reforzada del cliente, conocida como SCA. En términos prácticos: muchos pagos requieren validación adicional mediante 3D Secure u otros mecanismos. Los módulos antiguos que no implementan correctamente estos flujos pueden provocar rechazos o estados incompletos.

Si tienes clientes europeos, revisa que tu módulo soporte:

• 3D Secure 2.
• Autenticación dinámica cuando el banco la exige.
• Pagos con autorización y captura, si tu operativa lo requiere.
• Exenciones SCA correctamente gestionadas por el proveedor, no improvisadas desde la tienda.

CSP, cookies y scripts de pago

Las políticas de seguridad de contenido, los banners de cookies y las herramientas anti-tracking pueden afectar a scripts de pago. Si aplicas una Content Security Policy estricta, permite dominios necesarios del proveedor. Si tu gestor de consentimiento bloquea scripts esenciales hasta que el usuario acepta cookies, asegúrate de no bloquear componentes imprescindibles para procesar el pago cuando la base legal o la clasificación técnica lo permita.

Caché, rendimiento y optimización: cuando acelerar rompe el motor 🚀

PrestaShop incluye caché de Smarty, CCC para combinar, comprimir y cachear CSS/JavaScript, y puede convivir con cachés del servidor, CDN, Redis, Memcached, LiteSpeed Cache, Varnish o Cloudflare. Todo esto puede mejorar el rendimiento. También puede conservar una versión antigua del checkout como un insecto atrapado en ámbar.

Qué limpiar después de tocar una pasarela

• Caché de PrestaShop.
• Caché de Smarty.
• Caché del navegador durante pruebas.
• Caché de CDN o proxy.
• OPcache de PHP si hay cambios de código.
• Caché del módulo de optimización.

Si usas Cloudflare u otro CDN, evita cachear páginas dinámicas del checkout, carrito, cuenta de cliente, módulos de pago y endpoints de webhook. Un checkout cacheado es una contradicción peligrosa: pretende ser personal y se comporta como fotocopia.

Regla práctica: nunca optimices a ciegas el checkout. Excluye de minificación o diferido los scripts críticos de la pasarela cuando el proveedor lo recomiende. La velocidad importa, claro. Pero una página de pago ultrarrápida que no cobra es solo una página muy eficiente en fracasar.

Multi-tienda, idiomas y dominios: el laberinto elegante de PrestaShop 🧩

PrestaShop multitienda permite gestionar varios escaparates desde una misma instalación. Es potente. También añade capas de complejidad que pueden afectar a pasarelas de pago. Un módulo puede estar configurado para una tienda, pero no para otra; una URL de retorno puede apuntar al dominio equivocado; una moneda puede estar activa en un contexto y no en otro.

Revisiones en entornos multitienda

• Selecciona el contexto correcto en el Back Office antes de configurar el módulo.
• Comprueba credenciales por tienda si cada dominio usa una cuenta de comercio distinta.
• Revisa URLs de webhook por dominio.
• Confirma moneda, país y transportista en cada tienda.
• Verifica certificados SSL para todos los dominios.
• Asegúrate de que el proveedor permite el dominio usado en producción.

En tiendas multilingües, revisa también URLs amigables y redirecciones por idioma. Algunos módulos generan URLs de retorno que pueden verse afectadas por reglas de reescritura o configuraciones de idioma en la ruta.

Procedimiento profesional para corregir el problema sin romper la tienda 🛠️

Cuando una pasarela falla, el tiempo presiona. Cada minuto sin cobrar parece una moneda cayendo por una alcantarilla. Pero actuar con prisa no significa actuar sin método.

Plan recomendado

1. Haz copia de seguridad completa: archivos y base de datos. Verifica que puedes restaurarla.
2. Clona la tienda en staging: reproduce ahí el fallo antes de tocar producción.
3. Documenta el entorno: versión PrestaShop, PHP, MySQL/MariaDB, módulo, tema, servidor.
4. Revisa logs: PrestaShop, PHP, servidor, proveedor de pago.
5. Prueba con configuración mínima: tema clásico, caché desactivada, módulos no esenciales fuera.
6. Actualiza de forma escalonada: primero módulo, luego dependencias, luego PHP o núcleo si procede.
7. Valida en sandbox: usa tarjetas de prueba y escenarios de éxito, rechazo y 3D Secure.
8. Prueba en producción con importe bajo: confirma creación de pedido, cobro, factura, email y estado.
9. Monitorea las primeras horas: revisa webhooks, errores y pedidos reales.

Tarjetas y escenarios de prueba

Muchos proveedores ofrecen tarjetas de prueba para simular pagos aprobados, rechazados, autenticación 3D Secure, fondos insuficientes o errores. Úsalas. No basta con probar “un pago correcto”; hay que probar también el tropiezo. Un sistema que solo ha ensayado la felicidad se descompone en cuanto aparece la vida real.

Escenarios mínimos:

• Pago aprobado.
• Pago rechazado.
• Pago con 3D Secure aprobado.
• 3D Secure abandonado por el cliente.
• Pago pendiente o en revisión.
• Reembolso parcial y total.
• Cancelación antes de volver a la tienda.
• Pedido con cupón, envío gratuito y moneda alternativa.

Errores de configuración que conviene mirar dos veces 👀

En soporte técnico hay una verdad humilde: muchas incidencias graves nacen de un campo mal copiado. Una clave con un espacio al final. Una URL con HTTP en vez de HTTPS. Un modo pruebas olvidado en producción. La épica del comercio digital, derrotada por un carácter invisible.

Cuándo contactar al proveedor, al hosting o a un desarrollador

No todo debe resolverse desde el Back Office. Saber a quién preguntar ahorra tiempo y evita respuestas circulares, esa danza triste donde el hosting culpa al módulo, el módulo culpa al proveedor y el proveedor culpa a la tienda con la serenidad de quien nunca ha visto tu instalación.

Contacta al proveedor de pago si…

• El panel muestra rechazos bancarios o errores de comercio.
• Las credenciales parecen inválidas aunque estén bien copiadas.
• El método de pago local no está habilitado.
• Hay dudas sobre 3D Secure, SCA, límites o revisión antifraude.
• Los webhooks no se envían o se envían con errores documentados.

Contacta al hosting si…

• Hay errores cURL, SSL, DNS o timeout.
• El firewall bloquea notificaciones.
• PHP, OpenSSL o extensiones están desactualizadas.
• El servidor registra errores 500 o falta de memoria.
• Necesitas revisar logs a los que no tienes acceso.

Contacta a un desarrollador PrestaShop si…

• El problema aparece tras una actualización.
• Hay overrides personalizados.
• El tema modifica el checkout.
• Hay conflictos entre módulos.
• Necesitas adaptar una pasarela a un flujo especial de negocio.

Información que debes enviar para recibir ayuda útil:

• Versión exacta de PrestaShop.
• Versión de PHP y tipo de servidor.
• Nombre y versión del módulo de pago.
• Pasos exactos para reproducir el fallo.
• Capturas de pantalla sin datos sensibles.
• Fragmentos de logs relevantes.
• Hora y zona horaria de una prueba fallida.
• ID de transacción o evento en el proveedor, si existe.

Checklist profesional para solucionar problemas de pasarelas de pago en PrestaShop ✅

Si necesitas una ruta breve —no superficial, breve— sigue esta lista. Es el tipo de checklist que conviene tener a mano antes de tocar nada, como quien revisa el mapa antes de internarse en un bosque que ya se ha tragado a otros.

Diagnóstico inicial

• Confirmar si el error afecta a todos los clientes o solo a algunos.
• Probar con diferentes navegadores y dispositivos.
• Revisar si el método de pago aparece según país, moneda y transportista.
• Identificar si el proveedor registra el intento de pago.
• Anotar hora exacta y pasos de reproducción.

Compatibilidad

• Verificar versión exacta de PrestaShop.
• Verificar versión PHP compatible.
• Actualizar el módulo de pago a una versión compatible.
• Revisar changelog del módulo y documentación del proveedor.
• Comprobar compatibilidad con tema y módulos de checkout.

Configuración

• Revisar credenciales API, claves secretas y modo sandbox/producción.
• Confirmar URLs de retorno, cancelación y webhook.
• Comprobar restricciones por moneda, país, grupo y transportista.
• Validar estados de pedido asociados al pago.
• Confirmar que el comercio está activo y verificado en la pasarela.

Servidor y seguridad

• SSL válido y HTTPS forzado correctamente.
• cURL y OpenSSL activos y actualizados.
• TLS 1.2 o superior disponible.
• Firewall/WAF sin bloqueo de callbacks.
• Logs revisados sin exposición de datos sensibles.

Pruebas finales

• Limpiar caché de PrestaShop, CDN y navegador.
• Probar pago aprobado y rechazado.
• Probar 3D Secure si aplica.
• Confirmar actualización de estado del pedido.
• Verificar emails, factura, stock y back office.

Buenas prácticas para que el problema no vuelva cada temporada 🌱

La estabilidad de pagos no se consigue con una intervención heroica al año. Se consigue con mantenimiento. Menos épica, más calendario. Menos apagar incendios, más revisar cables antes de que huelan a quemado.

• Mantén un entorno de pruebas permanente: no uses producción como laboratorio.
• Planifica actualizaciones: PrestaShop, módulos, tema y PHP deben evolucionar con orden.
• Monitoriza pagos fallidos: revisa tendencias, no solo incidencias aisladas.
• Documenta configuración crítica: credenciales, endpoints, estados de pedido, restricciones.
• Haz pruebas periódicas: especialmente después de cambios en checkout, servidor o pasarela.
• Evita módulos abandonados: un módulo de pago sin mantenimiento es una promesa vencida.
• Revisa la seguridad: accesos, permisos, SSL, logs y cumplimiento.
• Conserva métodos alternativos: transferencia, contra reembolso, PayPal, tarjeta u otro método según negocio. Un único punto de fallo es cómodo hasta que falla.

También conviene medir el impacto real. Si muchos usuarios abandonan en el paso de pago, no siempre se trata de compatibilidad técnica: puede haber falta de confianza, costes sorpresa, formularios largos, métodos insuficientes o errores de usabilidad. La pasarela debe funcionar, sí; pero el checkout también debe persuadir sin empujar, informar sin cansar, pedir datos sin parecer interrogatorio.

Una mirada final: cobrar es técnico, pero también es confianza

Solucionar problemas de compatibilidad con pasarelas de pago en PrestaShop no es únicamente reparar un módulo. Es proteger el momento más frágil de una tienda online: aquel en el que el visitante deja de mirar y decide confiar. Todo lo anterior —SEO, campañas, diseño, fichas de producto, velocidad, fotografías— desemboca ahí, en un botón de pago que debe responder con la naturalidad de una llave bien tallada.

La buena noticia es que casi todos estos problemas tienen método. Versiones compatibles, logs claros, SSL correcto, webhooks accesibles, checkout limpio, configuración coherente y pruebas reales. No hay magia. Hay oficio. Y en el comercio electrónico, el oficio se nota precisamente cuando nada interrumpe al cliente.

Una pasarela de pago bien integrada desaparece. No presume, no declama, no exige aplausos. Simplemente permite comprar. Y esa invisibilidad, tan poco vistosa y tan rentable, es una de las formas más elegantes de la tecnología bien hecha. 💼✨