SIS0042: la firma enviada no es correcta.

El error de integración más famoso de Redsys. Casi siempre es la clave o el entorno; el resto de veces, el encoding. Vamos a cazarlo.

Qué está pasando técnicamente.

Cada petición al TPV virtual viaja con tres campos: Ds_MerchantParameters (tus datos de pago en JSON codificado en Base64), Ds_Signature (la firma) y la versión de firma. La firma se genera derivando una clave por operación — cifrado 3DES del número de pedido con tu clave secreta SHA-256 — y calculando el HMAC-SHA256 de los parámetros con esa clave derivada. Si lo que Redsys calcula no coincide con tu Ds_Signature, responde SIS0042 y no procesa. Cualquier byte distinto — en la clave, el pedido o los parámetros — rompe la coincidencia.

Diagnóstico en orden de probabilidad.

  1. Clave del entorno equivocado (el clásico): la clave de pruebas firma contra sis-t y la de producción contra sis. Comprueba el par clave↔URL. Si acabas de pasar a producción, este es tu caso con un 90% de probabilidad.
  2. Clave mal copiada: espacios al inicio/fin, saltos de línea del gestor de contraseñas o clave truncada. Vuelve a copiarla desde el panel del banco, a mano y con cuidado.
  3. Pedido inconsistente: el Ds_Merchant_Order usado para derivar la clave debe ser byte a byte el mismo que va dentro de los parámetros. Formatos válidos: 4-12 caracteres, empezando por 4 dígitos.
  4. Encoding de los parámetros: el JSON debe codificarse en Base64 estándar y el HMAC calcularse sobre exactamente esa cadena. Caracteres especiales en descripciones o URLs (ñ, tildes, &) delatan diferencias de encoding — prueba con un pedido de descripción ASCII pura para aislar.
  5. Módulo o librería antiguos: firmas SHA-1 de la época pre-2015 o librerías sin mantener. Actualiza el plugin de WooCommerce / módulo de PrestaShop o usa la librería oficial de tu lenguaje.

Cómo depurarlo de verdad.

  • Reproduce en el sandbox con las tarjetas de prueba y la clave de test: si en test firma bien y en producción no, es la clave/entorno al configurar los entornos, caso cerrado.
  • Firma un caso de laboratorio: pedido fijo, importe fijo, sin caracteres especiales. Compara tu firma con la que genera la librería oficial de Redsys para los mismos datos — si difieren, el bug está en tu derivación 3DES o tu HMAC.
  • Registra lo que firmas: loguea (en desarrollo) la cadena Base64 exacta firmada. La mayoría de casos «imposibles» se resuelven viendo que lo firmado no es lo enviado.

Para que no vuelva.

  • Guarda las claves de test y producción en variables de entorno separadas con nombres inequívocos.
  • Añade un test automático de firma con datos conocidos a tu CI: detecta regresiones al actualizar dependencias.
  • Tras cada rotación de claves del banco, ten un procedimiento de despliegue — no un «lo cambio en el panel y ya».

Transparencia: esta página contiene enlaces de afiliado a MONEI. Si contratas a través de ellos, recibimos una comisión sin coste extra para ti. Nuestro compromiso: las fuentes, fechas y supuestos de cálculo se muestran de forma visible para que puedas comprobarlos y comparar el coste completo por tu cuenta.

Preguntas frecuentes.

¿Qué significa el error SIS0042 de Redsys?

«La firma enviada no es correcta»: la firma HMAC-SHA256 que tu servidor calculó sobre los parámetros del pago no coincide con la que Redsys calcula con la clave de tu comercio. Redsys rechaza la petición antes de procesar nada — es un error de integración, no del cliente ni de su tarjeta.

¿Cómo se soluciona el SIS0042?

El 90% de los casos: estás firmando con la clave del entorno equivocado (test en producción o viceversa) o la clave se copió mal. El resto: parámetros mal codificados (el Base64 de Ds_MerchantParameters), el número de pedido usado en la derivación no coincide con el del mensaje, o un módulo desactualizado que firma con SHA-1. Verifica clave+entorno al configurar, regenera la firma y prueba en sandbox.

¿Por qué SIS0042 aparece solo a veces?

Un SIS0042 intermitente apunta a caracteres especiales: descripciones de pedido o URLs con caracteres que tu código codifica distinto a lo que firma (encoding UTF-8 vs otros, saltos de línea, espacios). También a instalaciones con varios idiomas/monedas donde algún flujo usa parámetros distintos de los firmados.

¿El SIS0042 puede cobrar al cliente?

No: la operación se rechaza antes de llegar al banco emisor. El cliente no ve cargo ni retención — solo tu pasarela devolviéndole un error. Por eso es un error «barato» de tener en test y carísimo en producción: cada aparición es un pago con tarjeta que no pudo ni intentarse.

Relacionado: SIS0051 (pedido repetido),Redsys no funciona: diagnóstico general oel sandbox y sus tarjetas de prueba.