Un fallo silencioso de pasarela en WooCommerce ocurre cuando la tienda online parece funcionar con total normalidad pero los clientes no pueden completar el pago con tarjeta o Bizum. En la inmensa mayoría de los casos, la causa no es una caída del servidor, sino un webhook bloqueado por un firewall (HTTP 403), una clave de firma desalineada entre Stripe o Redsys y el plugin, o el modo sandbox activado por error tras una actualización.

El problema más costoso para cualquier negocio digital es aquel del que no te enteras. Si tu servidor se cae por completo, recibes una alerta de tiempo de actividad en pocos minutos. Pero si el botón de pago en la caja rechaza operaciones silenciosamente, tus visitas siguen navegando, añaden productos al carrito, y al intentar pagar se encuentran con un error genérico o una pantalla de carga infinita.

En este artículo analizamos la anatomía técnica del flujo de pago en WooCommerce, las causas exactas por las que fallan Stripe y Redsys, y el protocolo paso a paso para diagnosticarlas y resolverlas.

Diagnóstico de terminales de pago y comprobación de pasarelas en WooCommerce

Por qué los fallos de pago son «silenciosos»

En una transacción de comercio electrónico moderna intervienen tres actores independientes:

  1. El navegador del cliente, ejecutando el formulario de pago JavaScript.
  2. El servidor de la pasarela bancaria (Stripe, Banco Santander, BBVA o Caixabank vía Redsys).
  3. Tu servidor web con WordPress y WooCommerce.

Cuando un cliente pulsa «Realizar el pedido», el banco suele autorizar el cargo en su tarjeta de forma síncrona. Sin embargo, para que WooCommerce marque el pedido como «Procesando» y descuente el inventario, la pasarela debe enviar una notificación asíncrona por detrás (webhook o llamada IPN) a una URL de tu tienda.

Diagrama técnico de rotura silenciosa en el webhook de pasarela de pago

Si esa comunicación secundaria falla, se produce una desconexión crítica:

  • El comprador ve un cargo en su banca móvil.
  • Tu tienda no recibe la confirmación.
  • El pedido queda atascado en estado «Pendiente de pago».
  • Tras el tiempo de retención fijado en WooCommerce (habitualmente 60 minutos), el sistema cancela el pedido por caducidad y devuelve el producto al stock.

El resultado es un cliente frustrado que exige explicaciones y una venta legítima que se convierte en una incidencia de atención al cliente.

Las 4 causas técnicas más comunes en Stripe y Redsys

A lo largo de cientos de auditorías en tiendas WooCommerce, hemos comprobado que más del 90 % de los fallos de pasarela se reducen a cuatro configuraciones erróneas:

1. Clave secreta del Webhook desalineada en Stripe (whsec_...)

Cuando configuras el plugin oficial de Stripe en WooCommerce, se generan claves públicas y privadas (pk_live_... y sk_live_...). Sin embargo, muchos administradores olvidan configurar el Secreto para la firma del webhook (Signing secret).

Si regeneras tus claves en el panel de Stripe o migras de entorno sin actualizar esta clave en los ajustes de WooCommerce, el plugin rechazará todas las notificaciones entrantes con un error de verificación criptográfica:

Stripe Webhook Error: Signature verification failed. Check your webhook secret.

2. Errores de firma SIS y modo pruebas en Redsys

En el ecosistema bancario español (Redsys), los fallos suelen deberse a dos motivos:

  • Error SIS0042 o SIS0019: La clave secreta de comercio (SHA-256) configurada en el plugin de Redsys no coincide exactamente con la generada en el Módulo de Administración del TPV Virtual.
  • Entorno de pruebas activo en producción: Tras realizar ajustes o actualizaciones, la casilla «Modo de pruebas» queda marcada, intentando enviar transacciones reales contra el servidor de pruebas (sis-t.sermepa.es) en lugar del entorno real (sis.sermepa.es).

3. Firewalls y plugins de seguridad bloqueando peticiones POST

Plugins como Wordfence, iThemes Security o reglas de protección WAF en Cloudflare a menudo interpretan las llamadas entrantes de los servidores de pago como ataques automatizados. Al responder con un código HTTP 403 Forbidden, el webhook bancario no puede entregar la confirmación.

Las direcciones que siempre deben estar en la lista blanca de tu cortafuegos son:

  • Redsys: https://mitienda.com/?wc-api=WC_Gateway_Redsys
  • Stripe: https://mitienda.com/?wc-api=wc_stripe

4. Cron de WordPress inactivo (wp-cron.php)

WooCommerce utiliza tareas programadas para revisar el estado de pedidos y comprobar confirmaciones pendientes. Si tu servidor tiene un tráfico muy bajo o el cron virtual de WordPress está bloqueado por el archivo wp-config.php, los pedidos no cambian de estado a tiempo.

Protocolo de diagnóstico paso a paso

Si sospechas que tu tienda no está cobrando pedidos correctamente, sigue este procedimiento de verificación manual:

Paso 1: Revisar el registro de errores de WooCommerce

Accede a tu panel de WordPress y ve a WooCommerce > Estado > Registros.

En el desplegable superior derecho, busca archivos con los siguientes prefijos:

  • woocommerce-gateway-stripe-...
  • redsys-...
  • fatal-errors-...

Pulsa «Ver» y busca líneas que contengan CRITICAL, 401 Unauthorized o Webhook failed. Si encuentras errores recurrentes en las horas en que bajaron tus ventas, habrás localizado el componente dañado.

Paso 2: Auditar los eventos en el Dashboard de Stripe

  1. Inicia sesión en tu panel de control de Stripe (dashboard.stripe.com).
  2. Entra en Desarrolladores > Webhooks.
  3. Haz clic en el endpoint configurado para tu tienda WooCommerce.
  4. Revisa la columna de respuesta: todos los eventos (payment_intent.succeeded, charge.succeeded) deben devolver un código 200 OK. Si ves respuestas 403, 500 o Timeout, pulsa sobre el evento para ver la respuesta devuelta por tu servidor.

Paso 3: Código de seguridad para alertar de pedidos fallidos

Puedes añadir un snippet temporal en el archivo functions.php de tu tema hijo o mediante un plugin de código personalizado para recibir un correo de alerta inmediato cada vez que un pedido pase a estado fallido:

add_action('woocommerce_order_status_failed', 'radar_alertar_fallo_pago', 10, 2);
function radar_alertar_fallo_pago($order_id, $order) {
    $to = get_option('admin_email');
    $subject = sprintf('ALERTA: Pedido #%d fallido en la caja', $order_id);
    $message = sprintf(
        "Se ha registrado un fallo de pago en el pedido #%d.
Importe: %s
Pasarela: %s
Cliente: %s",
        $order_id,
        $order->get_total(),
        $order->get_payment_method_title(),
        $order->get_billing_email()
    );
    wp_mail($to, $subject, $message);
}

Cómo lo detecta y resuelve Melopo Radar

No puedes estar revisando el panel de Stripe o los registros de WooCommerce cada quince minutos. Melopo Radar vigila tu pasarela de forma ininterrumpida mediante sus módulos especializados:

  • Comprobación PAY: Comprueba que las pasarelas activas no se encuentren en modo de pruebas en producción, verifica la accesibilidad de los endpoints de webhook desde el exterior y detecta certificados SSL caducados o con problemas de cadena intermedia.
  • Comprobación ORD: Monitoriza la tasa de conversión en la caja. Si tu tienda recibe tráfico constante pero los pedidos quedan atascados en «Pendiente» sin pasar a «Procesando» durante un periodo anómalo, salta una alerta inmediata calculando el dinero que está en riesgo de perderse.
  • Informe mensual de salud: Registra cualquier anomalía en los cobros para que puedas exigir responsabilidades técnicas a tu hosting o proveedor bancario.

Para mantener una tienda saludable en todos los frentes, te recomendamos revisar también nuestra guía sobre copias de seguridad expuestas en la raíz de WordPress o aprender a resolver problemas de indexación y errores 404.