Pruebas de 3D Secure: cómo funciona 3DS2 y tarjetas de prueba que activan cada flujo

3D Secure (3DS) es la capa de autenticación que traslada la responsabilidad del fraude de los comercios a los emisores. También es la parte de las pruebas de checkout que más se rompe, porque involucra redirecciones, iframes, SDKs móviles y resultados asíncronos. Esta guía cubre qué probar, qué tarjetas de prueba activan cada flujo y los errores que siempre se escapan.

De 3DS1 a 3DS2 en un párrafo

3DS1 era el flujo original de redirección en el navegador: el cliente salía de tu página, se autenticaba en la página del emisor y volvía con un resultado. Visa, Mastercard y American Express retiraron 3DS1 (3-D Secure 1.0.2) en octubre de 2022, y las últimas extensiones regionales terminaron en 2023, así que hoy los planes de prueba solo necesitan cubrir EMV 3DS (3DS2). 3DS2 envía al emisor muchos más datos del dispositivo y de la transacción, por lo que puede aprobar sin fricción (sin interacción del usuario) o lanzar un desafío. Tiene dos canales: un flujo de navegador, que recopila los datos del dispositivo mediante un iframe oculto de 3DS Method y muestra el desafío en un iframe (o en una redirección alojada por el proveedor), y un flujo de app que usa el SDK de 3DS en las apps móviles nativas.

Los tres resultados que debes manejar

Toda transacción 3DS termina de una de tres maneras, y las tres necesitan estados de interfaz explícitos:

1. Éxito sin fricción: la autenticación se completa sin interacción del usuario. Es el resultado más común de 3DS2.
2. Desafío: se le pide al cliente que se autentique (OTP, aprobación en la app). Maneja tanto el éxito como el fallo o la cancelación.
3. No inscrita / no soportada: la tarjeta o el emisor no participa. O bien no se ejecuta ninguna autenticación, o bien la red responde en nombre del emisor con un intento (attempt). Según la configuración de tu pasarela de pago, la transacción continúa o falla.

Internamente, cada resultado es un valor de transStatus: Y (autenticada), A (intento; normalmente sigue trasladando la responsabilidad al emisor), N (no autenticada), R (rechazada; no autorices), U (no disponible, un fallo técnico sin traslado de responsabilidad). C y D indican que un desafío o una autenticación desacoplada todavía está en curso.

Los caminos de error son donde los checkouts se rompen: un desafío cancelado no es lo mismo que un rechazo, y los usuarios que cierran el modal deben poder intentarlo de nuevo sin rehacer todo el carrito.

Tarjetas de prueba de Stripe para flujos 3DS

Stripe documenta números de prueba específicos para cada comportamiento de autenticación:

Están diseñadas solo para uso en sandbox. Para otros proveedores, Adyen documenta 4917 6100 0000 0000 (Visa inscrita en 3DS2; vencimiento 03/2030, CVC 737) para flujos de desafío, y 4111 1111 1111 1111 entre sus tarjetas de prueba Visa generales. Revisa siempre la documentación vigente del proveedor: el comportamiento de las tarjetas de prueba cambia sin aviso.

Hay una lista más completa en nuestra referencia de números de tarjetas de prueba.

Lista de verificación para configurar el sandbox

• Activa 3DS en el panel de la pasarela de pago, no solo en la llamada a la API. Muchas pasarelas tienen un interruptor por cuenta que desactiva la autenticación en modo de prueba sin avisar.
• Usa el SDK de 3DS2 en las apps nativas y prueba por separado el flujo de navegador (el iframe y cualquier redirección que use tu proveedor).
• Registra en la lista blanca las URLs de retorno de todos los entornos, incluidos los túneles de desarrollo local.
• Prueba en dispositivos móviles reales, no solo reduciendo la ventana en escritorio. Los navegadores integrados en apps (Instagram, TikTok, apps bancarias) se comportan distinto de Safari y Chrome.
• Mantén la ventana del desafío adaptable. Un desafío renderizado dentro de un iframe de altura fija es un clásico asesino de conversiones.

Errores que se escapan

• Perder el carrito en la redirección. Guarda el pedido antes de iniciar la autenticación, no después.
• No manejar el botón de atrás. Los navegadores restauran la página desde la bfcache; tu JavaScript debe volver a consultar el estado del pago en lugar de asumir que la página se cargó de cero.
• Doble envío. Los usuarios hacen clic dos veces en "Pagar" mientras el desafío está abierto. Usa claves de idempotencia en la solicitud de autorización.
• Asumir el éxito después del desafío. El resultado de la autenticación es una señal aparte; la autorización todavía puede rechazarse después.
• Ignorar los webhooks asíncronos. Algunos flujos 3DS2 terminan de forma asíncrona. Si solo escuchas la redirección, te vas a perder resultados.
• Monto o moneda incorrectos. La autenticación cubre el monto y la moneda que enviaste; si el carrito cambia, vuelve a autenticar (en Stripe, cambiar el monto de un PaymentIntent obliga a confirmarlo de nuevo).

Cómo probar sin tarjetas reales

No necesitas una tarjeta real para probar 3DS. Las tarjetas de prueba del proveedor más datos generados cubren toda la matriz:

1. Usa las tarjetas del proveedor para los flujos de éxito autenticado, fallo y sin fricción.
2. Usa nuestro generador de tarjetas para producir grandes volúmenes de números estructuralmente válidos para pruebas de carga, fuzzing e interfaz.
3. Usa el generador avanzado cuando necesites todas las combinaciones de un patrón específico.
4. Valida cualquier número de prueba con el validador de Luhn.

Resumen

Las pruebas de 3DS se centran sobre todo en cubrir los caminos difíciles: desafíos cancelados, autenticación fallida, resultados asíncronos y navegadores móviles. Las tarjetas de prueba del proveedor activan cada flujo de forma deliberada y un conjunto de datos generado cubre los huecos. Trata la autenticación como una máquina de estados separada de la autorización y evitarás la mayoría de los incidentes en producción.