{"id":3839,"date":"2026-09-18T11:42:33","date_gmt":"2026-09-18T09:42:33","guid":{"rendered":"https:\/\/mantenimientoweb.pro\/blog\/como-solucionar-problemas-de-compatibilidad-con-pasarelas-de-pago-en-prestashop-2\/"},"modified":"2026-09-18T11:42:35","modified_gmt":"2026-09-18T09:42:35","slug":"como-solucionar-problemas-de-compatibilidad-con-pasarelas-de-pago-en-prestashop-2","status":"publish","type":"post","link":"https:\/\/mantenimientoweb.pro\/blog\/como-solucionar-problemas-de-compatibilidad-con-pasarelas-de-pago-en-prestashop-2\/","title":{"rendered":"\u00bfC\u00f3mo solucionar problemas de compatibilidad con pasarelas de pago en PrestaShop?"},"content":{"rendered":"<article>\n  \u00bfC\u00f3mo solucionar problemas de compatibilidad con pasarelas de pago en PrestaShop? \ud83d\uded2\ud83d\udcb3<\/p>\n<p>Hay pocas escenas tan crueles en una tienda online como esta: el cliente ha elegido el producto, ha aceptado el precio, ha confiado en la marca, ha llegado al \u00faltimo clic\u2026 y la pasarela de pago decide comportarse como una puerta autom\u00e1tica que se abre hacia la pared. El carrito lleno; la venta, vac\u00eda. Todo muy moderno, naturalmente.<\/p>\n<p>Los problemas de compatibilidad con pasarelas de pago en PrestaShop no suelen aparecer con trompetas. Llegan como una humedad detr\u00e1s del armario: un pedido que no se crea, un pago capturado pero sin confirmaci\u00f3n, un bot\u00f3n de PayPal que desaparece, Stripe que devuelve un error indescifrable, Redsys que redirige al usuario a ninguna parte, Mercado Pago que funciona en pruebas pero se desmaya en producci\u00f3n. Y mientras tanto, la tienda parece estar bien. Esa es la parte divertida, si uno tiene un sentido del humor suficientemente resistente.<\/p>\n<p>Esta gu\u00eda est\u00e1 pensada para propietarios de tiendas, desarrolladores, agencias y responsables t\u00e9cnicos que necesitan diagnosticar y resolver incidencias reales en m\u00f3dulos de pago para PrestaShop. No se trata de agitar incienso sobre el Back Office, sino de seguir un m\u00e9todo: versiones, registros, servidor, webhooks, tema, checkout, cach\u00e9, SSL, monedas, estados de pedido y m\u00f3dulos. Un mapa completo para encontrar el fallo antes de que el fallo encuentre la facturaci\u00f3n.<\/p>\n<h2>Mapa r\u00e1pido de la gu\u00eda \ud83e\udded<\/h2>\n<ul>\n<li><a href=\"#por-que-fallan\">Por qu\u00e9 fallan las pasarelas de pago en PrestaShop<\/a><\/li>\n<li><a href=\"#sintomas\">S\u00edntomas comunes y qu\u00e9 significan<\/a><\/li>\n<li><a href=\"#diagnostico\">M\u00e9todo profesional de diagn\u00f3stico<\/a><\/li>\n<li><a href=\"#versiones\">Compatibilidad entre PrestaShop, PHP y m\u00f3dulos<\/a><\/li>\n<li><a href=\"#ssl\">SSL, TLS, cURL y certificados<\/a><\/li>\n<li><a href=\"#webhooks\">Webhooks, notificaciones y estados de pedido<\/a><\/li>\n<li><a href=\"#tema-checkout\">Tema, checkout y conflictos visuales<\/a><\/li>\n<li><a href=\"#cache\">Cach\u00e9, overrides y m\u00f3dulos incompatibles<\/a><\/li>\n<li><a href=\"#pasarelas\">Casos habituales: Stripe, PayPal, Redsys y Mercado Pago<\/a><\/li>\n<li><a href=\"#checklist\">Checklist final de resoluci\u00f3n<\/a><\/li>\n<\/ul>\n<h2 id=\"por-que-fallan\">Por qu\u00e9 fallan las pasarelas de pago en PrestaShop \u2699\ufe0f<\/h2>\n<p>Una pasarela de pago no es simplemente un bot\u00f3n bonito que dice \u201cPagar\u201d. Es una conversaci\u00f3n delicada entre muchos actores: PrestaShop, el m\u00f3dulo de pago, el servidor, el banco adquirente, el navegador del cliente, el certificado SSL, las reglas de seguridad del hosting, la moneda, el pa\u00eds, el tema, el sistema de cach\u00e9 y, por supuesto, las APIs externas que tienen la mala costumbre de evolucionar.<\/p>\n<p>La tienda quiere vender; el sistema quiere validar; el banco quiere reducir fraude; el navegador quiere bloquear contenido inseguro; el cliente quiere terminar r\u00e1pido. Una peque\u00f1a rep\u00fablica de intereses contradictorios. Antiguamente se entregaba una moneda sobre un mostrador. Ahora intervienen tokens, firmas HMAC, endpoints, callbacks, redirecciones, SCA, 3D Secure y webhooks. Progreso, lo llaman. Y s\u00ed, lo es, aunque a veces tenga la elegancia de una mudanza bajo la lluvia.<\/p>\n<p>En PrestaShop, los problemas de compatibilidad suelen concentrarse en estos frentes:<\/p>\n<ul>\n<li><strong>Versi\u00f3n de PrestaShop incompatible<\/strong> con el m\u00f3dulo de pago instalado.<\/li>\n<li><strong>Versi\u00f3n de PHP no soportada<\/strong> por la tienda o por el m\u00f3dulo.<\/li>\n<li><strong>Dependencias del servidor ausentes o antiguas<\/strong>: cURL, OpenSSL, extensiones PHP, TLS 1.2 o superior.<\/li>\n<li><strong>Credenciales mal configuradas<\/strong>: claves de prueba en producci\u00f3n, secretos de webhook incorrectos, terminal bancario equivocado.<\/li>\n<li><strong>Errores en webhooks o notificaciones<\/strong>, que impiden que PrestaShop confirme el pedido.<\/li>\n<li><strong>Conflictos con el tema o el checkout<\/strong>, especialmente en plantillas muy personalizadas.<\/li>\n<li><strong>M\u00f3dulos de cach\u00e9, optimizaci\u00f3n o seguridad<\/strong> que bloquean scripts, redirecciones o endpoints.<\/li>\n<li><strong>Problemas de moneda, pa\u00eds, impuestos o transportistas<\/strong> que hacen que la pasarela no se muestre.<\/li>\n<li><strong>Reglas del firewall, ModSecurity o WAF<\/strong> que interpretan una notificaci\u00f3n leg\u00edtima como si fuera un vikingo digital entrando por la ventana.<\/li>\n<\/ul>\n<p><strong>Idea clave:<\/strong> cuando una pasarela de pago no funciona en PrestaShop, rara vez hay un \u00fanico culpable. El fallo suele vivir en una frontera: entre el m\u00f3dulo y PHP, entre la tienda y el banco, entre el tema y el checkout, entre el servidor y una API externa.<\/p>\n<h2 id=\"sintomas\">S\u00edntomas comunes y qu\u00e9 significan \ud83d\udd0d<\/h2>\n<p>Antes de tocar configuraciones conviene observar. Un buen diagn\u00f3stico empieza con la paciencia del relojero: mirar qu\u00e9 pieza no gira, cu\u00e1ndo se detiene y qu\u00e9 ruido hace antes de fallar.<\/p>\n<table>\n<thead>\n<tr>\n<th>S\u00edntoma<\/th>\n<th>Posibles causas<\/th>\n<th>Primeras acciones<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>La pasarela de pago no aparece en el checkout<\/td>\n<td>Restricciones por pa\u00eds, moneda, grupo de clientes, transportista, tema incompatible, m\u00f3dulo desactivado o hook no registrado.<\/td>\n<td>Revisar configuraci\u00f3n del m\u00f3dulo, posiciones en hooks, restricciones en <strong>Pago &gt; M\u00e9todos de pago<\/strong> y probar con el tema Classic.<\/td>\n<\/tr>\n<tr>\n<td>El cliente paga, pero el pedido no se crea<\/td>\n<td>Webhook no recibido, URL de notificaci\u00f3n bloqueada, error en <code>validateOrder<\/code>, estado de pedido mal asignado.<\/td>\n<td>Revisar logs de PrestaShop, logs del m\u00f3dulo y panel de la pasarela. Verificar que la URL de callback sea accesible.<\/td>\n<\/tr>\n<tr>\n<td>Error 500 al volver de la pasarela<\/td>\n<td>Incompatibilidad PHP, excepci\u00f3n en m\u00f3dulo, override conflictivo, permisos, memoria insuficiente.<\/td>\n<td>Activar modo depuraci\u00f3n en entorno de pruebas y consultar <code>var\/logs<\/code> o logs del servidor.<\/td>\n<\/tr>\n<tr>\n<td>Pago duplicado o pedido duplicado<\/td>\n<td>Webhook procesado m\u00e1s de una vez, m\u00f3dulo no idempotente, reintentos de la pasarela, cliente recargando la p\u00e1gina.<\/td>\n<td>Actualizar m\u00f3dulo, revisar gesti\u00f3n de transacciones y comprobar si el m\u00f3dulo valida el ID de pago antes de crear pedido.<\/td>\n<\/tr>\n<tr>\n<td>Redirecci\u00f3n en bucle o pantalla en blanco<\/td>\n<td>Problemas de sesi\u00f3n, cookies, SSL, cach\u00e9 agresiva, reglas de seguridad o dominio can\u00f3nico mal configurado.<\/td>\n<td>Verificar SSL, dominio principal, configuraci\u00f3n de cookies, cach\u00e9 y errores del navegador.<\/td>\n<\/tr>\n<tr>\n<td>El bot\u00f3n de pago se ve roto o no responde<\/td>\n<td>JavaScript bloqueado, conflicto con tema, minificaci\u00f3n, m\u00f3dulo de optimizaci\u00f3n, Content Security Policy.<\/td>\n<td>Inspeccionar consola del navegador, desactivar minificaci\u00f3n temporalmente y probar sin m\u00f3dulos de optimizaci\u00f3n.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>Una vez, en una tienda de alimentaci\u00f3n gourmet, el problema no era Stripe, ni el servidor, ni PrestaShop. Era un m\u00f3dulo de \u201cefectos navide\u00f1os\u201d que insertaba copos de nieve por JavaScript y romp\u00eda el formulario de tarjeta. La Navidad, ese esp\u00edritu de paz capaz de tumbar una conversi\u00f3n del 3,8 %. Lo cuento porque en comercio electr\u00f3nico lo ornamental a veces devora lo esencial.<\/p>\n<h2 id=\"diagnostico\">M\u00e9todo profesional de diagn\u00f3stico paso a paso \ud83e\uddea<\/h2>\n<p>La peor manera de solucionar un problema de pagos es cambiar cinco cosas a la vez. Es r\u00e1pido, s\u00ed; tambi\u00e9n lo es apagar un incendio con gasolina si uno solo mide la velocidad del gesto. El objetivo es aislar variables.<\/p>\n<h3>1. Reproducir el problema con precisi\u00f3n<\/h3>\n<p>Documenta el fallo como si fueras a entreg\u00e1rselo a alguien que no conoce la tienda:<\/p>\n<ul>\n<li>Versi\u00f3n exacta de PrestaShop.<\/li>\n<li>Versi\u00f3n del m\u00f3dulo de pago.<\/li>\n<li>Versi\u00f3n de PHP y motor del servidor web: Apache, Nginx, LiteSpeed.<\/li>\n<li>Pasarela afectada: Stripe, PayPal, Redsys, Paycomet, Adyen, Mercado Pago, etc.<\/li>\n<li>Pa\u00eds, moneda, idioma, transportista y grupo de cliente usado en la prueba.<\/li>\n<li>Dispositivo y navegador.<\/li>\n<li>Mensaje de error visible, si existe.<\/li>\n<li>Momento exacto del fallo: antes de pagar, durante la redirecci\u00f3n, al volver, al confirmar pedido.<\/li>\n<\/ul>\n<p>Esta informaci\u00f3n parece b\u00e1sica, pero evita horas de conjeturas. \u201cNo funciona\u201d es una queja humana; \u201cfalla al recibir el webhook despu\u00e9s de un pago autorizado con EUR y transportista X\u201d ya es una pista t\u00e9cnica.<\/p>\n<h3>2. Crear una copia de seguridad y un entorno de pruebas<\/h3>\n<p>Antes de modificar m\u00f3dulos de pago en PrestaShop, realiza una copia completa de archivos y base de datos. Si es posible, replica la tienda en staging. El entorno de producci\u00f3n no es un laboratorio; es la caja registradora. Confundir ambos lugares es una forma moderna de poes\u00eda tr\u00e1gica.<\/p>\n<ul>\n<li>Exporta la base de datos.<\/li>\n<li>Copia archivos, especialmente <code>\/modules<\/code>, <code>\/override<\/code>, <code>\/themes<\/code> y <code>\/app\/config<\/code> o configuraciones equivalentes seg\u00fan versi\u00f3n.<\/li>\n<li>Desactiva indexaci\u00f3n del entorno de pruebas.<\/li>\n<li>Usa credenciales sandbox de la pasarela.<\/li>\n<li>No reutilices webhooks de producci\u00f3n en pruebas.<\/li>\n<\/ul>\n<h3>3. Activar depuraci\u00f3n solo donde corresponde<\/h3>\n<p>En PrestaShop puedes activar el modo debug desde el Back Office, si la tienda lo permite, o mediante configuraci\u00f3n de entorno seg\u00fan versi\u00f3n. En PrestaShop 1.7 y 8, muchos registros se encuentran bajo <code>var\/logs\/<\/code>, adem\u00e1s de los registros visibles en <strong>Par\u00e1metros avanzados &gt; Registros<\/strong>. Tambi\u00e9n debes revisar el log de PHP, el error log del servidor y el panel de la pasarela.<\/p>\n<p><strong>Precauci\u00f3n:<\/strong> no mantengas el modo debug activo en producci\u00f3n. Puede exponer rutas internas, datos t\u00e9cnicos y mensajes sensibles. La depuraci\u00f3n ilumina, pero tambi\u00e9n desnuda.<\/p>\n<h3>4. Revisar los logs como quien lee huellas en barro<\/h3>\n<p>Los logs suelen ser menos elegantes que una interfaz gr\u00e1fica, pero dicen la verdad con una brutalidad admirable. Busca errores como:<\/p>\n<ul>\n<li><code>Fatal error<\/code>, <code>Uncaught Exception<\/code> o <code>TypeError<\/code>.<\/li>\n<li>Errores de conexi\u00f3n cURL.<\/li>\n<li>Errores SSL: certificado no v\u00e1lido, handshake fallido, TLS incompatible.<\/li>\n<li>Errores 403 o 406 causados por ModSecurity.<\/li>\n<li>Errores 500 al ejecutar la URL de notificaci\u00f3n.<\/li>\n<li>Mensajes del m\u00f3dulo relacionados con firma inv\u00e1lida, token caducado o credenciales err\u00f3neas.<\/li>\n<\/ul>\n<p>Conviene cruzar tres relojes: hora del pago en la pasarela, hora del intento en PrestaShop y hora registrada en el servidor. Si no coinciden por zona horaria o desajuste del sistema, el an\u00e1lisis puede parecer un crimen sin cad\u00e1ver.<\/p>\n<h2 id=\"versiones\">Compatibilidad entre PrestaShop, PHP y m\u00f3dulos de pago \ud83e\udde9<\/h2>\n<p>La compatibilidad es el punto donde las buenas intenciones se encuentran con la aritm\u00e9tica. Una tienda puede tener un m\u00f3dulo reciente sobre un PrestaShop antiguo, o un PrestaShop actualizado corriendo sobre un PHP que el m\u00f3dulo no esperaba. Viejo motor, carrocer\u00eda nueva; o al rev\u00e9s.<\/p>\n<p>PrestaShop 1.7 introdujo cambios importantes frente a 1.6, especialmente en arquitectura y checkout. PrestaShop 8 contin\u00faa la transici\u00f3n hacia componentes modernos basados en Symfony, aunque mantiene capas heredadas. Eso significa que muchos m\u00f3dulos conviven con dos mundos: el legado y lo moderno, la carreta y el tren el\u00e9ctrico compartiendo v\u00eda.<\/p>\n<p>Antes de culpar al banco, revisa esta matriz t\u00e9cnica:<\/p>\n<table>\n<thead>\n<tr>\n<th>Elemento<\/th>\n<th>Qu\u00e9 comprobar<\/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>Comprueba si el m\u00f3dulo declara compatibilidad con tu versi\u00f3n exacta.<\/td>\n<td>Los hooks, controladores, plantillas y clases internas pueden cambiar entre versiones.<\/td>\n<\/tr>\n<tr>\n<td>Versi\u00f3n de PHP<\/td>\n<td>Consulta la documentaci\u00f3n oficial de PrestaShop y del m\u00f3dulo. No asumas que \u201cm\u00e1s nuevo\u201d siempre es \u201cmejor\u201d.<\/td>\n<td>PHP 8 introdujo cambios estrictos que pueden romper m\u00f3dulos antiguos con errores de tipos, par\u00e1metros nulos o funciones obsoletas.<\/td>\n<\/tr>\n<tr>\n<td>Extensiones PHP<\/td>\n<td>Verifica <code>curl<\/code>, <code>openssl<\/code>, <code>json<\/code>, <code>mbstring<\/code>, <code>intl<\/code>, <code>zip<\/code> y otras requeridas por tu instalaci\u00f3n.<\/td>\n<td>Muchas APIs de pago dependen de comunicaci\u00f3n HTTPS y procesamiento JSON.<\/td>\n<\/tr>\n<tr>\n<td>M\u00f3dulo de pago<\/td>\n<td>Instala versiones oficiales desde PrestaShop Addons o repositorio del proveedor cuando exista.<\/td>\n<td>Los m\u00f3dulos no oficiales o abandonados suelen fallar con cambios de API y requisitos de seguridad.<\/td>\n<\/tr>\n<tr>\n<td>Tema<\/td>\n<td>Prueba temporalmente con el tema Classic o uno est\u00e1ndar compatible.<\/td>\n<td>Un checkout personalizado puede ocultar m\u00e9todos de pago o romper eventos JavaScript.<\/td>\n<\/tr>\n<tr>\n<td>Overrides<\/td>\n<td>Revisa <code>\/override<\/code> y desactiva temporalmente personalizaciones no esenciales.<\/td>\n<td>Un override antiguo de carrito, pedido o pago puede interferir con la validaci\u00f3n.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h3>Actualizaciones: ni fiebre ni abandono<\/h3>\n<p>Actualizar todo sin revisar compatibilidad es imprudente. No actualizar nada durante a\u00f1os tambi\u00e9n. La virtud est\u00e1 en una disciplina menos glamorosa: leer changelogs, probar en staging, hacer backup, medir y desplegar. Como podar un \u00e1rbol: cortar demasiado lo mata; no cortar nunca lo vuelve ingobernable.<\/p>\n<p>Cuando actualices un m\u00f3dulo de pasarela de pago en PrestaShop:<\/p>\n<ol>\n<li>Lee los requisitos de versi\u00f3n de PrestaShop y PHP.<\/li>\n<li>Revisa si la actualizaci\u00f3n cambia el sistema de webhooks o endpoints.<\/li>\n<li>Comprueba si debes regenerar claves API.<\/li>\n<li>Haz pruebas con pagos sandbox.<\/li>\n<li>Verifica estados de pedido y correos transaccionales.<\/li>\n<li>Revisa que no se hayan duplicado m\u00e9todos de pago antiguos.<\/li>\n<\/ol>\n<h2 id=\"ssl\">SSL, TLS, cURL y certificados: la fontaner\u00eda invisible \ud83d\udd10<\/h2>\n<p>Una pasarela de pago moderna exige HTTPS correctamente configurado. No basta con que el candado aparezca en el navegador como una medalla decorativa. El certificado debe estar vigente, la cadena intermedia debe ser v\u00e1lida y el servidor debe soportar protocolos seguros, normalmente TLS 1.2 o superior, seg\u00fan los requisitos de cada proveedor.<\/p>\n<p>Problemas habituales:<\/p>\n<ul>\n<li><strong>Certificado SSL caducado<\/strong> o instalado de forma incompleta.<\/li>\n<li><strong>Contenido mixto<\/strong>: scripts, im\u00e1genes o recursos cargados por HTTP dentro de una p\u00e1gina HTTPS.<\/li>\n<li><strong>cURL desactualizado<\/strong> o compilado con una versi\u00f3n antigua de OpenSSL.<\/li>\n<li><strong>Bloqueos de firewall saliente<\/strong> que impiden conectar con la API de la pasarela.<\/li>\n<li><strong>Redirecciones mal configuradas<\/strong> entre HTTP, HTTPS, www y sin www.<\/li>\n<\/ul>\n<p>Para revisar la configuraci\u00f3n:<\/p>\n<ol>\n<li>Comprueba el certificado con herramientas como SSL Labs o el panel del hosting.<\/li>\n<li>Verifica que PrestaShop tenga SSL activado en todas las p\u00e1ginas, especialmente checkout y cuenta de cliente.<\/li>\n<li>Revisa la URL de la tienda en <strong>Par\u00e1metros de la tienda &gt; Tr\u00e1fico y SEO<\/strong>, o secci\u00f3n equivalente seg\u00fan versi\u00f3n.<\/li>\n<li>Ejecuta una prueba de conexi\u00f3n cURL hacia la API del proveedor desde el servidor, no desde tu ordenador.<\/li>\n<li>Consulta el error log si ves mensajes como <code>SSL certificate problem<\/code>, <code>handshake failure<\/code> o <code>Could not resolve host<\/code>.<\/li>\n<\/ol>\n<p><strong>Buena pr\u00e1ctica:<\/strong> evita redirecciones encadenadas durante el pago. Cada salto adicional es una cuerda m\u00e1s sobre un puente ya cargado.<\/p>\n<h2 id=\"webhooks\">Webhooks, notificaciones y estados de pedido \ud83d\udcec<\/h2>\n<p>Muchos problemas de compatibilidad no ocurren cuando el cliente paga, sino despu\u00e9s, en ese momento silencioso en que la pasarela debe avisar a PrestaShop: \u201cel pago se ha autorizado\u201d, \u201cel pago ha sido capturado\u201d, \u201cla operaci\u00f3n ha fallado\u201d o \u201chay una devoluci\u00f3n\u201d. Ese aviso suele llamarse webhook, IPN, callback o notificaci\u00f3n, dependiendo del proveedor.<\/p>\n<p>Si el webhook falla, la pasarela puede haber cobrado correctamente, pero PrestaShop no crea el pedido o lo deja en estado incorrecto. Es una fractura inc\u00f3moda: el dinero en un lado, el pedido en otro, como dos n\u00e1ufragos vi\u00e9ndose desde islas cercanas.<\/p>\n<h3>Qu\u00e9 revisar en los webhooks<\/h3>\n<ul>\n<li><strong>URL p\u00fablica accesible:<\/strong> la pasarela debe poder llegar a la URL de notificaci\u00f3n sin autenticaci\u00f3n, bloqueo geogr\u00e1fico ni mantenimiento activo.<\/li>\n<li><strong>HTTPS v\u00e1lido:<\/strong> algunos proveedores rechazan endpoints con certificados no confiables.<\/li>\n<li><strong>Secreto de firma correcto:<\/strong> Stripe, por ejemplo, valida firmas de webhook; si el secreto no coincide, la notificaci\u00f3n se rechaza.<\/li>\n<li><strong>Respuesta HTTP 200:<\/strong> si PrestaShop devuelve 500, 403 o 404, la pasarela puede reintentar o marcar el evento como fallido.<\/li>\n<li><strong>Idempotencia:<\/strong> el m\u00f3dulo debe evitar crear pedidos duplicados cuando recibe la misma notificaci\u00f3n m\u00e1s de una vez.<\/li>\n<li><strong>Estados de pedido:<\/strong> confirma que \u201cPago aceptado\u201d, \u201cPendiente de pago\u201d, \u201cError de pago\u201d o estados personalizados est\u00e9n correctamente asignados.<\/li>\n<\/ul>\n<h3>Errores t\u00edpicos de notificaci\u00f3n<\/h3>\n<table>\n<thead>\n<tr>\n<th>Error<\/th>\n<th>Interpretaci\u00f3n<\/th>\n<th>Soluci\u00f3n recomendada<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Webhook con 404<\/td>\n<td>La URL no existe, el m\u00f3dulo cambi\u00f3 la ruta o hay reglas de reescritura incorrectas.<\/td>\n<td>Reinstalar o reconfigurar el webhook seg\u00fan la documentaci\u00f3n del m\u00f3dulo. Regenerar URLs amigables si procede.<\/td>\n<\/tr>\n<tr>\n<td>Webhook con 403<\/td>\n<td>Firewall, ModSecurity, bloqueo por IP, protecci\u00f3n anti-bots o mantenimiento.<\/td>\n<td>Crear reglas de exclusi\u00f3n para el endpoint leg\u00edtimo. Consultar al hosting.<\/td>\n<\/tr>\n<tr>\n<td>Firma inv\u00e1lida<\/td>\n<td>Secreto incorrecto, payload modificado o endpoint equivocado.<\/td>\n<td>Copiar de nuevo el secreto desde el panel de la pasarela y evitar que plugins intermedios alteren el cuerpo de la petici\u00f3n.<\/td>\n<\/tr>\n<tr>\n<td>Pedido no encontrado<\/td>\n<td>La notificaci\u00f3n llega antes de que PrestaShop complete el flujo, o hay referencia de carrito incorrecta.<\/td>\n<td>Actualizar m\u00f3dulo, revisar logs y confirmar que no haya cach\u00e9 o redirecciones alterando la sesi\u00f3n.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h2 id=\"tema-checkout\">Tema, checkout y conflictos visuales \ud83c\udfa8<\/h2>\n<p>El tema de PrestaShop no es un simple vestido. En checkout, el tema puede tocar formularios, hooks, scripts, botones, validaciones y pasos de compra. Un tema elegante puede ser t\u00e9cnicamente torpe; uno sobrio puede ser fiable como una llave vieja. La belleza y la estabilidad no siempre desayunan juntas.<\/p>\n<p>Las pasarelas de pago se integran normalmente mediante hooks como los relacionados con opciones de pago, confirmaci\u00f3n, cabecera o visualizaci\u00f3n en checkout. Si el tema sobrescribe plantillas cr\u00edticas o elimina llamadas a hooks, el m\u00e9todo puede no aparecer.<\/p>\n<h3>Pruebas recomendadas<\/h3>\n<ol>\n<li>Activa temporalmente el tema Classic en staging.<\/li>\n<li>Desactiva m\u00f3dulos de checkout en un paso si no son imprescindibles.<\/li>\n<li>Revisa la consola del navegador en busca de errores JavaScript.<\/li>\n<li>Desactiva minificaci\u00f3n y combinaci\u00f3n de CSS\/JS durante la prueba.<\/li>\n<li>Comprueba que el bot\u00f3n de pago no est\u00e9 oculto por CSS.<\/li>\n<li>Verifica compatibilidad del m\u00f3dulo con checkout est\u00e1ndar y checkout personalizado.<\/li>\n<\/ol>\n<p>Si con el tema Classic la pasarela funciona, el problema no est\u00e1 en el banco. Est\u00e1 en la capa de presentaci\u00f3n o en un m\u00f3dulo que modifica el flujo. Esa diferencia es valiosa: separa el bosque del humo.<\/p>\n<h2 id=\"cache\">Cach\u00e9, overrides y m\u00f3dulos incompatibles \ud83e\uddef<\/h2>\n<p>La optimizaci\u00f3n de rendimiento es necesaria, pero en checkout debe manejarse con guantes. La cach\u00e9 que acelera una ficha de producto puede arruinar una sesi\u00f3n de pago. El mismo cuchillo que corta pan puede cortar el cable del dat\u00e1fono.<\/p>\n<h3>M\u00f3dulos de cach\u00e9 y optimizaci\u00f3n<\/h3>\n<p>Si usas sistemas como cach\u00e9 de p\u00e1gina completa, m\u00f3dulos de minificaci\u00f3n, CDN, optimizadores JavaScript o herramientas de lazy loading, revisa que excluyan:<\/p>\n<ul>\n<li>Carrito.<\/li>\n<li>Checkout.<\/li>\n<li>Cuenta de cliente.<\/li>\n<li>Confirmaci\u00f3n de pedido.<\/li>\n<li>URLs de notificaci\u00f3n de pasarelas.<\/li>\n<li>Scripts externos necesarios para botones de pago.<\/li>\n<\/ul>\n<p>En PrestaShop, el checkout depende de sesi\u00f3n, tokens y datos din\u00e1micos. Cachearlo como si fuera una p\u00e1gina est\u00e1tica es invitar al caos con una tarjeta perfumada.<\/p>\n<h3>Overrides y personalizaciones<\/h3>\n<p>Los overrides pueden modificar clases centrales como carrito, pedido, cliente o validaci\u00f3n. Tambi\u00e9n pueden quedarse obsoletos tras una actualizaci\u00f3n. Revisa especialmente:<\/p>\n<ul>\n<li><code>\/override\/classes\/PaymentModule.php<\/code><\/li>\n<li><code>\/override\/classes\/Cart.php<\/code><\/li>\n<li><code>\/override\/classes\/order\/Order.php<\/code><\/li>\n<li><code>\/override\/controllers\/front\/OrderController.php<\/code><\/li>\n<li>Plantillas sobrescritas en el tema relacionadas con checkout y payment options.<\/li>\n<\/ul>\n<p>Para probar, no borres a ciegas. Desactiva temporalmente overrides en staging, limpia cach\u00e9 y recompila si es necesario. En PrestaShop, despu\u00e9s de tocar overrides, conviene borrar cach\u00e9 manualmente cuando el Back Office no basta.<\/p>\n<h2 id=\"pasarelas\">Casos habituales por pasarela de pago \ud83c\udf0d<\/h2>\n<p>Cada proveedor tiene su car\u00e1cter. Algunas pasarelas son meticulosas como notarios; otras, veloces como mensajeros en moto. Todas, sin excepci\u00f3n, castigan la configuraci\u00f3n aproximada.<\/p>\n<h3>Stripe en PrestaShop<\/h3>\n<p>Stripe suele ser robusto, pero exige precisi\u00f3n en claves, webhooks y versiones de API. Problemas frecuentes:<\/p>\n<ul>\n<li>Uso de claves de prueba en modo producci\u00f3n o viceversa.<\/li>\n<li>Webhook endpoint no configurado o secreto incorrecto.<\/li>\n<li>Errores con 3D Secure o Strong Customer Authentication en Europa.<\/li>\n<li>JavaScript bloqueado por CSP, minificaci\u00f3n o tema.<\/li>\n<li>Versi\u00f3n antigua del m\u00f3dulo incompatible con la versi\u00f3n actual de PHP.<\/li>\n<\/ul>\n<p>Revisa en el panel de Stripe los eventos fallidos. Stripe ofrece un historial muy \u00fatil de cada webhook, con c\u00f3digo HTTP y respuesta del servidor. Es casi una radiograf\u00eda; no cura, pero muestra d\u00f3nde duele.<\/p>\n<h3>PayPal en PrestaShop<\/h3>\n<p>PayPal combina redirecciones, botones din\u00e1micos, API y validaci\u00f3n de cuenta. Sus problemas suelen estar vinculados a:<\/p>\n<ul>\n<li>Credenciales API incorrectas.<\/li>\n<li>Cuenta PayPal no verificada o con restricciones.<\/li>\n<li>Conflictos de JavaScript en botones inteligentes.<\/li>\n<li>Monedas no soportadas o configuraci\u00f3n regional incorrecta.<\/li>\n<li>URLs de retorno y cancelaci\u00f3n afectadas por redirecciones.<\/li>\n<\/ul>\n<p>Si el bot\u00f3n de PayPal no aparece, no mires solo el m\u00f3dulo. Revisa pa\u00eds, moneda, total del carrito, consola del navegador y posibles bloqueadores de scripts.<\/p>\n<h3>Redsys en PrestaShop<\/h3>\n<p>Redsys, muy usado en Espa\u00f1a, requiere especial atenci\u00f3n a firma, n\u00famero de comercio, terminal, clave secreta SHA-256, entorno de pruebas y par\u00e1metros del banco. Un car\u00e1cter de m\u00e1s o de menos en la clave secreta puede convertir una integraci\u00f3n seria en una tragicomedia administrativa.<\/p>\n<p>Problemas habituales:<\/p>\n<ul>\n<li>Clave de firma incorrecta o copiada con espacios.<\/li>\n<li>Modo pruebas activado en producci\u00f3n.<\/li>\n<li>Terminal o n\u00famero de comercio equivocado.<\/li>\n<li>Tipo de moneda mal configurado.<\/li>\n<li>Notificaci\u00f3n online no activada en el panel bancario.<\/li>\n<li>ModSecurity bloqueando la respuesta POST de Redsys.<\/li>\n<\/ul>\n<p>Comprueba que la URL de notificaci\u00f3n sea accesible y que el banco tenga habilitada la comunicaci\u00f3n online. En Redsys, el pago puede estar autorizado y aun as\u00ed no actualizar el pedido si la notificaci\u00f3n no llega bien a PrestaShop.<\/p>\n<h3>Mercado Pago en PrestaShop<\/h3>\n<p>Mercado Pago es com\u00fan en Latinoam\u00e9rica y puede depender mucho de pa\u00eds, moneda, cuenta, credenciales y tipo de integraci\u00f3n. Revisa:<\/p>\n<ul>\n<li>Credenciales p\u00fablicas y privadas del entorno correcto.<\/li>\n<li>Pa\u00eds configurado en la cuenta y moneda de la tienda.<\/li>\n<li>URL de notificaciones IPN o webhooks.<\/li>\n<li>Compatibilidad del m\u00f3dulo con tu versi\u00f3n de PrestaShop.<\/li>\n<li>Restricciones del m\u00e9todo de pago seleccionado.<\/li>\n<\/ul>\n<p>En tiendas multimoneda o multitienda, presta atenci\u00f3n doble. Lo que funciona para una tienda puede fallar en otra si el contexto cambia. PrestaShop multitienda es poderoso, s\u00ed, pero tambi\u00e9n tiene esa cualidad de los castillos antiguos: muchas habitaciones, muchas llaves, alg\u00fan pasillo que nadie recuerda.<\/p>\n<h2>Configuraciones que suelen pasar desapercibidas \ud83d\udc40<\/h2>\n<h3>Restricciones por moneda, pa\u00eds y transportista<\/h3>\n<p>En PrestaShop, los m\u00e9todos de pago pueden estar limitados por moneda, pa\u00eds, grupo de clientes o transportista. Si una pasarela no aparece, no siempre est\u00e1 rota; quiz\u00e1 est\u00e1 obedeciendo una regla olvidada.<\/p>\n<p>Revisa:<\/p>\n<ul>\n<li><strong>Pago por moneda:<\/strong> algunos m\u00f3dulos solo admiten EUR, USD u otras monedas espec\u00edficas.<\/li>\n<li><strong>Pago por pa\u00eds:<\/strong> puede estar habilitado para Espa\u00f1a pero no para M\u00e9xico, Chile o Colombia.<\/li>\n<li><strong>Pago por grupo de clientes:<\/strong> clientes invitados, minoristas, profesionales o grupos B2B.<\/li>\n<li><strong>Pago por transportista:<\/strong> determinados m\u00e9todos de env\u00edo pueden excluir pagos concretos.<\/li>\n<\/ul>\n<h3>Redondeos, impuestos y totales inconsistentes<\/h3>\n<p>Algunas pasarelas rechazan pagos si el importe enviado no coincide exactamente con el total esperado. Diferencias de c\u00e9ntimos por redondeo, impuestos incluidos\/excluidos o descuentos mal calculados pueden provocar errores dif\u00edciles de ver.<\/p>\n<p>Comprueba:<\/p>\n<ul>\n<li>Configuraci\u00f3n de redondeo en PrestaShop.<\/li>\n<li>Reglas de impuestos por pa\u00eds y provincia.<\/li>\n<li>Descuentos aplicados antes o despu\u00e9s de impuestos.<\/li>\n<li>Gastos de env\u00edo con IVA.<\/li>\n<li>Decimales de la moneda.<\/li>\n<\/ul>\n<p>Un c\u00e9ntimo parece poca cosa. En una pasarela de pago, puede ser una frontera infranqueable, como una grieta m\u00ednima en un cristal templado.<\/p>\n<h3>Sesiones, cookies y dominio can\u00f3nico<\/h3>\n<p>Si el usuario entra por <code>www.tienda.com<\/code> pero vuelve desde la pasarela a <code>tienda.com<\/code>, o si hay cambios entre HTTP y HTTPS, la sesi\u00f3n puede perderse. Resultado: carrito vac\u00edo, pedido no asociado o error al validar.<\/p>\n<p>Verifica:<\/p>\n<ul>\n<li>Dominio principal configurado correctamente.<\/li>\n<li>Redirecci\u00f3n \u00fanica y consistente a HTTPS.<\/li>\n<li>Cookies v\u00e1lidas para el dominio adecuado.<\/li>\n<li>No mezclar subdominios durante checkout.<\/li>\n<li>No usar reglas agresivas de limpieza de sesi\u00f3n.<\/li>\n<\/ul>\n<h2>Seguridad: resolver sin abrir una grieta \ud83d\udee1\ufe0f<\/h2>\n<p>Cuando un pago falla, existe la tentaci\u00f3n de desactivar protecciones \u201ctemporalmente\u201d. Temporalmente, esa palabra que en algunos servidores significa desde 2019. Hay que resolver, s\u00ed, pero sin dejar la tienda desnuda frente al tr\u00e1fico.<\/p>\n<p>Buenas pr\u00e1cticas de seguridad al trabajar con pasarelas de pago en PrestaShop:<\/p>\n<ul>\n<li>No compartas claves API por correo sin cifrado ni en tickets p\u00fablicos.<\/li>\n<li>Regenera claves si han sido expuestas.<\/li>\n<li>Usa cuentas con permisos m\u00ednimos cuando la pasarela lo permita.<\/li>\n<li>Verifica que las URLs de webhook no revelen informaci\u00f3n sensible.<\/li>\n<li>No desactives SSL ni validaci\u00f3n de certificados para \u201cprobar\u201d.<\/li>\n<li>Mant\u00e9n actualizado el m\u00f3dulo oficial de pago.<\/li>\n<li>Revisa usuarios administradores y accesos al Back Office.<\/li>\n<li>Registra cambios t\u00e9cnicos: qui\u00e9n toc\u00f3 qu\u00e9, cu\u00e1ndo y por qu\u00e9.<\/li>\n<\/ul>\n<p>Tambi\u00e9n conviene recordar que aceptar pagos implica responsabilidades legales y de seguridad. La mayor\u00eda de tiendas no procesa directamente datos completos de tarjeta si usa pasarelas externas, lo cual reduce la carga PCI DSS, pero no elimina la necesidad de una tienda segura, HTTPS correcto y m\u00f3dulos confiables.<\/p>\n<h2>Rendimiento y experiencia de pago: la velocidad tambi\u00e9n cobra \ud83d\udca8<\/h2>\n<p>Un checkout lento no siempre rompe la pasarela, pero s\u00ed rompe la paciencia. Y la paciencia del comprador online es fina como papel de arroz. Si el m\u00f3dulo tarda en cargar scripts externos, si el servidor responde lento o si el carrito recalcula eternamente transportistas e impuestos, el usuario abandona.<\/p>\n<p>Mejoras recomendadas:<\/p>\n<ul>\n<li>Optimiza TTFB del servidor.<\/li>\n<li>Evita m\u00f3dulos innecesarios en checkout.<\/li>\n<li>Excluye p\u00e1ginas de pago de cach\u00e9s peligrosas, pero no descuides rendimiento global.<\/li>\n<li>Usa CDN con cuidado, sin romper scripts de pasarelas.<\/li>\n<li>Controla llamadas externas excesivas.<\/li>\n<li>Revisa consultas lentas en base de datos.<\/li>\n<li>Mant\u00e9n limpia la tabla de logs si ha crecido de forma desmesurada.<\/li>\n<\/ul>\n<p>La paradoja es clara: queremos m\u00e1xima seguridad, m\u00ednima fricci\u00f3n; controles estrictos, experiencia ligera. Un checkout ideal debe ser como un buen camarero: presente cuando hace falta, invisible cuando no.<\/p>\n<h2>Procedimiento de emergencia cuando los pagos est\u00e1n ca\u00eddos \ud83d\udea8<\/h2>\n<p>Si la tienda est\u00e1 en producci\u00f3n y los clientes no pueden pagar, act\u00faa con orden. La prisa desordenada multiplica da\u00f1os.<\/p>\n<ol>\n<li><strong>Confirma el alcance:<\/strong> \u00bffallan todas las pasarelas o solo una?<\/li>\n<li><strong>Activa un m\u00e9todo alternativo:<\/strong> transferencia bancaria, pago contra reembolso o una segunda pasarela si est\u00e1 disponible.<\/li>\n<li><strong>Revisa estado del proveedor:<\/strong> Stripe, PayPal, Redsys o Mercado Pago pueden tener incidencias externas.<\/li>\n<li><strong>Consulta logs recientes:<\/strong> busca cambios desde la \u00faltima venta correcta.<\/li>\n<li><strong>Desactiva temporalmente m\u00f3dulos a\u00f1adidos recientemente:<\/strong> cach\u00e9, optimizaci\u00f3n, seguridad, checkout, remarketing.<\/li>\n<li><strong>Prueba con un carrito m\u00ednimo:<\/strong> producto simple, sin cup\u00f3n, transportista est\u00e1ndar.<\/li>\n<li><strong>No actualices todo en caliente:<\/strong> salvo que identifiques una causa clara y tengas backup.<\/li>\n<li><strong>Comunica internamente:<\/strong> soporte, ventas y administraci\u00f3n deben saber si puede haber pagos cobrados sin pedido.<\/li>\n<\/ol>\n<p><strong>Importante:<\/strong> si hay pagos cobrados sin pedido, no pierdas tiempo discutiendo con la interfaz. Cruza datos entre la pasarela, los carritos de PrestaShop, clientes y logs. Atiende al cliente antes de terminar la autopsia t\u00e9cnica.<\/p>\n<h2 id=\"checklist\">Checklist final para solucionar incompatibilidades con pasarelas de pago en PrestaShop \u2705<\/h2>\n<p>Guarda esta lista. No sustituye el criterio t\u00e9cnico, pero evita olvidar lo obvio, que suele ser el lugar favorito de los problemas.<\/p>\n<ul>\n<li>\u2611\ufe0f Confirmar versi\u00f3n de PrestaShop y compatibilidad declarada del m\u00f3dulo.<\/li>\n<li>\u2611\ufe0f Verificar versi\u00f3n de PHP recomendada por PrestaShop y por la pasarela.<\/li>\n<li>\u2611\ufe0f Actualizar el m\u00f3dulo de pago desde una fuente oficial.<\/li>\n<li>\u2611\ufe0f Revisar credenciales: claves p\u00fablicas, privadas, sandbox, producci\u00f3n, terminal, comercio.<\/li>\n<li>\u2611\ufe0f Comprobar SSL, TLS, cURL y OpenSSL en el servidor.<\/li>\n<li>\u2611\ufe0f Revisar logs de PrestaShop, servidor, PHP y panel de la pasarela.<\/li>\n<li>\u2611\ufe0f Probar webhooks y confirmar respuestas HTTP 200.<\/li>\n<li>\u2611\ufe0f Revisar firma de notificaciones y secreto de webhook.<\/li>\n<li>\u2611\ufe0f Validar estados de pedido asociados al m\u00f3dulo.<\/li>\n<li>\u2611\ufe0f Comprobar restricciones por pa\u00eds, moneda, grupo de cliente y transportista.<\/li>\n<li>\u2611\ufe0f Probar con tema Classic o tema est\u00e1ndar en staging.<\/li>\n<li>\u2611\ufe0f Desactivar temporalmente m\u00f3dulos de cach\u00e9, optimizaci\u00f3n y checkout personalizado.<\/li>\n<li>\u2611\ufe0f Revisar overrides y plantillas modificadas.<\/li>\n<li>\u2611\ufe0f Confirmar que no haya redirecciones extra\u00f1as entre HTTP\/HTTPS, www\/sin www.<\/li>\n<li>\u2611\ufe0f Comprobar consola del navegador y errores JavaScript.<\/li>\n<li>\u2611\ufe0f Realizar prueba con carrito simple, cliente nuevo y moneda principal.<\/li>\n<li>\u2611\ufe0f Documentar cambios y resultados.<\/li>\n<\/ul>\n<h2>Cu\u00e1ndo pedir ayuda especializada \ud83e\uddd1\u200d\ud83d\udcbb<\/h2>\n<p>Hay un punto en el que seguir probando sin m\u00e9todo sale m\u00e1s caro que contratar a alguien que ya ha visto ese incendio antes. Conviene escalar el caso cuando:<\/p>\n<ul>\n<li>Hay pagos capturados sin pedidos creados.<\/li>\n<li>El error aparece solo en producci\u00f3n y no en pruebas.<\/li>\n<li>Existen m\u00faltiples m\u00f3dulos modificando checkout.<\/li>\n<li>La tienda usa multitienda, multimoneda o reglas fiscales complejas.<\/li>\n<li>El m\u00f3dulo no tiene soporte activo.<\/li>\n<li>Hay errores 500 sin trazas claras.<\/li>\n<li>El hosting bloquea notificaciones y no sabes c\u00f3mo crear exclusiones seguras.<\/li>\n<li>La tienda factura lo suficiente como para que cada hora de ca\u00edda duela.<\/li>\n<\/ul>\n<p>Un especialista en PrestaShop no deber\u00eda limitarse a \u201creinstalar el m\u00f3dulo\u201d. Deber\u00eda revisar arquitectura, logs, servidor, flujo de checkout, seguridad y compatibilidad. La diferencia entre parchear y resolver es la misma que entre tapar una gotera con cinta adhesiva y reparar el tejado.<\/p>\n<h2>Una forma sensata de mirar el problema<\/h2>\n<p>Solucionar problemas de compatibilidad con pasarelas de pago en PrestaShop exige una mezcla curiosa de t\u00e9cnica y paciencia. Hay que leer documentaci\u00f3n, mirar logs, sospechar del tema, desconfiar de la cach\u00e9, respetar el SSL, entender los webhooks y recordar que el cliente no est\u00e1 all\u00ed para admirar nuestra arquitectura: est\u00e1 para comprar.<\/p>\n<p>La tienda online vive de una promesa sencilla: elegir, pagar, recibir. Todo lo dem\u00e1s es maquinaria bajo el suelo. Cuando esa maquinaria falla, conviene actuar sin superstici\u00f3n y sin furia. Revisar versiones. Probar en staging. Confirmar credenciales. Seguir el rastro de la notificaci\u00f3n. Escuchar al servidor cuando habla en errores secos.<\/p>\n<p>Porque al final, una pasarela compatible no es solo una integraci\u00f3n t\u00e9cnica. Es confianza convertida en proceso. Es el instante en que una intenci\u00f3n se vuelve pedido. Y en comercio electr\u00f3nico, ese instante vale demasiado como para dejarlo en manos del azar, de un m\u00f3dulo abandonado o de un copo de nieve navide\u00f1o que decidi\u00f3 aprender JavaScript. \ud83d\udcb3\u2728<\/p>\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":3838,"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-3839","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\/3839","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=3839"}],"version-history":[{"count":1,"href":"https:\/\/mantenimientoweb.pro\/blog\/wp-json\/wp\/v2\/posts\/3839\/revisions"}],"predecessor-version":[{"id":3840,"href":"https:\/\/mantenimientoweb.pro\/blog\/wp-json\/wp\/v2\/posts\/3839\/revisions\/3840"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/mantenimientoweb.pro\/blog\/wp-json\/wp\/v2\/media\/3838"}],"wp:attachment":[{"href":"https:\/\/mantenimientoweb.pro\/blog\/wp-json\/wp\/v2\/media?parent=3839"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mantenimientoweb.pro\/blog\/wp-json\/wp\/v2\/categories?post=3839"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mantenimientoweb.pro\/blog\/wp-json\/wp\/v2\/tags?post=3839"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}