Pocas cosas generan tanta ansiedad a un administrador de e-commerce que recibir el aviso de un cliente diciendo: "He intentado pagar y la web del banco dice que ha ocurrido un error". En la pasarela bancaria Redsys, los fallos no suelen venir acompañados de explicaciones comprensibles, sino de crípticos códigos alfanuméricos como SIS0042 o pedidos que se cobran en el banco pero se quedan estancados como "Pendiente de pago" en WooCommerce.
El error SIS0042 indica una discrepancia en el hash criptográfico Ds_Signature. Para solucionarlo: entra al panel de administración de Redsys de tu banco, pulsa en Comercio > Ver clave, copia la clave secreta SHA-256 asegurándote de no incluir espacios en blanco antes ni después, y pégala de nuevo en la configuración del plugin en WooCommerce. Verifica además que no estés usando la clave de pruebas en entorno real.
Diccionario de Códigos de Error SIS de Redsys y cómo solucionarlos
Cuando una pasarela Redsys deniega una transacción antes de solicitar los datos de la tarjeta, devuelve un código SIS indicando qué parámetro técnico ha fallado:
| Código SIS | Significado Oficial | Causa Raíz y Solución Rápida |
|---|---|---|
| SIS0042 | La firma calculada no es correcta | Clave SHA-256 errónea, espacios al pegar, o cruce entre clave de test y entorno de producción. |
| SIS0008 | Falta campo obligatorio | Falta el número de terminal (habitualmente 001 o 1) o el código de moneda (Euro = 978). |
| SIS0054 | Datos no coinciden con la orden | El número de pedido ya existe en Redsys. La pasarela no admite reutilizar un Ds_Merchant_Order previo. |
| SIS0075 | El número de pedido no es válido | El identificador de pedido debe tener entre 4 y 12 dígitos alfanuméricos y empezar obligatoriamente por dígitos. |
| SIS0026 | Comercio / FUC no encontrado | El banco aún no ha activado el TPV Virtual en sus servidores, o se introdujo un FUC de pruebas en producción. |
| SIS0253 | Fallo en la autenticación 3D Secure | El cliente no autorizó la operación en la app bancaria o caducó el tiempo de espera PSD2 (SCA). |
El misterio de los pedidos cobrados que quedan en "Pendiente de pago"
Este es el problema más desesperante para las tiendas online: el cliente ve el cargo en su cuenta corriente, pero en WooCommerce el pedido no pasa a "Procesando" y no se envía el email de confirmación.
¿Por qué ocurre esto?
Redsys utiliza un mecanismo llamado Notificación HTTP online (IPN). Cuando el usuario paga, el servidor del banco envía una petición HTTP POST directa por detrás a tu servidor con los datos del cobro. Si esta petición falla, WooCommerce nunca se entera de que el dinero ha sido cobrado.
Las 3 causas principales del bloqueo de notificaciones:
- Plugins de seguridad excesivamente restrictivos: Módulos como Wordfence, iThemes Security o All In One WP Security a veces clasifican las peticiones automáticas de Redsys como intentos de ataque bot y devuelven un código HTTP 403 Forbidden. Solución: añade a la lista blanca el rango de IPs oficiales de notificación de Redsys (
195.76.9.0/24). - Cortafuegos de Cloudflare o CDN: Si tu tienda pasa por Cloudflare con reglas de "Modo de ataque" o bloqueo de países, las IPs bancarias pueden quedar retenidas en un reto de verificación JavaScript que la pasarela no puede resolver.
- Redirecciones HTTP a HTTPS (301/302): Si en la configuración de Redsys la URL de notificación está definida con
http://y tu servidor fuerza una redirección 301 ahttps://, los datos POST se pierden en el salto de protocolo. Ambas URLs deben coincidir exactamente.
"Un fallo en la notificación IPN de Redsys no solo crea incidencias de soporte: si vendes productos con stock limitado o entradas numeradas, el sistema puede liberar el inventario a otro comprador mientras el primero ya pagó."
Cómo evitar errores de configuración con ExpressPay
El plugin oficial tradicional de Redsys suele tener pantallas de configuración dispersas y propensas a errores humanos.
Con ExpressPay la configuración está diseñada a prueba de fallos:
- Inspector de claves SHA-256 en tiempo real: Valida automáticamente que la clave introducida cumpla el formato Base64 exacto y descarta espacios en blanco accidentales que provocan el error SIS0042.
- Autodetección de entorno: Evita enviar peticiones reales al servidor de pruebas de Redsys o viceversa.
- Reintentos de notificación asíncrona: Si tu hosting sufre una microcaída en el momento exacto del cobro, ExpressPay gestiona la conciliación en cuanto se restablece la conexión para que ningún pedido se quede huérfano.
- Checkout nativo con Apple Pay y Google Pay: Tus clientes no necesitan rellenar formularios bancarios externos. Pagan con FaceID o huella dactilar directamente en tu tienda con la tarifa plana más rentable del mercado (39 €/año).
Preguntas Frecuentes sobre Errores en Redsys
¿Dónde se consulta el log de errores de Redsys en WooCommerce?
Puedes revisarlo en el panel de WordPress entrando en WooCommerce > Estado > Registros (Logs). En el desplegable superior busca los archivos que empiecen por redsys- o expresspay- para ver la respuesta exacta del servidor del banco en cada transacción.
¿Qué debo hacer si cambio de banco o de TPV Virtual?
Debes solicitar al nuevo banco tu nuevo FUC, número de terminal y generar la nueva clave secreta SHA-256 desde el panel del TPV del nuevo banco. Sustituye estos tres valores en la configuración de ExpressPay y la tienda empezará a cobrar en la nueva entidad inmediatamente.
¿Por qué Redsys rechaza pedidos cuando el cliente usa Bizum?
Para que los clientes puedan pagar por Bizum en el TPV Virtual, tu banco debe tener activado expresamente el servicio de Bizum en tu contrato de comercio. Si no está activado a nivel bancario, la opción de Bizum mostrará error de servicio denegado (SIS0051 o SIS0093).
Olvídate de los errores de pasarela con ExpressPay
Integra Apple Pay y Google Pay en tu WooCommerce con Redsys sin complicaciones técnicas, con validación de firmas y tarifa plana de 39 €/año.
Descubrir ExpressPay para Redsys