✓ Sin compromiso · ⚡ Respuesta en menos de 24 h · 💬 WhatsApp
💸 Pago KO = facturación que se escapa en silencio

¿El pago falla en tu
PrestaShop?
volvemos a poner la pasarela en marcha.

Auditoría y corrección de bugs de pago PrestaShop (Stripe, PayPal, Redsys, Bizum, Apple Pay)

Cliente que ha pagado pero pedido no creado, widget Stripe que no carga, PayPal en bucle, 3D Secure rechazado, Apple Pay invisible en iOS, Bizum desactivado, Redsys con SIS0042: cada PSP tiene sus averías típicas. Leemos los logs PSP, identificamos la ruptura, reconectamos la cadena.

O chatear por WhatsApp
✓ Pre-auditoría gratuita 30 min ✓ Presupuesto en 24 h laborables ✓ Desde 60 €/h sin IVA ✓ Pedidos huérfanos recuperados
💸 El coste real de un pago roto

Un bug de pago es 8 al 15% de tu facturación que se va

Medida sobre 18 auditorías de pago PrestaShop realizadas en 2025-2026. Compara con tu propia tienda.

200
pedidos / mes
(tienda B2C estándar)
× 8-15%
carritos perdidos
específicamente por bug de pago
3 a 5 k€
facturación / mes recuperable
tras arreglar la pasarela
💡 Pre-auditoría gratuita: te damos la cifra exacta para tu tienda.
🔎 Síntomas por PSP

Cada pasarela tiene sus averías típicas

Identifica tu PSP y el síntoma: orienta inmediatamente el diagnóstico.

💳 Stripe

Averías frecuentes:

  • authentication_required → 3DSv2 no implementado
  • Widget Card Element no carga → CSP que bloquea js.stripe.com
  • Endpoint webhook en 403 → IPs Stripe bloqueadas por WAF
  • signature_verification_failed → clave secreta webhook rotada
🅿️ PayPal

Averías frecuentes:

  • Botón «Pagar con PayPal» invisible → SDK JS no cargado
  • Redirect a paypal.com en bucle → token IPN roto
  • Webhook IPN que no llega → URL cambiada sin actualizar el dashboard
  • Sandbox activo en producción → claves API test no conmutadas
🏦 Redsys (BBVA, CaixaBank, Santander, Sabadell)

Averías frecuentes:

  • SIS0042: firma SHA-256 incorrecta → clave técnica errónea
  • Redirect 3DS que vuelve a una página de error PrestaShop
  • Notificación servidor (callback) en 500 → endpoint PHP roto
  • Pedido en «pendiente de pago» indefinidamente → URL DS_MERCHANT_MERCHANTURL inalcanzable
📱 Bizum

Averías frecuentes:

  • Botón Bizum no aparece → método no activado en el TPV virtual
  • Importe rechazado → límite por operación superado (1 000 € / 2 000 € según banco)
  • Pedido no confirmado tras pago → callback Bizum mal configurado
  • Módulo PrestaShop Bizum incompatible con PS 8.x
🍎 Apple Pay / Google Pay

Averías frecuentes:

  • Botón Apple Pay invisible iOS → archivo apple-developer-merchantid-domain-association ausente
  • Dominio no verificado en el dashboard PSP
  • HTTPS no válido en todo el sitio (subdominios)
  • En iOS < 15: Apple Pay rechaza sin Safari nativo
🌍 Klarna / Adyen

Averías frecuentes:

  • Estado del pedido que se queda en «pending» indefinidamente
  • Método local (Klarna Pay Later, SEPA) no activado en dashboard
  • Webhook recibido en 200 pero status no actualizado → bug del módulo
  • Modo test/live confundido tras migración
⚡ Intervención tipo

Bug Stripe resuelto en 2 h 21

Caso real · Tienda complementos alimenticios · PrestaShop 8.1 + módulo Stripe oficial · Febrero de 2026.

10:18
Email del cliente «Desde hace 3 días, Stripe muestra el widget pero cuando el cliente hace clic en Pagar, no pasa nada. Tenemos 42 carritos abandonados en la última etapa según GA4.»
10:24
Pre-auditoría · consola del navegador Apertura del recorrido de pago, F12 → Consola. Error mostrado: Refused to load the script 'https://js.stripe.com/v3/' because it violates the following Content Security Policy directive. CSP que bloquea Stripe.
10:31
Origen identificado El cliente había instalado 4 días antes un módulo de seguridad «Hardener» que inyectaba una cabecera Content-Security-Policy muy restrictiva sin permitir Stripe. Bingo.
10:48
Presupuesto enviado · 2 h estimadas Email con causa identificada + plan de acción: (1) añadir dominios Stripe a la whitelist CSP, (2) pruebas completas del recorrido, (3) auditoría de otros scripts que pudieran estar bloqueados (PayPal, Bizum, Google Pay, reCAPTCHA).
11:34
Fix desplegado CSP ampliada: script-src 'self' js.stripe.com m.stripe.network + frame-src js.stripe.com hooks.stripe.com. Pruebas en 3 tarjetas (Visa 3DS, Mastercard sin 3DS, AmEx): pagos OK.
12:39
Informe + recuperación de carritos abandonados Cruce con el Stripe Dashboard → 11 cargos exitosos en 3 días cuyo pedido PS no se había creado (bug antes del fix). Creación manual de los 11 pedidos para envío.
2 h 21
Total intervención
~ 141 €
Facturado bajo presupuesto
(2 h 21 × 60 €/h sin IVA)
11 ped
+ 2 850 €
Pedidos huérfanos recuperados
💰 Tarifas

Tarifas anunciadas por adelantado

Pre-auditoría gratuita. Para la intervención, sabes exactamente cuánto cuesta antes de que se toque el código.

🔍 Pre-auditoría

Pre-auditoría

descubrir por qué no se paga
0gratis
30 min · sin compromiso
  • Prueba del recorrido de pago completo (Visa, MC, 3DS)
  • Lectura logs PSP (dashboard Stripe/PayPal/Redsys/Bizum)
  • Presupuesto firme + facturación recuperable estimada
  • Tú decides si continuamos
Lanzar la pre-auditoría →
⚡ Lo más solicitado 🔧 Intervención

Intervención dirigida

volver a poner el pago en marcha
desde 60sin IVA
según diagnóstico · precio anunciado por adelantado
  • Copia de seguridad ficheros + BD antes de intervenir
  • Corrección de la causa (webhook, clave, CSP, 3DS, módulo)
  • Pruebas en Visa, MC, AmEx, Bizum, Apple Pay si procede
  • Recuperación de los pedidos huérfanos (≤ 10 incluidos)
  • Garantía 30 días sobre la corrección
🛡️ Mantenimiento

Mantenimiento Performance

vigilancia permanente del pago
desde 50/ mes
vigilancia 24/7 · sin compromiso
  • Replay automatizado del recorrido de pago mensual
  • Copias automáticas diarias externalizadas
  • Alerta si webhook PSP en error > 3 veces
  • Intervención prioritaria en caso de bug de pago
Ver planes →
🧭 No los confundas

«Bug de pago», no es...

❌ No es un bug general del checkout

Si el carrito se vacía, la etapa de envío entra en bucle, el botón siguiente no reacciona antes incluso de llegar al pago: es el embudo de compra, no el PSP. Página dedicada.

Página checkout →
❌ No es un rechazo del PSP por sector

Si Stripe/PayPal rechaza tu actividad (juego, CBD, cigarrillos electrónicos), es una decisión comercial del PSP, no un bug técnico. Solución: cambiar de PSP por uno que acepte tu sector.

❌ No es fraude bancario

Si hay transacciones disputadas (chargeback) o rechazadas por el banco emisor, es lucha antifraude del lado tarjeta, no un bug PrestaShop. Herramientas dedicadas: Stripe Radar, Sift, etc.

❓ FAQ

Bug de pago PrestaShop — preguntas frecuentes

Seis causas destacan en 2025-2026: (1) clave API caducada o rotada en el PSP, (2) URL del webhook bloqueada por WAF / Cloudflare, (3) certificado SSL caducado o no reconocido, (4) 3D Secure v2 no implementado (desde PSD2), (5) módulo incompatible con tu versión PrestaShop tras update, (6) JavaScript del widget bloqueado por otro módulo (chat, tracking, consentimiento RGPD).
Bug de webhook clásico. El PSP envía un POST de confirmación a tu sitio tras el pago. Si la petición falla, el pedido no se crea aunque el dinero esté cobrado. Verificación inmediata: dashboard PSP > Webhooks > estado de los últimos intentos. Si ves 403/500/502/timeout, el webhook no pasa. Causas: firewall WAF que bloquea las IP del PSP, endpoint con fatal, URL mal configurada. Solución: whitelist IPs oficiales + corrección endpoint. Los pedidos huérfanos se recrean manualmente desde los pagos PSP.
Desde PSD2 / SCA (septiembre de 2021), todas las transacciones B2C en el EEE deben pasar 3DSv2 salvo exenciones. Los módulos antiguos (anteriores a 2022) implementan a menudo 3DSv1 que ya no se acepta. Síntomas: authentication_required, widget Stripe que se carga y luego desaparece. Solución: actualizar el módulo Stripe oficial (gestiona 3DSv2 de forma nativa), o parchear el módulo custom para llamar a PaymentIntents API y gestionar el challenge.
Redsys y Bizum exigen: (1) firma SHA-256 correcta con la clave del banco (BBVA, CaixaBank, Santander, Sabadell), (2) URL de notificación pública que devuelva HTTP 200, (3) DS_MERCHANT_TERMINAL coherente con tu TPV virtual. Síntomas: SIS0042, pedido «pendiente de pago» indefinidamente, redirect bucle. Solución: regeneración de la clave en el panel del banco, verificación del módulo Redsys oficial / redsys_premium, prueba del callback con curl. La mayoría se resuelve en menos de 2 h.
Apple Pay exige tres condiciones acumulativas: (1) HTTPS válido en todo el sitio (no solo la página de checkout), (2) un archivo de verificación de dominio en /.well-known/apple-developer-merchantid-domain-association — a menudo olvidado tras migración, (3) dominio verificado en el dashboard Apple Pay (vía Stripe si Stripe). Diagnóstico: consola JS Safari iOS en el checkout. Solución: regeneración del archivo de asociación desde dashboard PSP, subida al servidor, re-verificación. 15 min de media.
La pre-auditoría es gratuita (30 min): prueba del recorrido de pago completo, lectura de los logs PrestaShop y del dashboard PSP. La intervención se factura luego bajo presupuesto, desde 60 €/h sin IVA. La mayoría de los bugs de pago (webhook, clave API, 3DS, Bizum, Redsys) se resuelven en 1 a 3 h una vez identificada la causa. Presupuesto enviado en 24 h laborables. Incluido en el mantenimiento Business / Performance.
En las auditorías de pago 2025-2026, el bug es responsable de media del 8 al 15% de la tasa de abandono del checkout. Para una tienda con 200 pedidos/mes y 70% de abandono: 8 al 15% × ≈ 50 a 90 carritos/mes × 60 € de ticket medio = 3 000 a 5 400 €/mes de facturación perdida específicamente por culpa del pago. ROI inmediato desde el primer mes tras el fix.

Tus clientes ya no consiguen pagar?

Pre-auditoría gratuita 30 min: probamos un recorrido completo, identificamos la ruptura, cuantificamos. Presupuesto en 24 h laborables.

💬 WhatsApp
💬 Chatear por WhatsApp — respuesta en minutos