{"id":3712,"date":"2026-07-19T11:43:18","date_gmt":"2026-07-19T09:43:18","guid":{"rendered":"https:\/\/mantenimientoweb.pro\/blog\/como-solucionar-problemas-de-compatibilidad-con-pasarelas-de-pago-en-prestashop\/"},"modified":"2026-07-19T11:43:20","modified_gmt":"2026-07-19T09:43:20","slug":"como-solucionar-problemas-de-compatibilidad-con-pasarelas-de-pago-en-prestashop","status":"publish","type":"post","link":"https:\/\/mantenimientoweb.pro\/blog\/como-solucionar-problemas-de-compatibilidad-con-pasarelas-de-pago-en-prestashop\/","title":{"rendered":"\u00bfC\u00f3mo solucionar problemas de compatibilidad con pasarelas de pago en PrestaShop?"},"content":{"rendered":"<header>\n<p>      \u00bfC\u00f3mo solucionar problemas de compatibilidad con pasarelas de pago en PrestaShop? \ud83d\uded2\ud83d\udcb3<\/p>\n<p>Hay pocas escenas m\u00e1s crueles en una tienda online que un cliente dispuesto a pagar y una pasarela que decide, con solemnidad burocr\u00e1tica, no colaborar. Todo parece estar listo: producto elegido, carrito lleno, intenci\u00f3n de compra intacta. Y entonces aparece el error. A veces visible, a veces silencioso. Como una puerta autom\u00e1tica que se abre para todos menos para quien trae la cartera en la mano.<\/p>\n<p>Esta gu\u00eda est\u00e1 pensada para propietarios de tiendas, desarrolladores y responsables t\u00e9cnicos que necesitan diagnosticar y resolver problemas de compatibilidad con pasarelas de pago en PrestaShop sin perderse entre m\u00f3dulos, versiones de PHP, certificados SSL, webhooks, cach\u00e9s, temas personalizados y respuestas cr\u00edpticas del banco.<\/p>\n<nav aria-label=\"Tabla de contenidos\">\n        <strong>Contenido de la gu\u00eda<\/strong><\/p>\n<ul>\n<li><a href=\"#por-que-fallan\">Por qu\u00e9 fallan las pasarelas de pago<\/a><\/li>\n<li><a href=\"#sintomas\">S\u00edntomas habituales en PrestaShop<\/a><\/li>\n<li><a href=\"#compatibilidad-versiones\">Versiones, PHP y m\u00f3dulos<\/a><\/li>\n<li><a href=\"#diagnostico\">M\u00e9todo de diagn\u00f3stico paso a paso<\/a><\/li>\n<li><a href=\"#ssl\">SSL, TLS, cURL y servidor<\/a><\/li>\n<li><a href=\"#webhooks\">Webhooks, IPN y notificaciones<\/a><\/li>\n<li><a href=\"#checkout\">Tema, checkout y JavaScript<\/a><\/li>\n<li><a href=\"#moneda-pais\">Monedas, pa\u00edses, impuestos y transportistas<\/a><\/li>\n<li><a href=\"#pasarelas\">Casos frecuentes: Redsys, PayPal, Stripe y m\u00e1s<\/a><\/li>\n<li><a href=\"#seguridad\">Seguridad, PSD2 y cumplimiento<\/a><\/li>\n<li><a href=\"#checklist\">Checklist profesional<\/a><\/li>\n<\/ul>\n<\/nav>\n<\/header>\n<article>\n<section id=\"por-que-fallan\">\n<h2>El problema no siempre est\u00e1 donde duele<\/h2>\n<p>Cuando una pasarela de pago falla en PrestaShop, la tentaci\u00f3n inmediata es culpar al m\u00f3dulo. Es humano. Tambi\u00e9n es c\u00f3modo. Pero en comercio electr\u00f3nico, como en ciertas novelas policiales, el culpable rara vez aparece con una etiqueta en la solapa. El error puede nacer en una versi\u00f3n 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\u00f3n de PrestaShop que dej\u00f3 a un m\u00f3dulo antiguo mirando al futuro como quien mira llover desde una estaci\u00f3n abandonada.<\/p>\n<p>PrestaShop funciona como un ecosistema. N\u00facleo, m\u00f3dulos, tema, servidor, m\u00e9todos de transporte, reglas de impuestos, cach\u00e9, 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.<\/p>\n<p>La paradoja es conocida: cuanto m\u00e1s \u201csimple\u201d parece un bot\u00f3n de pago, m\u00e1s capas t\u00e9cnicas tiene debajo. Un clic puede activar validaciones de carrito, sesiones, tokens, redirecciones, APIs REST, callbacks, webhooks, estados de pedido, reglas antifraude y autenticaci\u00f3n reforzada del cliente. Minimalismo en la pantalla, complejidad en las entra\u00f1as. La modernidad nos prometi\u00f3 comprar en dos clics; discretamente olvid\u00f3 mencionar los veinte sistemas negociando en la sombra.<\/p>\n<p><strong>Idea clave:<\/strong> solucionar problemas de compatibilidad con pasarelas de pago en PrestaShop exige separar s\u00edntomas de causas. Un \u201cpago rechazado\u201d puede ser un rechazo bancario real, pero tambi\u00e9n un fallo de comunicaci\u00f3n entre la pasarela y la tienda, un problema de SSL, un error de configuraci\u00f3n del m\u00f3dulo o una incompatibilidad del checkout.<\/p>\n<\/section>\n<section id=\"sintomas\">\n<h2>S\u00edntomas habituales: cuando la tienda habla en susurros \u26a0\ufe0f<\/h2>\n<p>Antes de tocar configuraciones, conviene escuchar. PrestaShop suele dejar pistas; algunas son claras, otras parecen escritas por un or\u00e1culo con prisa. Estos son los s\u00edntomas m\u00e1s frecuentes cuando hay problemas de compatibilidad con m\u00e9todos de pago en PrestaShop:<\/p>\n<h3>El m\u00e9todo de pago no aparece<\/h3>\n<p>El cliente llega al checkout y la pasarela no se muestra. Puede deberse a restricciones por pa\u00eds, moneda, grupo de clientes, transportista, importe m\u00ednimo\/m\u00e1ximo, modo sandbox, permisos del m\u00f3dulo o errores JavaScript.<\/p>\n<h3>Redirecci\u00f3n rota o pantalla en blanco<\/h3>\n<p>Al hacer clic en pagar, aparece una p\u00e1gina en blanco, un error 500, una URL incorrecta o un bucle de redirecci\u00f3n. Suele apuntar a incompatibilidad de m\u00f3dulo, override conflictivo, cach\u00e9, versi\u00f3n de PHP o error en plantilla.<\/p>\n<h3>Pedido creado pero sin pago confirmado<\/h3>\n<p>El cliente paga, pero PrestaShop deja el pedido como \u201cpendiente\u201d, \u201cerror de pago\u201d o ni siquiera lo crea correctamente. Aqu\u00ed suelen intervenir webhooks, IPN, URLs de retorno, estados de pedido y validaci\u00f3n de firma.<\/p>\n<h3>Pagos rechazados sin motivo evidente<\/h3>\n<p>Puede ser una tarjeta realmente rechazada, pero tambi\u00e9n un problema con 3D Secure, SCA, credenciales API, modo de pruebas, l\u00edmites antifraude, moneda no aceptada o configuraci\u00f3n del comercio en el proveedor.<\/p>\n<p>Una an\u00e9cdota m\u00ednima: una vez vi una tienda que llevaba tres d\u00edas culpando a Stripe por pagos fallidos. Al final, el problema era un m\u00f3dulo de optimizaci\u00f3n que retrasaba JavaScript \u201cpara mejorar la velocidad\u201d. La tienda iba m\u00e1s r\u00e1pida, s\u00ed; tan r\u00e1pida que el formulario de pago no alcanzaba a cargar. La optimizaci\u00f3n, ese arte noble que a veces se comporta como un camarero que retira el plato antes de servir la comida.<\/p>\n<\/section>\n<section id=\"compatibilidad-versiones\">\n<h2>Versiones de PrestaShop, PHP y m\u00f3dulos: el tri\u00e1ngulo donde se pierden muchas tardes \ud83d\udd27<\/h2>\n<p>La compatibilidad t\u00e9cnica empieza por una pregunta aburrida, por tanto imprescindible: \u00bfqu\u00e9 versiones exactas est\u00e1s usando? No basta con decir \u201cPrestaShop 1.7\u201d o \u201cel m\u00f3dulo est\u00e1 actualizado\u201d. En soporte t\u00e9cnico, la vaguedad es niebla; los n\u00fameros son faros.<\/p>\n<p>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\u00e1s, los m\u00f3dulos de pago suelen apoyarse en librer\u00edas 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.<\/p>\n<table>\n<thead>\n<tr>\n<th>Elemento<\/th>\n<th>Qu\u00e9 revisar<\/th>\n<th>Por qu\u00e9 importa<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Versi\u00f3n de PrestaShop<\/td>\n<td>Back office &gt; Par\u00e1metros avanzados &gt; Informaci\u00f3n<\/td>\n<td>Un m\u00f3dulo compatible con PrestaShop 8 puede no funcionar correctamente en 1.7.6, y uno antiguo para 1.7 puede romperse en versiones recientes.<\/td>\n<\/tr>\n<tr>\n<td>Versi\u00f3n de PHP<\/td>\n<td>Panel del hosting, phpinfo o informaci\u00f3n del sistema<\/td>\n<td>PHP 8 endureci\u00f3 avisos y errores; m\u00f3dulos antiguos con c\u00f3digo obsoleto pueden generar fallos fatales.<\/td>\n<\/tr>\n<tr>\n<td>Versi\u00f3n del m\u00f3dulo de pago<\/td>\n<td>Gestor de m\u00f3dulos de PrestaShop y changelog del proveedor<\/td>\n<td>Los m\u00f3dulos corrigen compatibilidad con APIs, 3D Secure, webhooks, firmas y cambios del proveedor.<\/td>\n<\/tr>\n<tr>\n<td>Tema y checkout<\/td>\n<td>Tema activo, m\u00f3dulos de one page checkout, overrides<\/td>\n<td>Muchos problemas no nacen en la pasarela, sino en un checkout personalizado que no respeta hooks o scripts.<\/td>\n<\/tr>\n<tr>\n<td>Servidor<\/td>\n<td>cURL, OpenSSL, TLS, permisos, WAF, mod_security<\/td>\n<td>La pasarela necesita comunicarse con APIs externas y recibir notificaciones. Si el servidor bloquea, el pago queda cojo.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p><strong>Atenci\u00f3n:<\/strong> no actualices PrestaShop, PHP y el m\u00f3dulo de pago a la vez en producci\u00f3n \u201cpara ahorrar tiempo\u201d. Es una de esas econom\u00edas brillantes que luego se pagan con una noche larga, caf\u00e9 malo y clientes preguntando por qu\u00e9 no pueden pagar. Hazlo en entorno de pruebas, con copia de seguridad y cambios controlados.<\/p>\n<h3>Compatibilidad con PHP: el detalle que parece t\u00e9cnico hasta que cuesta dinero<\/h3>\n<p>Los problemas de PHP son especialmente traicioneros. Una tienda puede funcionar en apariencia \u2014cat\u00e1logo, carrito, login\u2014 y fallar justo en el pago porque el m\u00f3dulo usa una funci\u00f3n incompatible, una dependencia no actualizada o una librer\u00eda que ya no se comporta igual.<\/p>\n<p>Como regla pr\u00e1ctica:<\/p>\n<ul>\n<li>Consulta siempre la matriz oficial de compatibilidad de tu versi\u00f3n de PrestaShop antes de cambiar PHP.<\/li>\n<li>Verifica que el m\u00f3dulo de pago declare compatibilidad con tu versi\u00f3n de PrestaShop y PHP.<\/li>\n<li>No asumas que \u201cm\u00e1s nuevo\u201d significa \u201cmejor\u201d para una tienda antigua. La novedad sin compatibilidad es solo una forma elegante de incendio.<\/li>\n<li>Si tu tienda est\u00e1 en PrestaShop 1.7 antiguo, eval\u00faa una actualizaci\u00f3n planificada: muchos proveedores priorizan soporte para versiones mantenidas.<\/li>\n<\/ul>\n<\/section>\n<section id=\"diagnostico\">\n<h2>M\u00e9todo de diagn\u00f3stico paso a paso: del caos al mapa \ud83e\udded<\/h2>\n<p>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\u00f3stico sigue un orden, reduce variables y documenta hallazgos.<\/p>\n<h3>1. Reproduce el error con precisi\u00f3n<\/h3>\n<p>Necesitas saber exactamente qu\u00e9 ocurre:<\/p>\n<ul>\n<li>\u00bfEl m\u00e9todo de pago no aparece o aparece y falla?<\/li>\n<li>\u00bfFalla con todos los productos o solo con algunos?<\/li>\n<li>\u00bfOcurre en m\u00f3vil, escritorio o ambos?<\/li>\n<li>\u00bfAfecta a todos los clientes o solo a invitados?<\/li>\n<li>\u00bfSucede con una moneda, pa\u00eds o transportista concreto?<\/li>\n<li>\u00bfEl pago falla antes o despu\u00e9s de redirigir al proveedor?<\/li>\n<li>\u00bfEl proveedor registra el intento de pago?<\/li>\n<\/ul>\n<p>Haz una compra de prueba con un producto econ\u00f3mico 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.<\/p>\n<h3>2. Activa el modo depuraci\u00f3n con cuidado<\/h3>\n<p>En PrestaShop puedes activar el modo debug desde <strong>Par\u00e1metros avanzados &gt; Rendimiento<\/strong> en muchas instalaciones, o mediante configuraci\u00f3n t\u00e9cnica seg\u00fan versi\u00f3n. Tambi\u00e9n puedes revisar logs en:<\/p>\n<ul>\n<li><code>var\/logs\/<\/code> en versiones modernas.<\/li>\n<li><code>app\/logs\/<\/code> en algunas instalaciones de PrestaShop 1.7.<\/li>\n<li>Logs del servidor: Apache, Nginx, PHP-FPM, LiteSpeed.<\/li>\n<li>Logs internos del m\u00f3dulo de pago, si los ofrece.<\/li>\n<li>Panel del proveedor: eventos, webhooks, intentos de pago, respuestas de API.<\/li>\n<\/ul>\n<p><strong>No dejes el modo debug activado en producci\u00f3n<\/strong> m\u00e1s tiempo del estrictamente necesario. Puede exponer rutas internas, mensajes sensibles o detalles de configuraci\u00f3n. En una tienda online, la transparencia excesiva no es virtud: es una ventana abierta en planta baja.<\/p>\n<h3>3. Diferencia error de cliente, error de tienda y error de proveedor<\/h3>\n<table>\n<thead>\n<tr>\n<th>Tipo de fallo<\/th>\n<th>Se\u00f1ales habituales<\/th>\n<th>Acci\u00f3n recomendada<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Error de cliente<\/td>\n<td>Tarjeta sin fondos, autenticaci\u00f3n bancaria fallida, datos incorrectos, operaci\u00f3n rechazada por el emisor.<\/td>\n<td>Confirmar en el panel de la pasarela. Ofrecer otro m\u00e9todo de pago y mensajes claros.<\/td>\n<\/tr>\n<tr>\n<td>Error de tienda<\/td>\n<td>Error 500, pantalla en blanco, m\u00e9todo no visible, JavaScript roto, pedido no creado, incompatibilidad de m\u00f3dulos.<\/td>\n<td>Revisar logs, tema, checkout, versi\u00f3n PHP, overrides, cach\u00e9 y configuraci\u00f3n del m\u00f3dulo.<\/td>\n<\/tr>\n<tr>\n<td>Error de proveedor<\/td>\n<td>API ca\u00edda, credenciales revocadas, webhook no entregado, cambios de endpoint, restricciones del comercio.<\/td>\n<td>Consultar estado del servicio, documentaci\u00f3n oficial y soporte del proveedor.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h3>4. Desactiva interferencias, no funcionalidades esenciales<\/h3>\n<p>En un entorno de staging, desactiva temporalmente m\u00f3dulos que puedan tocar el checkout:<\/p>\n<ul>\n<li>M\u00f3dulos de \u201cone page checkout\u201d.<\/li>\n<li>Optimizadores de JavaScript y CSS.<\/li>\n<li>M\u00f3dulos de cach\u00e9 avanzada.<\/li>\n<li>Herramientas de consentimiento de cookies que bloqueen scripts.<\/li>\n<li>Extensiones antifraude de terceros.<\/li>\n<li>Personalizaciones del tema sobre la p\u00e1gina de pedido.<\/li>\n<\/ul>\n<p>Si el pago funciona con el tema cl\u00e1sico y falla con el tema personalizado, el diagn\u00f3stico acaba de ponerse interesante. No necesariamente agradable, pero s\u00ed honesto.<\/p>\n<\/section>\n<section id=\"ssl\">\n<h2>SSL, TLS, cURL y servidor: la fontaner\u00eda invisible del pago \ud83d\udd10<\/h2>\n<p>Una pasarela de pago moderna exige comunicaci\u00f3n segura. Si el certificado SSL est\u00e1 mal instalado, si TLS es obsoleto, si cURL no puede conectarse o si el firewall bloquea una notificaci\u00f3n, el sistema falla con la discreci\u00f3n de una tuber\u00eda rota detr\u00e1s de la pared: no se ve, pero todo se humedece.<\/p>\n<h3>Certificado SSL correctamente instalado<\/h3>\n<p>PrestaShop debe funcionar \u00edntegramente bajo HTTPS, no solo en el checkout. Revisa:<\/p>\n<ul>\n<li>Certificado v\u00e1lido y no caducado.<\/li>\n<li>Cadena intermedia correctamente instalada.<\/li>\n<li>Redirecci\u00f3n consistente de HTTP a HTTPS.<\/li>\n<li>Dominio can\u00f3nico coherente: con o sin <code>www<\/code>, pero no ambos pele\u00e1ndose.<\/li>\n<li>Sin contenido mixto: scripts, im\u00e1genes o CSS cargados por HTTP.<\/li>\n<\/ul>\n<p>En Back Office, revisa la configuraci\u00f3n SSL de PrestaShop y confirma que el dominio de la tienda coincide con el dominio usado en la pasarela. Un peque\u00f1o desajuste puede bastar para que el proveedor rechace callbacks o redirecciones.<\/p>\n<h3>TLS y cURL<\/h3>\n<p>La mayor\u00eda de proveedores de pago requieren TLS moderno, habitualmente TLS 1.2 o superior. Si tu servidor todav\u00eda depende de protocolos antiguos, el problema no es que la pasarela sea exigente; es que tu servidor est\u00e1 intentando entrar a una reuni\u00f3n de 2025 vestido para 2009.<\/p>\n<p>Verifica que el hosting tenga:<\/p>\n<ul>\n<li>Extensi\u00f3n <code>cURL<\/code> activa.<\/li>\n<li>OpenSSL actualizado.<\/li>\n<li>Soporte para TLS 1.2 o superior.<\/li>\n<li>Permisos de salida hacia endpoints del proveedor.<\/li>\n<li>Resoluci\u00f3n DNS correcta.<\/li>\n<li>Sin bloqueo por WAF, <code>mod_security<\/code>, reglas anti-bot o firewall externo.<\/li>\n<\/ul>\n<h3>Errores t\u00edpicos relacionados con servidor<\/h3>\n<table>\n<thead>\n<tr>\n<th>Error o se\u00f1al<\/th>\n<th>Posible causa<\/th>\n<th>Soluci\u00f3n<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><code>cURL error 35<\/code> o errores SSL<\/td>\n<td>Problemas de negociaci\u00f3n TLS, certificado, OpenSSL antiguo.<\/td>\n<td>Actualizar OpenSSL\/cURL, revisar certificado y compatibilidad TLS del servidor.<\/td>\n<\/tr>\n<tr>\n<td><code>403 Forbidden<\/code> en webhook<\/td>\n<td>Firewall, WAF, bloqueo por IP, regla de seguridad.<\/td>\n<td>Permitir URLs de callback, revisar logs de seguridad y whitelist si el proveedor lo documenta.<\/td>\n<\/tr>\n<tr>\n<td><code>500 Internal Server Error<\/code><\/td>\n<td>Error PHP, memoria insuficiente, incompatibilidad del m\u00f3dulo, override.<\/td>\n<td>Activar debug temporalmente, revisar logs PHP y aumentar memoria si procede.<\/td>\n<\/tr>\n<tr>\n<td>Timeout al pagar<\/td>\n<td>Servidor lento, API externa no responde, DNS o firewall.<\/td>\n<td>Medir tiempos, revisar conectividad saliente y rendimiento del hosting.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/section>\n<section id=\"webhooks\">\n<h2>Webhooks, IPN y URLs de retorno: los mensajeros que nadie ve \ud83d\udcec<\/h2>\n<p>Muchos comerciantes creen que el pago termina cuando el cliente vuelve a la tienda. No exactamente. En pasarelas modernas, la confirmaci\u00f3n fiable suele llegar mediante una notificaci\u00f3n servidor a servidor: webhook, IPN, callback o notificaci\u00f3n as\u00edncrona. Es el cartero invisible que dice: \u201cs\u00ed, este pago existe\u201d.<\/p>\n<p>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\u00ed empieza el peque\u00f1o teatro del absurdo: el banco dice \u201ccobrado\u201d, PrestaShop dice \u201cpendiente\u201d y el cliente dice, con toda raz\u00f3n, \u201c\u00bfme van a enviar mi pedido o tengo que ofrecer un sacrificio?\u201d<\/p>\n<h3>Qu\u00e9 revisar en las notificaciones<\/h3>\n<ul>\n<li><strong>URL de webhook correcta:<\/strong> debe coincidir con la URL generada por el m\u00f3dulo y estar accesible p\u00fablicamente.<\/li>\n<li><strong>HTTPS v\u00e1lido:<\/strong> muchos proveedores rechazan callbacks hacia HTTP o certificados inv\u00e1lidos.<\/li>\n<li><strong>Modo correcto:<\/strong> sandbox y producci\u00f3n suelen tener endpoints, claves y webhooks separados.<\/li>\n<li><strong>Firma o secreto:<\/strong> si la firma del webhook no coincide, el m\u00f3dulo rechazar\u00e1 la notificaci\u00f3n.<\/li>\n<li><strong>Respuesta HTTP:<\/strong> el endpoint deber\u00eda devolver un c\u00f3digo 200 o el esperado por el proveedor.<\/li>\n<li><strong>Firewall:<\/strong> evita bloquear peticiones leg\u00edtimas de la pasarela.<\/li>\n<li><strong>Multi-tienda:<\/strong> confirma que la notificaci\u00f3n llega a la tienda correcta.<\/li>\n<\/ul>\n<h3>Pedidos duplicados o estados incorrectos<\/h3>\n<p>Un webhook reenviado varias veces no deber\u00eda crear pedidos duplicados si el m\u00f3dulo est\u00e1 bien dise\u00f1ado. Aun as\u00ed, pueden aparecer problemas cuando hay personalizaciones del flujo de pedido, overrides o m\u00f3dulos que modifican estados. Revisa la configuraci\u00f3n de estados de pedido:<\/p>\n<ul>\n<li>Pago aceptado.<\/li>\n<li>Pago pendiente.<\/li>\n<li>Error de pago.<\/li>\n<li>Cancelado.<\/li>\n<li>Reembolsado.<\/li>\n<li>Autorizado pendiente de captura, si tu pasarela trabaja con autorizaci\u00f3n\/captura.<\/li>\n<\/ul>\n<p>En pasarelas como Stripe, PayPal o Adyen, el panel del proveedor suele mostrar eventos con gran detalle. \u00dasalo. Es una bit\u00e1cora m\u00e1s fiable que muchas intuiciones.<\/p>\n<\/section>\n<section id=\"checkout\">\n<h2>Tema, checkout y JavaScript: la belleza tambi\u00e9n rompe cosas \ud83c\udfad<\/h2>\n<p>El checkout de PrestaShop depende de hooks, plantillas, scripts y comportamientos din\u00e1micos. Un tema demasiado intervenido puede convertir el pago en una delicada vajilla en una mudanza. Por fuera luce impecable; por dentro, cada pieza cruje.<\/p>\n<p>Los m\u00f3dulos de pago suelen insertarse mediante hooks como los relacionados con opciones de pago, validaci\u00f3n de pedido, cabecera, scripts o display de contenido. Si un tema elimina, altera o reordena esos hooks sin respetar el flujo esperado, el m\u00f3dulo puede no renderizar su formulario, no cargar scripts o no enviar tokens correctamente.<\/p>\n<h3>Conflictos frecuentes en el checkout<\/h3>\n<ul>\n<li><strong>One page checkout de terceros:<\/strong> algunos no son compatibles con todos los m\u00e9todos de pago, especialmente los que requieren formularios embebidos o redirecciones complejas.<\/li>\n<li><strong>Minificaci\u00f3n agresiva:<\/strong> combinar o diferir JavaScript puede romper SDKs de Stripe, PayPal Smart Buttons, Apple Pay, Google Pay o validaciones 3D Secure.<\/li>\n<li><strong>Errores JavaScript previos:<\/strong> un error en un m\u00f3dulo de cookies o analytics puede detener la ejecuci\u00f3n del script de pago.<\/li>\n<li><strong>Plantillas sobrescritas:<\/strong> overrides del tema pueden estar basados en una versi\u00f3n antigua de PrestaShop.<\/li>\n<li><strong>Campos obligatorios personalizados:<\/strong> si el checkout exige datos no est\u00e1ndar, puede bloquear la creaci\u00f3n de pedido.<\/li>\n<\/ul>\n<h3>C\u00f3mo probar si el tema es el culpable<\/h3>\n<ol>\n<li>Crea una copia de la tienda en staging.<\/li>\n<li>Activa temporalmente el tema cl\u00e1sico compatible con tu versi\u00f3n de PrestaShop.<\/li>\n<li>Desactiva m\u00f3dulos de optimizaci\u00f3n frontend.<\/li>\n<li>Prueba el mismo carrito, pa\u00eds, moneda y transportista.<\/li>\n<li>Revisa la consola del navegador y la pesta\u00f1a Network.<\/li>\n<\/ol>\n<p>Si el m\u00e9todo de pago funciona en el tema cl\u00e1sico, 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\u00f3dulo de checkout.<\/p>\n<blockquote><p>\n        Un checkout bonito que impide pagar es como una caja registradora tallada en m\u00e1rmol sin caj\u00f3n para el dinero: admirable, in\u00fatil y ligeramente ofensiva.\n      <\/p><\/blockquote>\n<\/section>\n<section id=\"moneda-pais\">\n<h2>Monedas, pa\u00edses, impuestos y transportistas: la compatibilidad comercial tambi\u00e9n existe \ud83c\udf0d<\/h2>\n<p>No todos los problemas de pasarela son t\u00e9cnicos. Algunos nacen de la configuraci\u00f3n comercial. PrestaShop permite restringir m\u00e9todos de pago por moneda, pa\u00eds, grupo de clientes y transportista. Los m\u00f3dulos, a su vez, pueden imponer sus propias limitaciones. Y los proveedores de pago, por supuesto, tienen reglas: pa\u00edses permitidos, monedas aceptadas, importe m\u00ednimo, tipo de cuenta, m\u00e9todos locales habilitados.<\/p>\n<h3>Cuando el m\u00e9todo de pago no aparece<\/h3>\n<p>Revisa en el Back Office:<\/p>\n<ul>\n<li><strong>Pago &gt; Preferencias:<\/strong> restricciones por moneda, pa\u00eds, grupo y transportista.<\/li>\n<li><strong>Internacional &gt; Localizaci\u00f3n:<\/strong> monedas activas, pa\u00edses, zonas y configuraci\u00f3n regional.<\/li>\n<li><strong>Transporte:<\/strong> transportistas disponibles para la direcci\u00f3n del cliente.<\/li>\n<li><strong>Clientes &gt; Grupos:<\/strong> permisos o precios espec\u00edficos que puedan afectar al checkout.<\/li>\n<li><strong>M\u00f3dulo de pago:<\/strong> importes m\u00ednimo y m\u00e1ximo, pa\u00edses habilitados, tipos de tarjeta, modo de operaci\u00f3n.<\/li>\n<\/ul>\n<h3>Importes y decimales<\/h3>\n<p>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\u00e9ntimos, sin decimales. Si el m\u00f3dulo no transforma bien esos valores, el pago puede fallar.<\/p>\n<p>Presta especial atenci\u00f3n a:<\/p>\n<ul>\n<li>Reglas de redondeo.<\/li>\n<li>Cupones y descuentos.<\/li>\n<li>Gastos de env\u00edo gratuitos.<\/li>\n<li>Productos virtuales.<\/li>\n<li>Pedidos con importe cero.<\/li>\n<li>Impuestos compuestos o configuraciones por zona.<\/li>\n<\/ul>\n<p><strong>Prueba \u00fatil:<\/strong> crea carritos con importes simples: 10 \u20ac, 10,01 \u20ac, producto con descuento, producto virtual, env\u00edo gratuito y compra internacional. Si el error aparece solo en una combinaci\u00f3n, ya no buscas una aguja en un pajar; buscas una aguja en una esquina concreta del pajar.<\/p>\n<\/section>\n<section id=\"pasarelas\">\n<h2>Casos frecuentes por pasarela de pago en PrestaShop \ud83d\udcb3<\/h2>\n<p>Cada proveedor tiene su propio temperamento. Algunos son meticulosos como notarios; otros, veloces como mensajeros en moto; otros combinan ambas cosas y llaman \u201cexperiencia de integraci\u00f3n\u201d a lo que uno recordar\u00e1 como una peque\u00f1a traves\u00eda por el desierto. Veamos problemas habituales en pasarelas populares.<\/p>\n<h3>Redsys \/ Sermepa \/ Bizum en PrestaShop<\/h3>\n<p>Redsys es muy utilizado en Espa\u00f1a para pagos con tarjeta y Bizum a trav\u00e9s de bancos. Sus problemas m\u00e1s comunes suelen estar relacionados con firmas, claves, terminales y par\u00e1metros del comercio.<\/p>\n<ul>\n<li><strong>Firma incorrecta:<\/strong> revisa la clave secreta, el algoritmo de firma y que no haya espacios copiados accidentalmente.<\/li>\n<li><strong>C\u00f3digo FUC, terminal o moneda err\u00f3neos:<\/strong> deben coincidir con los datos proporcionados por el banco.<\/li>\n<li><strong>Modo pruebas vs real:<\/strong> las credenciales de sandbox no sirven en producci\u00f3n, y viceversa.<\/li>\n<li><strong>URL de notificaci\u00f3n:<\/strong> debe ser accesible desde Redsys. Evita bloqueos por firewall o mantenimiento.<\/li>\n<li><strong>Bizum no aparece:<\/strong> confirma que el banco lo haya habilitado para el comercio y que el m\u00f3dulo lo soporte.<\/li>\n<li><strong>3D Secure:<\/strong> puede requerir configuraci\u00f3n espec\u00edfica seg\u00fan banco y m\u00f3dulo.<\/li>\n<\/ul>\n<p>Si Redsys devuelve c\u00f3digos de error, cons\u00faltalos en la documentaci\u00f3n oficial o en el panel del banco. No todos los errores son de PrestaShop; a veces el TPV simplemente est\u00e1 rechazando una operaci\u00f3n por configuraci\u00f3n del comercio.<\/p>\n<h3>PayPal en PrestaShop<\/h3>\n<p>PayPal puede trabajar con redirecci\u00f3n, botones inteligentes, pagos con tarjeta seg\u00fan pa\u00eds y configuraci\u00f3n, y notificaciones IPN o webhooks seg\u00fan m\u00f3dulo. Los conflictos m\u00e1s frecuentes:<\/p>\n<ul>\n<li>Credenciales API incorrectas o cuenta no verificada.<\/li>\n<li>Moneda no aceptada por la cuenta PayPal.<\/li>\n<li>IPN desactivado o URL antigua.<\/li>\n<li>Botones que no cargan por bloqueo de JavaScript.<\/li>\n<li>Problemas con ventanas emergentes o scripts bloqueados por pol\u00edticas de cookies.<\/li>\n<li>Cuenta en modo sandbox mientras la tienda espera pagos reales.<\/li>\n<\/ul>\n<p>PayPal suele ofrecer buenos registros de actividad. Revisa si el pago se cre\u00f3, si fue cancelado por el usuario, si qued\u00f3 pendiente por revisi\u00f3n o si ni siquiera lleg\u00f3 a iniciarse.<\/p>\n<h3>Stripe en PrestaShop<\/h3>\n<p>Stripe exige especial atenci\u00f3n a webhooks, claves publicables\/secretas, Payment Intents y m\u00e9todos de autenticaci\u00f3n como 3D Secure. En Europa, por la normativa PSD2 y la autenticaci\u00f3n reforzada del cliente, un m\u00f3dulo antiguo que no soporte correctamente SCA puede causar fallos de pago.<\/p>\n<ul>\n<li><strong>Webhook mal configurado:<\/strong> Stripe debe enviar eventos al endpoint correcto del m\u00f3dulo.<\/li>\n<li><strong>Secreto de webhook incorrecto:<\/strong> si no coincide, el m\u00f3dulo rechaza el evento.<\/li>\n<li><strong>Claves mezcladas:<\/strong> no combines clave publicable de pruebas con clave secreta real.<\/li>\n<li><strong>3D Secure no finaliza:<\/strong> revisa scripts, iframes, pol\u00edticas de seguridad y checkout personalizado.<\/li>\n<li><strong>M\u00e9todos locales:<\/strong> iDEAL, Bancontact, Klarna u otros requieren configuraci\u00f3n espec\u00edfica y pa\u00edses\/monedas compatibles.<\/li>\n<\/ul>\n<h3>Mercado Pago, PayU, Paycomet, Adyen, Klarna y otros<\/h3>\n<p>En Latinoam\u00e9rica, Mercado Pago y PayU son habituales; en Europa, Adyen, Klarna, Mollie, Paycomet o Checkout.com aparecen con frecuencia seg\u00fan mercado. Aunque cada integraci\u00f3n tiene matices, los patrones se repiten:<\/p>\n<ul>\n<li>Credenciales por entorno.<\/li>\n<li>Pa\u00eds y moneda compatibles.<\/li>\n<li>Webhooks o notificaciones correctamente registrados.<\/li>\n<li>Requisitos de identificaci\u00f3n fiscal o direcci\u00f3n.<\/li>\n<li>SDKs que dependen de JavaScript no bloqueado.<\/li>\n<li>Revisi\u00f3n antifraude que deja pagos en estado pendiente.<\/li>\n<\/ul>\n<table>\n<thead>\n<tr>\n<th>Pasarela<\/th>\n<th>Fallo t\u00edpico<\/th>\n<th>Punto cr\u00edtico<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Redsys<\/td>\n<td>Error de firma, pedido pendiente, Bizum no visible.<\/td>\n<td>Clave secreta, FUC, terminal, moneda, URL de notificaci\u00f3n.<\/td>\n<\/tr>\n<tr>\n<td>PayPal<\/td>\n<td>Bot\u00f3n no carga, pago cancelado, IPN no confirma.<\/td>\n<td>Credenciales, moneda, cuenta verificada, scripts, IPN\/webhook.<\/td>\n<\/tr>\n<tr>\n<td>Stripe<\/td>\n<td>3D Secure falla, webhook no valida, pago no actualiza pedido.<\/td>\n<td>Payment Intents, claves, secreto de webhook, compatibilidad SCA.<\/td>\n<\/tr>\n<tr>\n<td>Mercado Pago<\/td>\n<td>Redirecci\u00f3n incorrecta, pago aprobado sin pedido actualizado.<\/td>\n<td>Credenciales, notificaciones, pa\u00eds, modo producci\u00f3n\/pruebas.<\/td>\n<\/tr>\n<tr>\n<td>Adyen \/ Klarna<\/td>\n<td>M\u00e9todo no aparece, pago queda pendiente.<\/td>\n<td>Configuraci\u00f3n de merchant, pa\u00edses, monedas, captura y webhooks.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/section>\n<section id=\"seguridad\">\n<h2>Seguridad, PSD2 y cumplimiento: vender no justifica bajar la guardia \ud83d\udee1\ufe0f<\/h2>\n<p>Cuando el pago falla, alguien siempre propone una soluci\u00f3n peligrosa: \u201cdesactiva eso de seguridad a ver si funciona\u201d. La frase parece inocente, pero tiene la elegancia t\u00e9cnica de apagar la alarma de incendios porque hace ruido. En pagos online, la seguridad no es un adorno; es el suelo.<\/p>\n<h3>PCI DSS y datos de tarjeta<\/h3>\n<p>La norma PCI DSS regula el tratamiento de datos de tarjetas. En la pr\u00e1ctica, la mayor\u00eda de tiendas PrestaShop deber\u00edan 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.<\/p>\n<p>Buenas pr\u00e1cticas:<\/p>\n<ul>\n<li>No guardes n\u00fameros de tarjeta, CVV ni datos sensibles en logs.<\/li>\n<li>Usa m\u00f3dulos oficiales o mantenidos por proveedores confiables.<\/li>\n<li>Mant\u00e9n PrestaShop, m\u00f3dulos y servidor actualizados.<\/li>\n<li>Restringe accesos al Back Office con contrase\u00f1as fuertes y doble factor si est\u00e1 disponible.<\/li>\n<li>Audita permisos de archivos y carpetas.<\/li>\n<li>Elimina m\u00f3dulos antiguos no usados.<\/li>\n<\/ul>\n<h3>PSD2, SCA y 3D Secure<\/h3>\n<p>En el Espacio Econ\u00f3mico Europeo, la PSD2 impuls\u00f3 la autenticaci\u00f3n reforzada del cliente, conocida como SCA. En t\u00e9rminos pr\u00e1cticos: muchos pagos requieren validaci\u00f3n adicional mediante 3D Secure u otros mecanismos. Los m\u00f3dulos antiguos que no implementan correctamente estos flujos pueden provocar rechazos o estados incompletos.<\/p>\n<p>Si tienes clientes europeos, revisa que tu m\u00f3dulo soporte:<\/p>\n<ul>\n<li>3D Secure 2.<\/li>\n<li>Autenticaci\u00f3n din\u00e1mica cuando el banco la exige.<\/li>\n<li>Pagos con autorizaci\u00f3n y captura, si tu operativa lo requiere.<\/li>\n<li>Exenciones SCA correctamente gestionadas por el proveedor, no improvisadas desde la tienda.<\/li>\n<\/ul>\n<h3>CSP, cookies y scripts de pago<\/h3>\n<p>Las pol\u00edticas 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\u00farate de no bloquear componentes imprescindibles para procesar el pago cuando la base legal o la clasificaci\u00f3n t\u00e9cnica lo permita.<\/p>\n<\/section>\n<section>\n<h2>Cach\u00e9, rendimiento y optimizaci\u00f3n: cuando acelerar rompe el motor \ud83d\ude80<\/h2>\n<p>PrestaShop incluye cach\u00e9 de Smarty, CCC para combinar, comprimir y cachear CSS\/JavaScript, y puede convivir con cach\u00e9s del servidor, CDN, Redis, Memcached, LiteSpeed Cache, Varnish o Cloudflare. Todo esto puede mejorar el rendimiento. Tambi\u00e9n puede conservar una versi\u00f3n antigua del checkout como un insecto atrapado en \u00e1mbar.<\/p>\n<h3>Qu\u00e9 limpiar despu\u00e9s de tocar una pasarela<\/h3>\n<ul>\n<li>Cach\u00e9 de PrestaShop.<\/li>\n<li>Cach\u00e9 de Smarty.<\/li>\n<li>Cach\u00e9 del navegador durante pruebas.<\/li>\n<li>Cach\u00e9 de CDN o proxy.<\/li>\n<li>OPcache de PHP si hay cambios de c\u00f3digo.<\/li>\n<li>Cach\u00e9 del m\u00f3dulo de optimizaci\u00f3n.<\/li>\n<\/ul>\n<p>Si usas Cloudflare u otro CDN, evita cachear p\u00e1ginas din\u00e1micas del checkout, carrito, cuenta de cliente, m\u00f3dulos de pago y endpoints de webhook. Un checkout cacheado es una contradicci\u00f3n peligrosa: pretende ser personal y se comporta como fotocopia.<\/p>\n<p><strong>Regla pr\u00e1ctica:<\/strong> nunca optimices a ciegas el checkout. Excluye de minificaci\u00f3n o diferido los scripts cr\u00edticos de la pasarela cuando el proveedor lo recomiende. La velocidad importa, claro. Pero una p\u00e1gina de pago ultrarr\u00e1pida que no cobra es solo una p\u00e1gina muy eficiente en fracasar.<\/p>\n<\/section>\n<section>\n<h2>Multi-tienda, idiomas y dominios: el laberinto elegante de PrestaShop \ud83e\udde9<\/h2>\n<p>PrestaShop multitienda permite gestionar varios escaparates desde una misma instalaci\u00f3n. Es potente. Tambi\u00e9n a\u00f1ade capas de complejidad que pueden afectar a pasarelas de pago. Un m\u00f3dulo 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.<\/p>\n<h3>Revisiones en entornos multitienda<\/h3>\n<ul>\n<li>Selecciona el contexto correcto en el Back Office antes de configurar el m\u00f3dulo.<\/li>\n<li>Comprueba credenciales por tienda si cada dominio usa una cuenta de comercio distinta.<\/li>\n<li>Revisa URLs de webhook por dominio.<\/li>\n<li>Confirma moneda, pa\u00eds y transportista en cada tienda.<\/li>\n<li>Verifica certificados SSL para todos los dominios.<\/li>\n<li>Aseg\u00farate de que el proveedor permite el dominio usado en producci\u00f3n.<\/li>\n<\/ul>\n<p>En tiendas multiling\u00fces, revisa tambi\u00e9n URLs amigables y redirecciones por idioma. Algunos m\u00f3dulos generan URLs de retorno que pueden verse afectadas por reglas de reescritura o configuraciones de idioma en la ruta.<\/p>\n<\/section>\n<section>\n<h2>Procedimiento profesional para corregir el problema sin romper la tienda \ud83d\udee0\ufe0f<\/h2>\n<p>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\u00e9todo.<\/p>\n<h3>Plan recomendado<\/h3>\n<ol>\n<li><strong>Haz copia de seguridad completa:<\/strong> archivos y base de datos. Verifica que puedes restaurarla.<\/li>\n<li><strong>Clona la tienda en staging:<\/strong> reproduce ah\u00ed el fallo antes de tocar producci\u00f3n.<\/li>\n<li><strong>Documenta el entorno:<\/strong> versi\u00f3n PrestaShop, PHP, MySQL\/MariaDB, m\u00f3dulo, tema, servidor.<\/li>\n<li><strong>Revisa logs:<\/strong> PrestaShop, PHP, servidor, proveedor de pago.<\/li>\n<li><strong>Prueba con configuraci\u00f3n m\u00ednima:<\/strong> tema cl\u00e1sico, cach\u00e9 desactivada, m\u00f3dulos no esenciales fuera.<\/li>\n<li><strong>Actualiza de forma escalonada:<\/strong> primero m\u00f3dulo, luego dependencias, luego PHP o n\u00facleo si procede.<\/li>\n<li><strong>Valida en sandbox:<\/strong> usa tarjetas de prueba y escenarios de \u00e9xito, rechazo y 3D Secure.<\/li>\n<li><strong>Prueba en producci\u00f3n con importe bajo:<\/strong> confirma creaci\u00f3n de pedido, cobro, factura, email y estado.<\/li>\n<li><strong>Monitorea las primeras horas:<\/strong> revisa webhooks, errores y pedidos reales.<\/li>\n<\/ol>\n<h3>Tarjetas y escenarios de prueba<\/h3>\n<p>Muchos proveedores ofrecen tarjetas de prueba para simular pagos aprobados, rechazados, autenticaci\u00f3n 3D Secure, fondos insuficientes o errores. \u00dasalas. No basta con probar \u201cun pago correcto\u201d; hay que probar tambi\u00e9n el tropiezo. Un sistema que solo ha ensayado la felicidad se descompone en cuanto aparece la vida real.<\/p>\n<p>Escenarios m\u00ednimos:<\/p>\n<ul>\n<li>Pago aprobado.<\/li>\n<li>Pago rechazado.<\/li>\n<li>Pago con 3D Secure aprobado.<\/li>\n<li>3D Secure abandonado por el cliente.<\/li>\n<li>Pago pendiente o en revisi\u00f3n.<\/li>\n<li>Reembolso parcial y total.<\/li>\n<li>Cancelaci\u00f3n antes de volver a la tienda.<\/li>\n<li>Pedido con cup\u00f3n, env\u00edo gratuito y moneda alternativa.<\/li>\n<\/ul>\n<\/section>\n<section>\n<h2>Errores de configuraci\u00f3n que conviene mirar dos veces \ud83d\udc40<\/h2>\n<p>En soporte t\u00e9cnico 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\u00f3n. La \u00e9pica del comercio digital, derrotada por un car\u00e1cter invisible.<\/p>\n<table>\n<thead>\n<tr>\n<th>Configuraci\u00f3n<\/th>\n<th>Error com\u00fan<\/th>\n<th>C\u00f3mo verificar<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Credenciales API<\/td>\n<td>Claves de prueba en entorno real o viceversa.<\/td>\n<td>Comparar con el panel del proveedor y regenerar si hay duda.<\/td>\n<\/tr>\n<tr>\n<td>URL de retorno<\/td>\n<td>Dominio antiguo, HTTP, ruta incorrecta.<\/td>\n<td>Probar acceso p\u00fablico y revisar documentaci\u00f3n del m\u00f3dulo.<\/td>\n<\/tr>\n<tr>\n<td>Moneda<\/td>\n<td>Moneda activa en PrestaShop pero no aceptada por la pasarela.<\/td>\n<td>Consultar moneda del comercio en el proveedor.<\/td>\n<\/tr>\n<tr>\n<td>Pa\u00eds<\/td>\n<td>M\u00e9todo restringido para la direcci\u00f3n del cliente.<\/td>\n<td>Revisar restricciones en Pago &gt; Preferencias.<\/td>\n<\/tr>\n<tr>\n<td>Estado de pedido<\/td>\n<td>Pago aceptado mapeado a estado incorrecto.<\/td>\n<td>Revisar configuraci\u00f3n del m\u00f3dulo y estados personalizados.<\/td>\n<\/tr>\n<tr>\n<td>Permisos<\/td>\n<td>Archivos del m\u00f3dulo sin permisos adecuados.<\/td>\n<td>Comprobar permisos y propietario en servidor.<\/td>\n<\/tr>\n<tr>\n<td>Cach\u00e9<\/td>\n<td>Plantillas antiguas o scripts desactualizados.<\/td>\n<td>Limpiar cach\u00e9 de PrestaShop, CDN y navegador.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/section>\n<section>\n<h2>Cu\u00e1ndo contactar al proveedor, al hosting o a un desarrollador<\/h2>\n<p>No todo debe resolverse desde el Back Office. Saber a qui\u00e9n preguntar ahorra tiempo y evita respuestas circulares, esa danza triste donde el hosting culpa al m\u00f3dulo, el m\u00f3dulo culpa al proveedor y el proveedor culpa a la tienda con la serenidad de quien nunca ha visto tu instalaci\u00f3n.<\/p>\n<h3>Contacta al proveedor de pago si&#8230;<\/h3>\n<ul>\n<li>El panel muestra rechazos bancarios o errores de comercio.<\/li>\n<li>Las credenciales parecen inv\u00e1lidas aunque est\u00e9n bien copiadas.<\/li>\n<li>El m\u00e9todo de pago local no est\u00e1 habilitado.<\/li>\n<li>Hay dudas sobre 3D Secure, SCA, l\u00edmites o revisi\u00f3n antifraude.<\/li>\n<li>Los webhooks no se env\u00edan o se env\u00edan con errores documentados.<\/li>\n<\/ul>\n<h3>Contacta al hosting si&#8230;<\/h3>\n<ul>\n<li>Hay errores cURL, SSL, DNS o timeout.<\/li>\n<li>El firewall bloquea notificaciones.<\/li>\n<li>PHP, OpenSSL o extensiones est\u00e1n desactualizadas.<\/li>\n<li>El servidor registra errores 500 o falta de memoria.<\/li>\n<li>Necesitas revisar logs a los que no tienes acceso.<\/li>\n<\/ul>\n<h3>Contacta a un desarrollador PrestaShop si&#8230;<\/h3>\n<ul>\n<li>El problema aparece tras una actualizaci\u00f3n.<\/li>\n<li>Hay overrides personalizados.<\/li>\n<li>El tema modifica el checkout.<\/li>\n<li>Hay conflictos entre m\u00f3dulos.<\/li>\n<li>Necesitas adaptar una pasarela a un flujo especial de negocio.<\/li>\n<\/ul>\n<p><strong>Informaci\u00f3n que debes enviar para recibir ayuda \u00fatil:<\/strong><\/p>\n<ul>\n<li>Versi\u00f3n exacta de PrestaShop.<\/li>\n<li>Versi\u00f3n de PHP y tipo de servidor.<\/li>\n<li>Nombre y versi\u00f3n del m\u00f3dulo de pago.<\/li>\n<li>Pasos exactos para reproducir el fallo.<\/li>\n<li>Capturas de pantalla sin datos sensibles.<\/li>\n<li>Fragmentos de logs relevantes.<\/li>\n<li>Hora y zona horaria de una prueba fallida.<\/li>\n<li>ID de transacci\u00f3n o evento en el proveedor, si existe.<\/li>\n<\/ul>\n<\/section>\n<section id=\"checklist\">\n<h2>Checklist profesional para solucionar problemas de pasarelas de pago en PrestaShop \u2705<\/h2>\n<p>Si necesitas una ruta breve \u2014no superficial, breve\u2014 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.<\/p>\n<h3>Diagn\u00f3stico inicial<\/h3>\n<ul>\n<li>Confirmar si el error afecta a todos los clientes o solo a algunos.<\/li>\n<li>Probar con diferentes navegadores y dispositivos.<\/li>\n<li>Revisar si el m\u00e9todo de pago aparece seg\u00fan pa\u00eds, moneda y transportista.<\/li>\n<li>Identificar si el proveedor registra el intento de pago.<\/li>\n<li>Anotar hora exacta y pasos de reproducci\u00f3n.<\/li>\n<\/ul>\n<h3>Compatibilidad<\/h3>\n<ul>\n<li>Verificar versi\u00f3n exacta de PrestaShop.<\/li>\n<li>Verificar versi\u00f3n PHP compatible.<\/li>\n<li>Actualizar el m\u00f3dulo de pago a una versi\u00f3n compatible.<\/li>\n<li>Revisar changelog del m\u00f3dulo y documentaci\u00f3n del proveedor.<\/li>\n<li>Comprobar compatibilidad con tema y m\u00f3dulos de checkout.<\/li>\n<\/ul>\n<h3>Configuraci\u00f3n<\/h3>\n<ul>\n<li>Revisar credenciales API, claves secretas y modo sandbox\/producci\u00f3n.<\/li>\n<li>Confirmar URLs de retorno, cancelaci\u00f3n y webhook.<\/li>\n<li>Comprobar restricciones por moneda, pa\u00eds, grupo y transportista.<\/li>\n<li>Validar estados de pedido asociados al pago.<\/li>\n<li>Confirmar que el comercio est\u00e1 activo y verificado en la pasarela.<\/li>\n<\/ul>\n<h3>Servidor y seguridad<\/h3>\n<ul>\n<li>SSL v\u00e1lido y HTTPS forzado correctamente.<\/li>\n<li>cURL y OpenSSL activos y actualizados.<\/li>\n<li>TLS 1.2 o superior disponible.<\/li>\n<li>Firewall\/WAF sin bloqueo de callbacks.<\/li>\n<li>Logs revisados sin exposici\u00f3n de datos sensibles.<\/li>\n<\/ul>\n<h3>Pruebas finales<\/h3>\n<ul>\n<li>Limpiar cach\u00e9 de PrestaShop, CDN y navegador.<\/li>\n<li>Probar pago aprobado y rechazado.<\/li>\n<li>Probar 3D Secure si aplica.<\/li>\n<li>Confirmar actualizaci\u00f3n de estado del pedido.<\/li>\n<li>Verificar emails, factura, stock y back office.<\/li>\n<\/ul>\n<\/section>\n<section>\n<h2>Buenas pr\u00e1cticas para que el problema no vuelva cada temporada \ud83c\udf31<\/h2>\n<p>La estabilidad de pagos no se consigue con una intervenci\u00f3n heroica al a\u00f1o. Se consigue con mantenimiento. Menos \u00e9pica, m\u00e1s calendario. Menos apagar incendios, m\u00e1s revisar cables antes de que huelan a quemado.<\/p>\n<ul>\n<li><strong>Mant\u00e9n un entorno de pruebas permanente:<\/strong> no uses producci\u00f3n como laboratorio.<\/li>\n<li><strong>Planifica actualizaciones:<\/strong> PrestaShop, m\u00f3dulos, tema y PHP deben evolucionar con orden.<\/li>\n<li><strong>Monitoriza pagos fallidos:<\/strong> revisa tendencias, no solo incidencias aisladas.<\/li>\n<li><strong>Documenta configuraci\u00f3n cr\u00edtica:<\/strong> credenciales, endpoints, estados de pedido, restricciones.<\/li>\n<li><strong>Haz pruebas peri\u00f3dicas:<\/strong> especialmente despu\u00e9s de cambios en checkout, servidor o pasarela.<\/li>\n<li><strong>Evita m\u00f3dulos abandonados:<\/strong> un m\u00f3dulo de pago sin mantenimiento es una promesa vencida.<\/li>\n<li><strong>Revisa la seguridad:<\/strong> accesos, permisos, SSL, logs y cumplimiento.<\/li>\n<li><strong>Conserva m\u00e9todos alternativos:<\/strong> transferencia, contra reembolso, PayPal, tarjeta u otro m\u00e9todo seg\u00fan negocio. Un \u00fanico punto de fallo es c\u00f3modo hasta que falla.<\/li>\n<\/ul>\n<p>Tambi\u00e9n conviene medir el impacto real. Si muchos usuarios abandonan en el paso de pago, no siempre se trata de compatibilidad t\u00e9cnica: puede haber falta de confianza, costes sorpresa, formularios largos, m\u00e9todos insuficientes o errores de usabilidad. La pasarela debe funcionar, s\u00ed; pero el checkout tambi\u00e9n debe persuadir sin empujar, informar sin cansar, pedir datos sin parecer interrogatorio.<\/p>\n<\/section>\n<section>\n<h2>Una mirada final: cobrar es t\u00e9cnico, pero tambi\u00e9n es confianza<\/h2>\n<p>Solucionar problemas de compatibilidad con pasarelas de pago en PrestaShop no es \u00fanicamente reparar un m\u00f3dulo. Es proteger el momento m\u00e1s fr\u00e1gil de una tienda online: aquel en el que el visitante deja de mirar y decide confiar. Todo lo anterior \u2014SEO, campa\u00f1as, dise\u00f1o, fichas de producto, velocidad, fotograf\u00edas\u2014 desemboca ah\u00ed, en un bot\u00f3n de pago que debe responder con la naturalidad de una llave bien tallada.<\/p>\n<p>La buena noticia es que casi todos estos problemas tienen m\u00e9todo. Versiones compatibles, logs claros, SSL correcto, webhooks accesibles, checkout limpio, configuraci\u00f3n coherente y pruebas reales. No hay magia. Hay oficio. Y en el comercio electr\u00f3nico, el oficio se nota precisamente cuando nada interrumpe al cliente.<\/p>\n<p>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\u00e1s elegantes de la tecnolog\u00eda bien hecha. \ud83d\udcbc\u2728<\/p>\n<\/section>\n<\/article>\n","protected":false},"excerpt":{"rendered":"<p>\u00bfC\u00f3mo solucionar problemas de compatibilidad con pasarelas de pago en PrestaShop? \ud83d\uded2\ud83d\udcb3 Hay pocas escenas<\/p>\n","protected":false},"author":1,"featured_media":3711,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_seopress_titles_title":"","_seopress_titles_desc":"","_seopress_robots_index":"","_seopress_robots_follow":"","_seopress_robots_imageindex":"","_seopress_robots_snippet":"","_seopress_robots_primary_cat":"","_seopress_robots_breadcrumbs":"","_seopress_robots_freeze_modified_date":"","_seopress_robots_custom_modified_date":"","_seopress_robots_canonical":"","_seopress_social_fb_title":"","_seopress_social_fb_desc":"","_seopress_social_fb_img":"","_seopress_social_fb_img_attachment_id":0,"_seopress_social_fb_img_width":0,"_seopress_social_fb_img_height":0,"_seopress_social_twitter_title":"","_seopress_social_twitter_desc":"","_seopress_social_twitter_img":"","_seopress_social_twitter_img_attachment_id":0,"_seopress_social_twitter_img_width":0,"_seopress_social_twitter_img_height":0,"_seopress_redirections_value":"","_seopress_redirections_enabled":"","_seopress_redirections_enabled_regex":"","_seopress_redirections_logged_status":"","_seopress_redirections_param":"","_seopress_redirections_type":0,"_seopress_analysis_target_kw":"","_seopress_news_disabled":"","_seopress_video_disabled":"","_seopress_video":[],"_seopress_pro_schemas_manual":[],"_seopress_pro_rich_snippets_disable_all":"","_seopress_pro_rich_snippets_disable":[],"_seopress_pro_schemas":[],"footnotes":""},"categories":[2],"tags":[],"class_list":["post-3712","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-mantenimiento"],"_links":{"self":[{"href":"https:\/\/mantenimientoweb.pro\/blog\/wp-json\/wp\/v2\/posts\/3712","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/mantenimientoweb.pro\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mantenimientoweb.pro\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/mantenimientoweb.pro\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/mantenimientoweb.pro\/blog\/wp-json\/wp\/v2\/comments?post=3712"}],"version-history":[{"count":1,"href":"https:\/\/mantenimientoweb.pro\/blog\/wp-json\/wp\/v2\/posts\/3712\/revisions"}],"predecessor-version":[{"id":3713,"href":"https:\/\/mantenimientoweb.pro\/blog\/wp-json\/wp\/v2\/posts\/3712\/revisions\/3713"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/mantenimientoweb.pro\/blog\/wp-json\/wp\/v2\/media\/3711"}],"wp:attachment":[{"href":"https:\/\/mantenimientoweb.pro\/blog\/wp-json\/wp\/v2\/media?parent=3712"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mantenimientoweb.pro\/blog\/wp-json\/wp\/v2\/categories?post=3712"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mantenimientoweb.pro\/blog\/wp-json\/wp\/v2\/tags?post=3712"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}