Pruebas de 3D Secure: 3DS1 vs 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.
3DS1 vs 3DS2 en un párrafo
3DS1 es el flujo original de redirección en el navegador: el cliente sale de tu página, se autentica en la página del emisor y vuelve con un resultado. 3DS2 reemplaza la redirección por un SDK o la huella del dispositivo: el emisor recibe datos adicionales del dispositivo y de la transacción y puede aprobar sin fricción (sin interacción del usuario) o lanzar un desafío (un modal dentro de la página, o una redirección como respaldo en los navegadores que no soportan el SDK). La mayoría de las pasarelas de pago todavía admiten 3DS1 para integraciones antiguas, así que un plan de pruebas real cubre ambos.
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:
- Éxito sin fricción: la autenticación se completa sin interacción del usuario. Es el resultado más común de 3DS2.
- 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.
- No inscrita / no soportada: la tarjeta no participa. Según la configuración de tu pasarela de pago, la transacción continúa o falla.
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:
| Número de tarjeta | Qué activa |
|---|---|
| 4000 0025 0000 3155 | Requiere autenticación 3D Secure |
| 4000 0027 6000 3184 | Requiere 3DS para que el pago se complete |
| 4000 0000 0000 3055 | Admite 3D Secure 2 |
| 4000 0000 0000 3220 | 3DS2: obliga a completar el flujo de desafío |
Están diseñadas solo para uso en sandbox. Para otros proveedores, Adyen documenta 4917 6100 0000 0000 para escenarios 3DS1, además de las tarjetas genéricas de éxito (4242…, 4111 1111 1111 1111) en su sandbox. 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 cuando esté disponible y prueba por separado el respaldo por redirección.
- 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 está vinculada a la intención de pago; cambiar el carrito entre la autenticación y la captura la invalida.
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:
- Usa las tarjetas del proveedor para los flujos de éxito autenticado, fallo y sin fricción.
- Usa nuestro generador de tarjetas para producir grandes volúmenes de números estructuralmente válidos para pruebas de carga, fuzzing e interfaz.
- Usa el generador avanzado cuando necesites todas las combinaciones de un patrón específico.
- 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.