Herramientas testing integración TPV: guía práctica

Herramientas testing integración TPV: guía práctica

Validar que un TPV Redsys funciona correctamente antes de lanzar a producción no es opcional. Las herramientas de testing para integración TPV son precisamente las que permiten a desarrolladores y equipos técnicos detectar errores en la firma de parámetros, fallos en notificaciones server-to-server o problemas de configuración antes de que un cliente real intente pagar. Para negocios en Andorra que trabajan con Redsys como pasarela principal, elegir bien estas herramientas marca la diferencia entre un despliegue limpio y horas de diagnóstico en producción. En este artículo encontrarás los criterios de selección, las opciones más utilizadas, una comparativa directa y recomendaciones según tu perfil técnico.

Tabla de contenidos

• Puntos clave
• 1. Criterios clave para elegir herramientas de pruebas TPV
• 2. Selenium y Playwright para pruebas de interfaz
• 3. Postman para pruebas de API y validación de callbacks
• 4. Frameworks de pruebas unitarias para validar la firma
• 5. Ngrok y túneles para exponer entornos locales
• 6. Herramientas para codificación y depuración de parámetros
• 7. Comparativa práctica de herramientas para testing de integración TPV
• 8. Recomendaciones según tu perfil y situación
• 9. Consejos prácticos para pruebas efectivas antes de producción
• Mi perspectiva sobre el testing en integraciones Redsys
• Cómo Andorpay simplifica la integración y el testing sobre Redsys
• FAQ

Puntos clave

1. Criterios clave para elegir herramientas de pruebas TPV

Antes de instalar cualquier herramienta, conviene definir qué necesitas probar. La integración con Redsys tiene una arquitectura específica: el backend firma los parámetros, redirige al usuario al entorno del banco y espera notificaciones server-to-server en endpoints propios. Cada una de esas capas requiere un tipo de prueba distinto.

Estos son los criterios que deben guiar la selección:

• Compatibilidad con entornos Redsys. La herramienta debe funcionar contra los entornos SIS-t y SIS-d, no solo contra URLs genéricas.
• Simulación de pagos autorizados y rechazados. Las tarjetas de prueba del banco en SIS-t permiten testear ambos escenarios con números concretos y claves de encriptación específicas.
• Soporte para callbacks. La herramienta o el entorno deben permitir recibir y validar notificaciones POST del TPV.
• Integración en CI/CD. Si tu equipo despliega con frecuencia, los tests deben ejecutarse de forma automática sin intervención manual.
• Gestión segura de credenciales. Las claves del comercio no deben quedar expuestas en logs ni repositorios de código.
• Capacidad para pruebas de firma. Validar la firma HMAC-SHA256 contra vectores oficiales es uno de los tests más críticos de cualquier integración Redsys.
• Accesibilidad del entorno. Si trabajas en local, necesitas una solución para exponer tu endpoint de callback al exterior.

Consejo profesional: Empieza siempre revisando si tu firewall permite tráfico outbound al puerto 25443, que Redsys usa en el entorno de pruebas SIS. Es el error de configuración de red más frecuente y el más fácil de pasar por alto.

2. Selenium y Playwright para pruebas de interfaz

Selenium y Playwright para pruebas UI son las opciones más completas cuando necesitas simular el flujo completo de un usuario: desde que hace clic en “Pagar” hasta que ve la página de confirmación. Ambas herramientas pueden automatizar la navegación por el formulario de Redsys, introducir los datos de la tarjeta de prueba y verificar que la redirección OK o KO llega correctamente.

Playwright tiene una ventaja práctica sobre Selenium en integraciones modernas: maneja mejor las redirecciones entre dominios y los contextos de navegador aislados, lo que resulta útil cuando el flujo de pago salta entre tu dominio y el entorno de Redsys. Selenium sigue siendo válido si tu equipo ya tiene infraestructura de tests sobre esa base.

Estos frameworks no validan la lógica de firma del backend. Son la capa de prueba de extremo a extremo, complementaria a los tests unitarios.

3. Postman para pruebas de API y validación de callbacks

Postman es la herramienta más directa para probar los endpoints de tu integración sin necesidad de un navegador. Puedes enviar peticiones POST simulando la notificación server-to-server de Redsys, verificar que tu endpoint procesa correctamente los parámetros y devuelve el código de respuesta esperado.

Una colección de Postman bien estructurada para una integración Redsys debe incluir al menos tres tipos de petición: notificación de pago autorizado, notificación de pago rechazado, y petición con firma incorrecta para verificar que el sistema la rechaza. También puedes usar Postman para depurar el formato de los datos codificados en Base64 que Redsys requiere en algunos parámetros.

El entorno de variables de Postman permite separar credenciales de test y de producción sin riesgo de mezclarlas accidentalmente, lo que es especialmente útil para equipos que trabajan en paralelo sobre varios entornos.

4. Frameworks de pruebas unitarias para validar la firma

La firma HMAC-SHA256 sobre "Ds_MerchantParameters` es el núcleo de la seguridad en Redsys. Un test que valide esta firma contra vectores oficiales es probablemente el más importante de toda la suite.

Los frameworks de pruebas unitarias (JUnit, PHPUnit, xUnit, pytest o los equivalentes en tu stack) son la herramienta adecuada para este tipo de validación. No necesitas conectarte a ningún entorno externo: ejecutas la función de firma con entradas conocidas y verificas que el resultado coincide con el esperado. Esto te permite detectar cualquier cambio accidental en la lógica de firma antes de que llegue a producción.

Para proyectos .NET, existe una demo con pruebas anti-regresión que incluye escenarios como firma con vectores oficiales, firma incorrecta, errores de formato y casos donde Bizum no está activo en el terminal. Ese tipo de cobertura es el modelo a replicar en cualquier stack tecnológico.

5. Ngrok y túneles para exponer entornos locales

Cuando desarrollas en local, tu endpoint de callback no es accesible desde internet. Redsys no puede notificar pagos a localhost, así que necesitas una URL pública que apunte a tu servidor de desarrollo.

Ngrok resuelve esto creando un túnel temporal que expone tu servidor local con una URL HTTPS pública. Configuras esa URL como DS_MERCHANT_MERCHANTURL en el TPV virtual y Redsys puede enviarte notificaciones durante las pruebas. El proceso es sencillo: arrancas ngrok apuntando al puerto donde corre tu aplicación y copias la URL generada al entorno de test.

Existen alternativas a ngrok como Localtunnel o Cloudflare Tunnel, que ofrecen URLs más estables o sin límite de tiempo en sus versiones gratuitas. Para pruebas puntuales, ngrok funciona bien. Para un entorno de desarrollo compartido en equipo, conviene valorar una opción con URL fija.

6. Herramientas para codificación y depuración de parámetros

Redsys utiliza codificación Base64 y JSON para los parámetros del comercio, y errores en ese proceso son una fuente frecuente de fallos difíciles de diagnosticar. Herramientas como CyberChef o cualquier decodificador Base64 online permiten inspeccionar el contenido exacto de Ds_MerchantParameters durante las pruebas.

El flujo típico de depuración consiste en decodificar el valor Base64 del parámetro, verificar el JSON resultante campo por campo y compararlo con la especificación de Redsys. Este paso manual es especialmente útil cuando la firma falla y no está claro si el problema está en la codificación o en el cálculo del HMAC.

Para entornos con más volumen de pruebas, puedes automatizar esta validación con scripts propios que registren en logs el valor decodificado de cada transacción de test. Así puedes auditar después sin necesidad de repetir manualmente cada petición.

7. Comparativa práctica de herramientas para testing de integración TPV

La combinación más eficaz para la mayoría de proyectos es: tests unitarios de firma para la lógica del backend, Postman para validar los endpoints de callback, y Playwright para el flujo de usuario completo. Ngrok cubre la parte de infraestructura local.

Consejo profesional: No intentes cubrirlo todo con una sola herramienta. La automatización repetible de cada capa por separado detecta cambios silenciosos en firmas o formatos que una prueba end-to-end sola no atrapa.

8. Recomendaciones según tu perfil y situación

Las necesidades de un desarrollador técnico con pipeline CI/CD son distintas a las de un responsable de negocio que quiere verificar que los cobros funcionan antes de abrir una tienda online. Estas son las recomendaciones para cada perfil:

Para desarrolladores técnicos:

• Integra tests unitarios de firma en el pipeline desde el primer día.
• Usa Postman con colecciones versionadas para los tests de callback.
• Añade Playwright para pruebas end-to-end antes de cada despliegue a producción.
• Revisa que el entorno de test tiene acceso outbound al puerto 25443.

Para responsables de negocio sin equipo técnico propio:

• Verifica con tu proveedor de desarrollo que existe una suite de pruebas que cubre pagos autorizados y rechazados.
• Solicita evidencia de que el endpoint de callback recibe y procesa correctamente las notificaciones de Redsys.
• Confirma que las credenciales de test se han usado en SIS-t y que no se ha pasado a producción sin validación completa.

Un error habitual en ambos perfiles es activar Bizum en el formulario sin verificar que el terminal lo tiene activo contractualmente. El parámetro en el código no es suficiente. Este escenario debe estar cubierto explícitamente en los tests.

9. Consejos prácticos para pruebas efectivas antes de producción

Estos pasos concretos reducen los fallos más habituales en integraciones Redsys:

1. Configura correctamente los entornos SIS-t y SIS-d antes de escribir una sola línea de código de negocio. Las credenciales de test son distintas a las de producción y no son intercambiables.
2. Usa las tarjetas de prueba que proporciona el banco. Cada banco tiene números específicos para simular autorización y rechazo. No inventes datos de tarjeta.
3. Valida la firma con vectores oficiales antes de conectar con el entorno externo. Si la firma falla localmente, fallará en producción.
4. Prueba el endpoint de callback de forma independiente con Postman enviando notificaciones simuladas. No asumas que funciona porque el flujo visual parece correcto.
5. Verifica que el puerto 25443 está abierto en el firewall de tu servidor de desarrollo. Es la causa más frecuente de diagnóstico fallido en entorno SIS según problemas documentados.
6. Registra en logs cada transacción de test, incluyendo los parámetros decodificados. Esto acelera el diagnóstico cuando algo falla en una prueba concreta.
7. Automatiza los tests en tu pipeline CI/CD. La detección de cambios silenciosos en firmas o formatos solo es posible si los tests se ejecutan con cada cambio de código.

Consejo profesional: Mantén un entorno de staging lo más parecido posible a producción, con su propia URL pública y credenciales Redsys separadas. Esto elimina la categoría entera de errores que solo aparecen cuando el entorno cambia.

Mi perspectiva sobre el testing en integraciones Redsys

He visto más integraciones rotas por problemas de notificación que por errores en el código de firma. El flujo visual funciona: el usuario paga, la pantalla muestra “operación correcta”. Pero el backend nunca recibe la notificación, no marca el pedido como pagado, y el problema no se detecta hasta que un cliente real llama para reclamar. Ese escenario es el que más tiempo cuesta y el que más daño hace a la confianza del usuario.

Lo que aprendo constantemente es que la mayoría de equipos invierten en probar el código y muy poco en probar la infraestructura. Un puerto bloqueado, una URL de callback con trailing slash inesperado, o un timeout en el servidor que procesa notificaciones son invisibles para los tests de firma. Por eso insisto tanto en el valor de los beneficios de los SDKs y las capas de abstracción que ya cubren esos detalles.

Mi recomendación más práctica: dedica al menos un tercio de tu tiempo de testing a simular fallos, no solo flujos exitosos. Un test que demuestra que tu sistema rechaza correctamente una firma inválida vale más que diez que demuestran que el pago funciona cuando todo va bien.

— Andorpay

Cómo Andorpay simplifica la integración y el testing sobre Redsys

Si tu equipo ya está invirtiendo tiempo en probar una integración Redsys desde cero, merece la pena evaluar qué parte de ese trabajo puede evitarse con una capa de producto que ya gestiona esa complejidad.

Andorpay añade sobre Redsys una plataforma de billing y suscripciones similar a Stripe, con API y webhooks propios que abstraen los detalles de la integración bancaria. Esto significa que tu equipo no necesita construir ni testear la lógica de firma, los callbacks ni la gestión de estados de pago. Esa capa ya está validada y en funcionamiento para el mercado de Andorra. Puedes consultar las opciones disponibles en la página de planes de Andorpay o conocer en detalle la solución para TPV en Andorra.

FAQ

¿Qué entorno debo usar para probar una integración Redsys?

Usa el entorno SIS-t o SIS-d con las credenciales de test que proporciona tu banco adquiriente. Nunca hagas pruebas contra el entorno de producción.

¿Por qué Redsys no me envía las notificaciones de callback?

La causa más habitual es que la URL de callback no es pública. Redsys requiere una URL accesible desde internet para enviar notificaciones server-to-server. Usa ngrok u otro túnel si trabajas en local.

¿Cómo sé si mi firma HMAC-SHA256 es correcta?

Valida la función de firma contra los vectores oficiales que publica Redsys en su documentación técnica. Si el resultado coincide con el esperado para esos datos de entrada, la implementación es correcta.

¿Qué herramienta uso para probar los endpoints de mi integración?

Postman es la opción más directa. Crea una colección con peticiones que simulen notificaciones de pago autorizado, rechazado y con firma inválida para cubrir los escenarios críticos.

¿Es suficiente con probar el flujo visual del usuario?

No. Los fallos más comunes ocurren en la comunicación de notificaciones, no en la interfaz. El flujo visual puede parecer correcto mientras el backend no recibe ninguna confirmación de pago.

Recomendación

• Beneficios de los SDKs en la integración con TPV
• Blog de pagos en Andorra, Redsys y billing | Andorpay | Andorpay
• TPV Andorra | Capa tipo Stripe sobre Redsys | Andorpay
• Comisiones TPV banco: guía práctica para Andorra