Un pedido queda como pendiente, el cliente ve un mensaje de pago no completado y en el registro aparece un rechazo de SIS. Si buscas resolver rechazo SIS en WordPress, el dato decisivo no es el texto genérico que recibe el comprador, sino la respuesta concreta que devuelve la pasarela y el punto exacto en que se interrumpe la operación.
En proyectos con RedSys, SIS suele referirse al sistema de pago seguro que procesa la transacción. Un rechazo puede ser una decisión legítima del banco emisor, una configuración incompleta del comercio o un problema al validar la respuesta en WordPress. Tratar todos los casos como si fueran un fallo del plugin lleva a cambios innecesarios y, a veces, a perder pedidos que sí se habían autorizado.
Primero: separa un rechazo bancario de un fallo técnico
Antes de modificar claves, plantillas o estados de pedido, confirma qué ha ocurrido en el flujo de pago. Hay tres situaciones habituales. La primera es que el cliente no complete la autenticación o su banco deniegue la operación. La segunda es que RedSys reciba datos incompatibles con la configuración del terminal. La tercera es que el cobro se autorice, pero WordPress no procese correctamente la notificación o el retorno.
La diferencia es relevante. Si el banco ha rechazado la tarjeta por fondos, límites, autenticación o políticas antifraude, no existe un ajuste de WordPress que deba forzar el pago. El objetivo es informar al cliente sin revelar datos sensibles y ofrecerle que pruebe otra tarjeta o método autorizado. Si el rechazo procede de la integración, en cambio, hay que revisar parámetros, firma y entorno.
No te guíes solo por el estado de WooCommerce. Un pedido marcado como fallido puede corresponder a un rechazo real, pero también a una notificación que no llegó o cuya firma no fue válida. Consulta el registro del método de pago, la respuesta recibida de la pasarela y, cuando sea posible, el panel bancario. Conserva el identificador de pedido y el código de respuesta para cruzar la información sin almacenar datos de tarjeta.
Datos que debes revisar antes de cambiar nada
Un diagnóstico rápido empieza por una operación concreta. Anota la fecha y hora, el número de pedido de WordPress, el identificador enviado a RedSys, el importe, la moneda, el terminal y el código de respuesta. Con eso se puede determinar si el problema afecta a un cliente aislado o a toda la tienda.
Revisa además estos puntos, en este orden:
- El entorno activo: pruebas y producción usan credenciales, terminales y claves diferentes.
- El código de comercio, el número de terminal y la moneda configurados en WordPress.
- El número de pedido enviado a la pasarela y su formato permitido por tu entidad bancaria.
- La clave secreta y el método de firma compatible con la versión de la integración.
- La URL de notificación, el acceso público a WordPress y los registros del servidor durante el intento de pago.
Este orden evita un error frecuente: sustituir la clave secreta porque un cliente no pudo pagar. La clave solo debe cambiarse cuando haya evidencia de una firma incorrecta, credenciales equivocadas o un cambio comunicado por el banco.
Códigos de respuesta: contexto antes que interpretación
RedSys devuelve códigos que permiten clasificar la operación. Los códigos de autorización suelen indicar que el pago fue aceptado, mientras que otros reflejan denegaciones, errores de formato, problemas de autenticación o restricciones del terminal. La descripción exacta depende de la documentación de la entidad y de la versión de la pasarela, por lo que no conviene asumir el significado de un número visto en un foro antiguo.
Si varios clientes reciben el mismo rechazo inmediatamente después de una actualización, un cambio de PHP o una migración de hosting, la causa probablemente es técnica. Si solo falla una tarjeta y otras compras se completan con normalidad, el origen suele estar en el banco emisor o en la autenticación del titular. Esa comparación ahorra muchas horas de depuración.
Cómo resolver un rechazo SIS en WordPress paso a paso
Empieza reproduciendo el caso en un entorno controlado, preferiblemente con credenciales de prueba proporcionadas por el banco. No pruebes pagos reales repetidos con la misma tarjeta para intentar adivinar la causa: puedes generar bloqueos antifraude, duplicidades o confusión en la conciliación.
Comprueba que el sitio usa HTTPS en el checkout y que no hay redirecciones inesperadas entre el dominio configurado y otro dominio con o sin www. La pasarela debe recibir los datos esperados y el cliente debe volver a una URL válida. Una regla de caché agresiva, un plugin de seguridad que bloquee peticiones externas o una redirección mal planteada puede interferir en la comunicación posterior al pago.
Después, valida la configuración del terminal. El FUC o código de comercio, el terminal, la moneda y el tipo de operación deben coincidir con los datos activados por el banco. También hay que verificar que el terminal esté habilitado para comercio electrónico y para las modalidades que se quieren utilizar. Por ejemplo, una configuración estándar no implica necesariamente que estén permitidos pagos recurrentes, tokenización, Bizum o ciertas opciones de autenticación.
La firma merece una revisión independiente. RedSys no valida una clave secreta enviada directamente como texto plano: la integración debe generar la firma según el algoritmo y la versión requerida. Un plugin desactualizado, una clave copiada con espacios o la mezcla de una clave de pruebas con un terminal de producción provocan rechazos o respuestas que WordPress no puede verificar. No pegues la clave en tickets, capturas ni registros públicos.
Por último, revisa la notificación del servidor. El retorno del navegador depende de que el cliente termine la redirección; la notificación es la confirmación que debe permitir actualizar el pedido incluso si el usuario cierra la pestaña. La URL debe ser accesible desde fuera, no requerir inicio de sesión, no estar bloqueada por firewall y responder sin errores de PHP. Si el cobro figura como autorizado en RedSys, pero el pedido sigue pendiente, este es el punto más probable de fallo.
Pedidos duplicados, pendientes y pagos ya autorizados
No canceles de forma automática un pedido solo porque el usuario regrese a la tienda con un mensaje de error. Primero verifica en el panel de la pasarela si existe autorización. En ocasiones el cliente percibe una pantalla incompleta, vuelve a intentar pagar y termina generando dos operaciones: una autorizada y otra rechazada, o incluso dos autorizadas.
Configura una gestión clara para los pedidos pendientes. El pedido debe conservar el identificador de transacción cuando exista, y el equipo debe poder distinguir entre pago no iniciado, pago rechazado, pago autorizado pendiente de notificación y pago completado. Esta trazabilidad es especialmente necesaria en reservas, donaciones y venta de entradas, donde una duplicidad puede afectar plazas, inventario o confirmaciones automáticas.
Errores de WordPress que parecen un rechazo de SIS
No todo lo que sucede en la página de pago viene de RedSys. Los conflictos de JavaScript pueden impedir que el formulario se envíe correctamente. Las extensiones que personalizan el checkout pueden alterar campos requeridos, importes o sesiones. También puede haber problemas si una capa de caché sirve una página antigua con un nonce caducado o si la sesión del cliente se pierde durante la redirección.
Actualiza WordPress, WooCommerce y la extensión de pago dentro de un proceso controlado, con copia de seguridad y pruebas previas si la tienda tiene volumen. Desactivar plugins al azar en producción no es una estrategia de diagnóstico: puede ocultar la causa, afectar otros cobros o dejar datos de pedidos en un estado inconsistente.
Revisa los logs de WooCommerce y del servidor buscando errores en la misma franja horaria. Un error fatal, una respuesta 403 en la URL de notificación o una limitación del hosting puede dar una explicación más fiable que el mensaje mostrado en pantalla. Si usas un plugin específico para RedSys, Bizum, formularios o reservas, verifica también que la versión sea compatible con tu versión de PHP y con las APIs actuales de la plataforma.
Cuándo escalar el caso al banco o al soporte técnico
Contacta con la entidad bancaria cuando el registro confirme un código de denegación emitido por la pasarela y la configuración del comercio sea correcta. Facilita fecha, importe, terminal, número de pedido e identificador de operación, pero nunca datos completos de tarjeta ni la clave de firma. El banco puede confirmar si el terminal tiene una restricción activa o si el rechazo procede del emisor.
Necesitas soporte técnico especializado cuando hay firmas inválidas, respuestas que no actualizan pedidos, incompatibilidades tras una actualización o requisitos fuera del flujo estándar. En instalaciones que combinan WooCommerce con reservas, donaciones, entradas o formularios, la integración debe respetar el ciclo propio de cada plugin. Codection trabaja precisamente con extensiones de pago para estos escenarios y puede ayudar cuando la configuración estándar no cubre el caso.
Un rechazo SIS bien diagnosticado no se resuelve cambiando opciones hasta que algo funcione. Se resuelve siguiendo el rastro de la operación, protegiendo los datos sensibles y corrigiendo solo el componente que realmente falló. Así se recupera la capacidad de cobro sin convertir cada pago fallido en una incidencia incierta.