3D Secure suele presentarse como una etapa adicional de seguridad para las compras con tarjeta. La definición es correcta, pero incompleta. En operaciones modernas, 3DS también influye en la experiencia, la responsabilidad, los datos de riesgo, la tasa de aprobación y el diseño de la integración.
La discusión ya no consiste simplemente en activar o desactivar la autenticación. El verdadero problema es decidir cuándo autenticar, qué datos enviar, cómo gestionar los flujos frictionless y challenge, cómo interpretar el resultado y cómo conectar la autenticación con el resto de la infraestructura de pagos.
Mal implementado, 3DS puede añadir fricción sin un beneficio claro. Bien integrado, puede aumentar la confianza en el flujo y aportar más contexto a las decisiones de autorización y riesgo.
¿Qué es 3D Secure?
3D Secure, o 3DS, es un protocolo de autenticación para pagos con tarjeta que crea un intercambio adicional de información entre participantes del ecosistema antes o durante la autorización.
La versión moderna del protocolo se diseñó para permitir la autenticación basada en riesgo, reduciendo la necesidad de interacción directa del titular en transacciones consideradas de menor riesgo y activando pasos adicionales cuando sea necesario.
En la práctica, el comercio y su infraestructura envían datos de la transacción y del contexto de compra. Estos datos se evalúan dentro del ecosistema de autenticación y pueden dar lugar a un flujo sin desafío visible o a una etapa de confirmación con el cliente.
¿3DS es lo mismo que antifraude?
No.
El antifraude y 3DS pueden utilizar señales de riesgo, pero cumplen funciones distintas.
Una solución antifraude suele evaluar la probabilidad de que una transacción sea fraudulenta según modelos, reglas y contexto del comercio o proveedor. 3DS es un protocolo de autenticación vinculado al ecosistema de tarjetas y al emisor.
Ambos pueden coexistir.
Una operación puede analizar el riesgo internamente, decidir solicitar 3DS en determinados casos y seguir utilizando otros controles antes o después de la autenticación.
La documentación de AZPay presenta antifraude, 3DS y zero-auth como capas complementarias de seguridad, no como sustitutos entre sí.
¿Qué es un flujo frictionless?
Frictionless es el flujo en el que la autenticación se realiza sin exigir una interacción adicional perceptible del titular.
El sistema envía contexto suficiente para que la evaluación de riesgo permita completar la autenticación sin challenge.
Para el usuario, la experiencia puede parecerse a un checkout normal. La diferencia está en los datos y mensajes intercambiados entre comercio, infraestructura 3DS, red de tarjetas y emisor.
Esta posibilidad es una de las razones por las que importa tanto la calidad de los datos enviados. Cuanto más coherente y completo sea el contexto, mayor será la capacidad del ecosistema para tomar una decisión basada en riesgo.
¿Qué es un challenge?
El challenge es el flujo en el que el titular debe realizar una etapa adicional de autenticación.
Puede incluir una confirmación en la aplicación del banco, biometría, un código, una contraseña u otro método admitido por el emisor.
El challenge añade fricción porque interrumpe la secuencia directa del checkout. Pero existe precisamente para situaciones en las que el emisor necesita más confianza antes de autenticar la transacción.
La experiencia debe tratarse como parte del producto. Si la aplicación no puede abrir, reanudar o interpretar correctamente el challenge, una autenticación técnicamente válida puede convertirse en abandono.
¿Quién decide si habrá challenge?
El comercio puede influir en el flujo mediante datos, preferencias y reglas permitidas, pero la decisión final depende del ecosistema 3DS y del emisor.
Esto importa porque algunos equipos tratan 3DS como una regla determinista del frontend: si se activa, aparece una pantalla; si se desactiva, no aparece.
El comportamiento real es más dinámico.
Una misma integración puede producir frictionless en una transacción y challenge en otra, según el riesgo, el contexto, el mercado y la decisión del emisor.
La aplicación debe estar preparada para ambos.
¿Qué es data-only 3DS?
Data-only es un enfoque en el que se comparten datos del contexto de la transacción para apoyar la evaluación de riesgo sin ejecutar necesariamente el flujo completo de autenticación con challenge.
Puede ser útil en estrategias de rendimiento y aprobación cuando la infraestructura y los participantes admiten este modelo.
La documentación de AZPay incluye una integración específica de Data-Only 3DS, además del flujo completo de 3DS.
Esto muestra una distinción importante: compartir señales y autenticar no son exactamente lo mismo.
El diseño debe considerar qué resultado necesita obtener la operación y qué capacidades están disponibles en cada ruta.
¿3DS aumenta la tasa de aprobación?
Puede aumentarla en algunos contextos, pero no existe una regla universal.
La autenticación adicional puede dar al emisor más confianza en la identidad del titular y reducir determinados riesgos. En algunos escenarios, puede favorecer la decisión de autorización.
Al mismo tiempo, el challenge añade fricción y puede generar abandono. Una mala integración puede perder conversión antes de llegar a la autorización.
Por eso, medir solo la tasa de aprobación es insuficiente.
La operación debe seguir la conversión completa: inicio del checkout, intento de autenticación, frictionless o challenge, finalización del challenge, autorización y compra completada.
¿Seguridad y conversión son opuestas?
No tienen por qué serlo.
La falsa elección entre seguridad y conversión aparece cuando cada control se trata como un paso fijo que se aplica por igual a todas las transacciones.
Los modelos basados en riesgo buscan precisamente aplicar más fricción donde hace falta y menos donde existe suficiente confianza.
El objetivo no es quitar controles para aumentar la conversión. Es utilizar el contexto para que el nivel de control sea proporcional al riesgo y a las reglas del ecosistema.
Una infraestructura madura mide el coste de cada etapa sin tratar la seguridad como un obstáculo inevitable.
¿Qué datos influyen en el flujo 3DS?
El protocolo puede utilizar información de la transacción, del navegador o dispositivo, del comercio y del titular, según el flujo y la implementación.
Los datos incoherentes, ausentes o incorrectos reducen la calidad del contexto que llega a los participantes.
Por eso, campos aparentemente técnicos como device information no deberían enviarse solo para completar un esquema. Representan señales que pueden intervenir en la decisión de autenticación.
La documentación de AZPay incluye campos device_info y parámetros relacionados con 3DS al crear cobros, lo que refuerza que la autenticación debe integrarse en el contexto completo del pago.
¿Qué ocurre después de la autenticación?
3DS no sustituye a la autorización financiera.
Una transacción puede estar autenticada y aun así ser rechazada por el emisor debido al saldo, un límite, un bloqueo u otra regla.
La autenticación responde a una pregunta sobre identidad y confianza en el contexto. La autorización responde a si esa transacción financiera puede continuar.
Mezclar estos estados dificulta el diagnóstico.
La aplicación debe saber si falló la autenticación, si se abandonó el challenge o si la autenticación se completó y la autorización financiera se denegó después.
Son problemas distintos que exigen acciones distintas.
¿Cómo se relaciona 3DS con el antifraude?
Una estrategia de riesgo puede utilizar el antifraude para decidir cuándo exigir una autenticación más fuerte, permitir un flujo más sencillo o bloquear una transacción antes de enviarla al procesador.
El diseño concreto depende de las herramientas y reglas del comercio.
El resultado de 3DS también puede convertirse en una señal adicional para decisiones posteriores.
Lo importante es evitar duplicar responsabilidades sin claridad. Si varias capas toman decisiones de riesgo sin compartir contexto, la experiencia puede resultar incoherente.
La arquitectura de riesgo necesita un orden y responsabilidades explícitos.
¿Qué significa liability shift?
En determinados contextos de red de tarjetas y autenticación, el uso satisfactorio de 3DS puede modificar la responsabilidad por ciertos tipos de fraude.
Este concepto se conoce como liability shift o traslado de responsabilidad.
Las reglas concretas dependen de la red, el mercado, el tipo de transacción y el resultado del protocolo. Por eso, no es adecuado tratarlo como una garantía automática siempre que 3DS aparece en el flujo.
Para el comercio, lo relevante es que la autenticación puede tener efectos más allá de la aprobación inmediata. También interviene en el modelo de responsabilidad del ecosistema.
Las reglas vigentes deben comprobarse siempre en las fuentes oficiales aplicables.
¿Es obligatorio 3DS?
Depende del mercado, del tipo de transacción y de las reglas aplicables.
Las regiones con requisitos de autenticación reforzada pueden hacer que 3DS sea especialmente relevante, mientras otros mercados tienen dinámicas diferentes.
También existen excepciones, exenciones y tratamientos específicos.
Una plataforma global no debería asumir que una sola regla vale para todos los países.
Esto importa para la orquestación: la ruta elegida debe ser compatible no solo con el método y la moneda, sino también con los requisitos de autenticación de ese contexto.
¿Qué cambia en una arquitectura multi-PSP?
En una operación multi-PSP, la autenticación y el procesamiento pueden estar acoplados de distinta manera según el proveedor.
Si una transacción se autenticó en un contexto determinado y después cambia la ruta de autorización, la infraestructura debe saber qué datos y resultados siguen siendo válidos en la nueva ruta.
Cambiar de procesador después de 3DS no debería tratarse como un simple reintento sin contexto.
La compatibilidad entre autenticación, token, adquirente y proveedor debe conocerse antes de implementar failover.
Este es uno de los motivos por los que el smart routing debe considerar capacidades y no solo el rendimiento histórico.
¿Puede 3DS formar parte del enrutamiento?
Sí, como restricción o señal.
Un motor puede saber que una ruta admite una modalidad específica de autenticación, que otro proveedor tiene requisitos distintos o que un mercado exige un comportamiento determinado.
Esto no significa elegir la ruta exclusivamente para evitar la autenticación.
Significa incluir la autenticación en la matriz de capacidades de la ruta.
Una decisión de enrutamiento que ignore el estado de 3DS puede enviar una transacción a un camino incapaz de completar correctamente el flujo.
¿Qué medir en 3DS?
La primera métrica es la proporción de transacciones enviadas a 3DS.
Después conviene separar frictionless y challenge, la tasa de finalización del challenge, el abandono, el fallo técnico, la autenticación aprobada, la autenticación rechazada y la autorización posterior.
También es importante comparar la conversión final entre grupos y contextos distintos.
Las métricas agregadas pueden ocultar problemas. Un PSP puede tener buena aprobación financiera, pero baja finalización del challenge en un dispositivo concreto. Otro puede tener una mayor proporción de frictionless porque recibe datos más completos.
La observabilidad debe seguir todo el recorrido.
¿Cómo diagnosticar una caída de conversión tras activar 3DS?
Primero separa autenticación y autorización.
Comprueba cuántas transacciones entran en challenge y cuántas lo completan. Analiza si el abandono se concentra en navegadores, dispositivos, emisores o mercados concretos.
Después investiga fallos técnicos: callbacks, redirecciones, pérdida de sesión, timeouts y errores de integración.
Solo entonces compara el resultado financiero.
Sin esta descomposición, es fácil atribuir toda la caída al protocolo cuando el problema puede estar en la implementación del challenge.
Checkout integrado y 3DS
El checkout integrado busca mantener al cliente dentro de la experiencia del comercio. Esto no elimina los pasos externos necesarios para la autenticación.
El reto de producto consiste en integrar esos pasos sin romper el contexto.
El usuario debe entender que se está realizando una confirmación y poder volver al checkout con el estado correcto.
En móvil, esto puede implicar cambiar de aplicación. En la web, puede implicar componentes y redirecciones.
La experiencia debe conservar el pedido y evitar que el usuario genere un nuevo intento al volver.
La idempotencia sigue siendo importante
Imagina que el cliente completa un challenge, pero la aplicación sufre un timeout al reanudar el flujo.
Si el checkout crea inmediatamente un nuevo cobro, puede producir una duplicidad o una segunda autenticación innecesaria.
La infraestructura debe correlacionar la sesión de checkout, la autenticación y la intención de pago.
Las claves de idempotencia, las consultas de estado y los eventos asíncronos ayudan a mantener esa relación coherente.
3DS añade estados; no elimina la necesidad de controlar los intentos.
Webhooks y 3DS
El estado final del cobro puede seguir evolucionando después del flujo de autenticación.
Los webhooks ayudan a sincronizar la aplicación con cambios posteriores del pago.
Por eso, el comercio no debería utilizar únicamente el retorno visual del challenge como fuente final del estado financiero.
La experiencia puede informar al usuario de que se está procesando el pago mientras la infraestructura espera la confirmación definitiva.
Separar la interfaz del estado financiero evita mensajes incorrectos.
3DS en pagos recurrentes
La primera compra de una suscripción puede contar con la presencia del cliente y un flujo de autenticación. Los cobros futuros pueden producirse en otro contexto operativo.
La infraestructura debe representar correctamente que existe una relación de credencial almacenada y recurrencia.
Esto influye en cómo interpretan los participantes las transacciones posteriores.
Intentar ejecutar cada cobro recurrente como si fuera una nueva compra interactiva puede generar fricción o incompatibilidad con el modelo de negocio.
La recurrencia exige establecer correctamente la relación desde el primer pago.
3DS y network tokens
Tokenización y autenticación son capas distintas, pero pueden combinarse.
Los network tokens representan credenciales dentro del ecosistema de las redes y pueden incorporar sus propios elementos dinámicos de seguridad. 3DS autentica el contexto de la compra.
Una operación avanzada puede utilizar ambos según las capacidades de la ruta y del mercado.
La documentación de AZPay mantiene contenidos separados para 3DS, Data-Only y Network Token, lo que ayuda a mostrar que cada mecanismo resuelve una parte distinta del problema.
Cuándo no forzar un challenge
Forzar fricción innecesaria puede empeorar la experiencia.
Cuando el protocolo y las reglas permiten la evaluación basada en riesgo, el objetivo debería ser ofrecer contexto suficiente para que la autenticación sea proporcional a la transacción.
Esto no significa buscar atajos de seguridad.
Significa aprovechar el diseño moderno de 3DS en lugar de reproducir una mentalidad de autenticación fija para cada compra.
La mejor experiencia es la que sigue siendo segura sin exigir acciones innecesarias al usuario.
¿Qué admite AZPay en este ámbito?
La documentación de AZPay incluye 3DS en cobros con tarjeta, el flujo completo de autenticación, Data-Only 3DS, device information e integración con otras capacidades de seguridad, como antifraude y zero-auth.
Esto permite que la autenticación forme parte de la infraestructura de pagos, en lugar de tratarse como un componente aislado del checkout.
Para el comercio, la ventaja arquitectónica está en observar 3DS junto con autorización, tasa de aprobación, riesgo y enrutamiento.
¿Cómo implementarlo sin perder el control de la experiencia?
Empieza por tratar 3DS como una máquina de estados, no como una ventana emergente.
La aplicación debe saber cuándo se inició la autenticación, cuándo exige un challenge, cuándo se completó, cuándo falló y cuándo puede continuar el pago.
Conserva los identificadores entre estas etapas. Garantiza que los reintentos no creen nuevas intenciones comerciales. Mantén el estado del pedido independiente del componente visual. Supervisa cada transición.
Y, sobre todo, no lo ocultes todo dentro de una única métrica de aprobación.
3DS es infraestructura de confianza
El valor de 3DS no está en añadir una pantalla extra al checkout. Está en crear un intercambio estructurado de señales y autenticación dentro del ecosistema de tarjetas.
Esto puede influir en la seguridad, la responsabilidad, la experiencia y la decisión de autorización.
Para aprovechar ese valor, la empresa debe integrar el protocolo con el resto de la arquitectura: antifraude, tokenización, recurrencia, enrutamiento, observabilidad y estado del pago.
Tratado así, 3DS deja de ser una obligación aislada y pasa a ser una capa de confianza dentro de una infraestructura de pagos más amplia.