Servidor de Control de Acceso EMV 3DS: Passkeys, FIDO y SPC

El panorama de la autenticación de pagos en línea está experimentando una transformación importante, impulsada por la doble necesidad de reforzar la seguridad frente a fraudes sofisticados y de mejorar la experiencia del usuario para reducir la fricción y el abandono de carritos de compra. El protocolo EMV® 3-D Secure (3DS), especialmente en sus versiones más recientes (EMV 3DS 2.x), es la tecnología fundamental para autenticar transacciones de tarjeta no presente (CNP) en todo el mundo. Gestionado por EMVCo, este protocolo facilita el intercambio de datos entre comercios, emisores (a través de su Servidor de Control de Acceso o ACS) y el dominio de interoperabilidad (servidores de directorio operados por los esquemas de pago) para verificar la identidad del titular de la tarjeta.

Dentro de este marco, están surgiendo dos avances tecnológicos clave relacionados con los estándares de la Alianza FIDO (Fast Identity Online):

1. El uso de datos de autenticación FIDO generados durante interacciones previas del usuario (por ejemplo, al iniciar sesión en un comercio) para enriquecer la evaluación de riesgos en el flujo sin fricción de EMV 3DS.
2. La integración de Secure Payment Confirmation (SPC), un estándar web del W3C basado en FIDO/WebAuthn, como un método de "desafío" optimizado y resistente al phishing dentro del flujo de EMV 3DS.

Este artículo ofrece una visión general del mercado global de soluciones de Servidor de Control de Acceso (ACS) para EMV 3DS que se ofrecen a los bancos emisores. Identifica a los principales proveedores e intenta evaluar su soporte actual tanto para las estructuras de datos FIDO que no son SPC como para Secure Payment Confirmation (SPC) en los flujos de desafío. Además, aclara el mecanismo por el cual los emisores pueden aprovechar sus propias passkeys FIDO para la verificación criptográfica dentro del flujo de desafío 3DS a través de SPC y analiza la aplicabilidad global de este estándar.

EMV 3DS opera principalmente a través de dos vías de autenticación distintas:

• Flujo sin fricción: Esta es la vía preferida, que busca una experiencia de usuario fluida. El ACS del emisor realiza una evaluación de riesgos basada en un amplio conjunto de datos intercambiados durante el inicio de la transacción (a través del mensaje de solicitud de autenticación, o AReq). Estos datos incluyen detalles de la transacción, información del comercio, características del dispositivo, datos del navegador (potencialmente recopilados a través del JavaScript 3DSMethod) y, posiblemente, información de autenticaciones previas. Si el riesgo se considera bajo, la transacción se autentica sin requerir ninguna interacción directa o "desafío" por parte del titular de la tarjeta. Este flujo representa la mayoría de las transacciones 3DS, especialmente donde los motores de riesgo están bien ajustados.
• Flujo de desafío: Si el ACS determina que el riesgo de la transacción es alto, si lo exigen las regulaciones (como la PSD2 SCA en Europa) o la política del emisor, se desafía activamente al titular de la tarjeta para que verifique su identidad. Los métodos de desafío tradicionales incluyen contraseñas de un solo uso (OTP) enviadas por SMS, preguntas basadas en conocimiento o autenticación fuera de banda (OOB) a través de una aplicación bancaria. El objetivo de las versiones más nuevas de 3DS y tecnologías relacionadas como SPC es hacer que este flujo de desafío sea más seguro y menos engorroso que los métodos tradicionales.

EMVCo y la Alianza FIDO han colaborado para definir una forma estandarizada para que los comercios transmitan información sobre autenticaciones FIDO previas (donde el comercio actuó como Relying Party, por ejemplo, durante el inicio de sesión del usuario) al ACS del emisor dentro del mensaje AReq estándar de 3DS. Este mecanismo, soportado por primera vez en EMV 3DS v2.1, utiliza campos específicos dentro del AReq, principalmente la estructura threeDSRequestorAuthenticationInfo, que contiene subcampos como threeDSRequestorAuthenticationData.

La nota técnica de la Alianza FIDO y el white paper relacionado de EMVCo especifican una estructura JSON para este campo threeDSRequestorAuthenticationData al transmitir detalles de una autenticación FIDO previa. Este objeto JSON incluye detalles como la hora de autenticación (authTime), el ID del Relying Party FIDO (rpId o appId), e información sobre el o los autenticadores utilizados, incluyendo la clave pública, el AAGUID/AAID, e indicadores de presencia del usuario (UP) y verificación del usuario (UV).

La lógica es que si un comercio ha realizado recientemente una autenticación FIDO fuerte (por ejemplo, usando datos biométricos o una passkey) para la sesión del usuario que inicia la compra, esta información puede servir como una valiosa señal de riesgo adicional para el ACS del emisor. Al recibir y procesar estos datos FIDO estandarizados, el ACS puede ganar mayor confianza en la legitimidad de la transacción, aumentando la probabilidad de una aprobación sin fricción y reduciendo la necesidad de un desafío separado. Es importante señalar que, en este escenario, el comercio es el RP de FIDO, y el emisor consume estos datos como una entrada para su motor de riesgos; el emisor no verifica criptográficamente la aserción FIDO en sí misma dentro de este flujo sin fricción. El ACS se reserva la opción de ignorar estos datos si no está configurado para procesarlos.

Secure Payment Confirmation (SPC) representa una integración distinta de los estándares FIDO dentro del flujo de desafío de EMV 3DS. SPC es un estándar web del W3C, desarrollado en colaboración con FIDO y EMVCo, y basado en WebAuthn. Está formalmente soportado dentro de EMV 3DS a partir de la versión 2.3.

Cuando se utiliza SPC como método de desafío:

1. El emisor (o una parte explícitamente delegada por el emisor, como un esquema de pago) funciona como el Relying Party (RP) de FIDO. Esto es fundamentalmente diferente del flujo de datos FIDO no SPC descrito anteriormente, donde el comercio suele actuar como el RP para sus propios fines de inicio de sesión/autenticación.
2. Durante el desafío 3DS, el ACS señala la necesidad de SPC y proporciona los identificadores de credenciales FIDO necesarios y un desafío criptográfico al comercio/servidor 3DS.
3. El sistema del comercio invoca la API de SPC del navegador, presentando los detalles de la transacción (importe, moneda, beneficiario, instrumento) al usuario en un diálogo seguro controlado por el navegador.
4. El usuario se autentica usando su autenticador FIDO (por ejemplo, datos biométricos del dispositivo, PIN, llave de seguridad), que firma los detalles de la transacción y el desafío usando la clave privada asociada con la passkey registrada por el emisor.
5. La aserción FIDO resultante (prueba criptográfica de autenticación y consentimiento) se devuelve a través del protocolo 3DS (normalmente mediante un segundo mensaje AReq) al ACS del emisor.
6. El ACS, como RP, valida criptográficamente la aserción utilizando la clave pública correspondiente, confirmando la identidad del titular de la tarjeta y su consentimiento a los detalles específicos de la transacción.

SPC tiene como objetivo proporcionar una experiencia de desafío que sea a la vez más segura (resistente al phishing, con vinculación dinámica de la autenticación a los datos de la transacción) y potencialmente con menor fricción (a menudo más rápida que la introducción de un OTP) en comparación con los métodos tradicionales.

Las dos vías para la integración de FIDO —una que aprovecha los datos de autenticación previos del comercio para la evaluación de riesgos sin fricción, y la otra que utiliza credenciales gestionadas por el emisor para un desafío directo basado en FIDO a través de SPC— ofrecen enfoques distintos para mejorar la seguridad y la experiencia del usuario dentro del marco de EMV 3DS. Comprender el soporte de los proveedores para cada una es crucial para los emisores y los PSPs que planifican sus estrategias de autenticación.

Esta sección analiza las capacidades de los proveedores globales de soluciones ACS para EMV 3DS, centrándose en su presencia en el mercado y su soporte para datos FIDO (no SPC) y Secure Payment Confirmation (SPC). Las cifras precisas de cuota de mercado son propietarias y difíciles de obtener públicamente; por lo tanto, la presencia se evalúa en función de las afirmaciones de los proveedores, certificaciones, asociaciones, alcance geográfico e informes de mercado.

• Presencia en el mercado: Entersekt, especialmente tras la adquisición del negocio de software 3DS de Modirum en diciembre de 2023, se posiciona como un proveedor líder mundial de soluciones EMV 3DS, con el objetivo de alcanzar una posición entre los cinco primeros del mercado. Modirum tenía más de 20 años de experiencia en 3DS. Entersekt destaca un crecimiento récord impulsado por nuevos clientes, especialmente en Norteamérica, y asociaciones estratégicas, incluida una relación ampliada con Mastercard. Afirman asegurar más de 2.500 millones de transacciones anuales (a fecha del año fiscal 24) y están clasificados como el número 1 en prevención de ATO en banca por Liminal. Su ACS está disponible alojado (por Entersekt o el cliente) o on-premise. Prestan servicio a emisores y procesadores a nivel mundial.
• Soporte de datos FIDO no SPC (sin fricción): Entersekt enfatiza su autenticación Context Aware™, análisis de comportamiento y dispositivo para señales de riesgo, y la integración con varios servicios de puntuación de riesgo. Su ACS cuenta con la certificación FIDO EMVCo 2.2. Aunque destacan el uso de datos de inteligencia de riesgo y comportamiento para RBA, no se indica explícitamente en los materiales en línea la confirmación de que procesan los datos de atestación FIDO estandarizados de autenticaciones previas de comercios dentro del campo threeDSRequestorAuthenticationInfo para mejorar el flujo sin fricción. Sin embargo, su enfoque en la autenticación avanzada y las señales de riesgo sugiere que tienen esa capacidad.
• Soporte de SPC (desafío): Hay fuertes indicios de que Entersekt soporta SPC. Modirum, cuyo negocio 3DS fue adquirido por Entersekt, proporcionó componentes para el piloto de SPC de Visa utilizando 3DS 2.2 con extensiones. Entersekt enumera explícitamente el soporte para el cumplimiento de SPC como parte de sus capacidades de cumplimiento normativo. Su ACS soporta la autenticación biométrica, está certificado para EMV 3DS 2.2 y probablemente incorpora capacidades de la participación de Modirum en el piloto. La combinación de la adquisición de Modirum, la mención explícita del cumplimiento de SPC y la certificación FIDO apunta firmemente al soporte de SPC en su oferta actual.

• Presencia en el mercado: Arcot de Broadcom es un actor fundamental en el mercado 3DS, habiendo coinventado el protocolo original con Visa. Se posicionan como un líder mundial reconocido, prestando servicio a más de 5.000 instituciones financieras en todo el mundo y procesando transacciones de 229 países. Su red Arcot Network enfatiza un enfoque de datos de un vasto consorcio (afirmando tener más de 600 millones de firmas de dispositivos, 150 billones de puntos de datos) para potenciar sus motores de puntuación de fraude y riesgo. Tienen una fuerte presencia en Europa, Australia y Norteamérica.
• Soporte de datos FIDO no SPC (sin fricción): Broadcom enfatiza enormemente la riqueza de su red de datos y el uso de IA/redes neuronales para la detección de fraudes y la evaluación basada en riesgos, yendo más allá de los elementos de datos estándar de EMV 3DS. Afirman explícitamente que su solución aprovecha los datos que fluyen a través de múltiples emisores e incorpora datos digitales como los del dispositivo y la geolocalización. Aunque no mencionan explícitamente el procesamiento de la estructura JSON específica de FIDO de threeDSRequestorAuthenticationData, su enfoque en la ingesta de diversos puntos de datos para RBA sugiere firmemente que podrían consumir dichos datos si se les proporcionaran, lo que se alinea con la intención de la guía de EMVCo/FIDO. Su plataforma tiene como objetivo maximizar las aprobaciones sin fricción a través de una evaluación de riesgos superior.
• Soporte de SPC (desafío): La documentación de Broadcom confirma el soporte para autenticadores FIDO (llave de seguridad, biométrico, passkey) dentro de su suite más amplia VIP Authentication Hub / Identity Security. Su ACS 3DS soporta varios métodos de desafío, incluyendo OTPs y notificaciones push, y mencionan el soporte para biometría. También ofrecen capacidades de autenticación delegada y han introducido funciones de evaluación de riesgos post-desafío. Sin embargo, en la documentación proporcionada no se encuentra una confirmación explícita de que su producto ACS para EMV 3DS soporte actualmente SPC como un método de desafío específico (que requiere capacidades de EMV 3DS v2.3+ y el flujo de dos AReq). Aunque son un actor importante probablemente capaz de implementarlo, el material público actual se centra más en su motor RBA y en los métodos de desafío tradicionales/OOB.

• Presencia en el mercado: Netcetera se posiciona como un importante actor internacional de pagos, particularmente fuerte en Europa y Oriente Medio. Afirman que su ACS es utilizado por más de 800 bancos/emisores, asegurando más de 50 millones de tarjetas en todo el mundo. Destacan las certificaciones con todas las principales redes de tarjetas (Visa, Mastercard, Amex, Discover, JCB, UnionPay, etc.) y el cumplimiento de PCI. Fueron notablemente el primer proveedor de ACS en todo el mundo en lograr la certificación EMV 3DS 2.3.1.
• Soporte de datos FIDO no SPC (sin fricción): La documentación de Netcetera destaca la importancia de los datos recopilados a través del 3DSMethod para la evaluación de riesgos del ACS con el fin de aumentar la autenticación sin fricción. Ofrecen integración con herramientas de riesgo. Sin embargo, no se menciona explícitamente en los materiales revisados la confirmación específica del procesamiento de datos de autenticación FIDO previos del comercio (de threeDSRequestorAuthenticationInfo) para la evaluación de riesgos.
• Soporte de SPC (desafío): Netcetera demuestra un fuerte soporte para SPC. Fueron el primer proveedor a nivel mundial certificado para EMV 3DS 2.3.1, la versión que incorpora SPC. Participaron en el piloto de SPC de Visa, proporcionando los componentes de la v2.3.1. La documentación de su producto define explícitamente SPC. Han realizado seminarios web discutiendo la integración de FIDO y SPC y han publicado artículos destacando los beneficios de SPC. Esta combinación de certificación, participación en pilotos y documentación explícita confirma su soporte para los desafíos de SPC.

• Presencia en el mercado: Worldline se posiciona como el líder europeo en servicios de pago y transaccionales y un importante actor global (afirmando ser el 4º actor de pagos a nivel mundial). Procesan miles de millones de transacciones anualmente y enfatizan el cumplimiento garantizado, el control de fraudes mediante IA/ML y la escalabilidad. Se afirma que su ACS está certificado para EMV 3DS y cumple con los principales esquemas (Visa Secure, Mastercard Identity Check) y PSD2. Informan que procesan más de 2.400 millones de transacciones 3DS anualmente para más de 100 emisores.
• Soporte de datos FIDO no SPC (sin fricción): La oferta de ACS de Worldline incluye un motor de reglas RBA que permite a los emisores configurar flujos sin fricción o de desafío basados en el riesgo. Su solución más amplia "Trusted Authentication" aprovecha la inteligencia de dispositivos y el análisis de comportamiento. Aunque soportan FIDO en general, no se detalla en los fragmentos proporcionados la confirmación explícita del procesamiento de datos FIDO previos del comercio (no SPC) dentro del ACS para la evaluación de riesgos.
• Soporte de SPC (desafío): Worldline muestra claros indicios de soportar SPC. Su documentación reconoce la evolución de EMV 3DS 2.3 para incluir SPC/FIDO. Comercializan explícitamente su solución "WL Trusted Authentication" como compatible con la autenticación FIDO y ofrecen un "WL FIDO Server" adecuado para "casos de uso 3DS, con emvCO2.3 y SPC".

• Presencia en el mercado: GPayments posiciona ActiveAccess como una "plataforma robusta y líder en el mercado de Servidores de Control de Acceso (ACS)" con más de 20 años en el espacio de 3D Secure. Están certificados con los principales esquemas de tarjetas (Visa Secure, Mastercard Identity Check, JCB J/Secure) tanto para 3DS1 como para EMV 3DS. Su solución puede desplegarse on-premise o alojada en la nube. Los informes de mercado identifican a GPayments como un actor notable que ofrece soluciones ACS.
• Soporte de datos FIDO no SPC (sin fricción): ActiveAccess soporta la integración con soluciones RBA de terceros y utiliza varios parámetros para su propia evaluación de riesgos. Sin embargo, la documentación proporcionada no menciona explícitamente el soporte para la ingesta o el uso de datos de autenticación FIDO previos del comercio (no SPC) para la evaluación de riesgos sin fricción.
• Soporte de SPC (desafío): La documentación revisada de ActiveAccess no menciona explícitamente el soporte para Secure Payment Confirmation (SPC), desafíos WebAuthn o desafíos FIDO como parte de sus capacidades de flujo de desafío. Aunque soportan varios métodos de autenticación, incluido el OOB (que puede abarcar biometría), el soporte específico de SPC no está claro a partir de la información disponible.

• Presencia en el mercado: Visa, como una de las principales redes de pago globales, define el programa Visa Secure basado en el estándar EMV 3DS. Fueron pioneros en el protocolo 3DS original. En lugar de actuar principalmente como un proveedor directo de ACS de la misma manera que empresas tecnológicas como Entersekt o Broadcom, Visa opera el programa y se basa en una lista de proveedores 3DS aprobados (incluidos los proveedores de ACS) cuyos productos están certificados como compatibles con EMV 3DS y las reglas de Visa Secure. Los emisores suelen adquirir soluciones ACS de estos proveedores certificados. Visa se centra en la red (servidor de directorio), definiendo las reglas del programa, promoviendo la adopción e impulsando la innovación como los pilotos de SPC.
• Soporte de datos FIDO no SPC (sin fricción): Visa Secure, al estar basado en EMV 3DS, soporta inherentemente el intercambio de datos enriquecidos para la evaluación de riesgos y permitir el flujo sin fricción. El marco de EMVCo/FIDO para transmitir datos FIDO previos opera dentro del ecosistema de Visa Secure si el proveedor de ACS elegido soporta su procesamiento.
• Soporte de SPC (desafío): Visa está activamente involucrada en la realización de pilotos y la promoción de SPC. Están trabajando con socios (como Netcetera y Modirum/Entersekt en los pilotos) para probar y refinar el flujo de SPC dentro del protocolo 3DS. Este fuerte compromiso indica un apoyo estratégico para SPC como método de desafío dentro del programa Visa Secure, supeditado a la preparación del ecosistema (soporte de ACS, comercio y navegador).

• Presencia en el mercado: Al igual que Visa, Mastercard opera el programa Mastercard Identity Check basado en EMV 3DS. Ofrecen opciones para emisores y comercios, incluido el procesamiento stand-in y potencialmente el aprovechamiento de socios o subsidiarias como NuData. Mastercard adquirió NuData Security, una empresa de biometría conductual, en 2017, mejorando sus capacidades de evaluación de riesgos. También enfatizan la innovación continua en biometría, RBA e IA. Al igual que Visa, dependen de proveedores certificados para los componentes principales del ACS, pero pueden ofrecer servicios empaquetados o aprovechar la tecnología adquirida.
• Soporte de datos FIDO no SPC (sin fricción): Mastercard Identity Check aprovecha el rico intercambio de datos de EMV 3DS 2.x para mejorar la toma de decisiones de riesgo y el flujo sin fricción. Su adquisición de NuData sugiere un fuerte enfoque en el análisis de comportamiento como parte de esta evaluación de riesgos. El soporte para procesar datos FIDO previos del comercio dependería de la implementación específica del ACS utilizada por el emisor dentro del programa Identity Check.
• Soporte de SPC (desafío): Mastercard es un miembro clave de EMVCo y está involucrado en el desarrollo de los estándares EMV 3DS, incluida la v2.3 que soporta SPC. También están promoviendo la adopción de passkeys de forma más amplia. Se pueden encontrar más detalles aquí. Son un firme defensor de SPC e impulsan la adopción de métodos de autenticación modernos.

El mercado de ACS para EMV 3DS cuenta con numerosos proveedores además de los detallados anteriormente. Proveedores como /n software, RSA, 2C2P, 3dsecure.io, Adyen, ACI Worldwide, Computop y otros también ofrecen soluciones certificadas o desempeñan roles significativos en regiones o segmentos específicos. Este análisis tiene como objetivo cubrir a los actores globales prominentes, pero no es exhaustivo debido a la naturaleza dinámica del mercado. Las capacidades de los proveedores, particularmente en lo que respecta a estándares emergentes como SPC, evolucionan rápidamente. Si nota alguna imprecisión o tiene información actualizada sobre el soporte de los proveedores para datos FIDO o Secure Payment Confirmation, por favor, póngase en contacto con nosotros para que podamos asegurar que esta visión general se mantenga actualizada y precisa.

Un principio fundamental del uso de Secure Payment Confirmation (SPC) dentro del flujo de desafío de EMV 3DS es que el emisor de la tarjeta (o una parte explícitamente delegada por el emisor, como un esquema de pago) funciona como el Relying Party (RP) de FIDO. Esto es fundamentalmente diferente del flujo de datos FIDO no SPC descrito anteriormente, donde el comercio suele actuar como el RP para sus propios fines de inicio de sesión/autenticación.

Para que SPC funcione en un desafío 3DS, se siguen los siguientes pasos:

1. Registro: El titular de la tarjeta debe registrar primero un autenticador FIDO (por ejemplo, datos biométricos del dispositivo como huella dactilar/reconocimiento facial, PIN del dispositivo o una llave de seguridad externa) con su banco emisor. Este proceso crea una passkey, donde la clave pública y un identificador de credencial único son almacenados por el emisor y asociados con la cuenta del titular de la tarjeta o una tarjeta de pago específica. El registro puede ocurrir dentro de la aplicación móvil del banco, el portal de banca en línea, o potencialmente ofrecerse después de un desafío 3DS tradicional exitoso. Es crucial que, para que SPC sea invocado por un tercero como el sitio web de un comercio, la credencial debe crearse típicamente con el consentimiento explícito del usuario para su uso en dichos contextos, lo que a menudo implica extensiones específicas de WebAuthn durante el registro.
2. Autenticación (durante el desafío 3DS):
   • Cuando una transacción 3DS desencadena un desafío, y el emisor/ACS soporta y elige SPC, el ACS identifica el o los ID de credencial FIDO relevantes vinculados al titular de la tarjeta y al dispositivo.
   • El ACS incluye este o estos ID de credencial, junto con un desafío criptográfico único y los detalles de la transacción (importe, moneda, nombre/origen del beneficiario, icono/nombre de visualización del instrumento), en la respuesta de autenticación (ARes) enviada de vuelta al servidor/solicitante 3DS.
   • El componente solicitante 3DS del comercio utiliza esta información del ARes para invocar la API de SPC del navegador.
   • El navegador presenta un diálogo estandarizado y seguro que muestra los detalles de la transacción proporcionados por el ACS.
   • El usuario confirma la transacción y se autentica usando su autenticador FIDO registrado (por ejemplo, tocando un sensor de huellas dactilares, reconocimiento facial, introduciendo el PIN del dispositivo, tocando una llave de seguridad). Esta acción desbloquea la clave privada almacenada de forma segura en el dispositivo/autenticador.
   • El autenticador firma los detalles de la transacción presentados y el desafío criptográfico recibido del ACS.
   • El navegador devuelve la aserción FIDO resultante (la carga de datos firmada) al solicitante 3DS del comercio.
   • El solicitante 3DS transmite esta aserción de vuelta al ACS del emisor, típicamente encapsulada dentro de un segundo mensaje AReq.
   • El emisor/ACS, actuando como el Relying Party autoritativo, utiliza la clave pública previamente almacenada del titular de la tarjeta para verificar criptográficamente la firma en la aserción. Una verificación exitosa confirma que el titular legítimo de la tarjeta, usando su autenticador registrado, aprobó los detalles específicos de la transacción presentados.

La integración de SPC en el flujo de desafío de EMV 3DS requiere modificaciones en la secuencia de mensajes estándar, implicando típicamente dos intercambios AReq/ARes:

1. Solicitud de autenticación inicial (AReq #1): El comercio/servidor 3DS inicia el proceso 3DS enviando un AReq que contiene datos de la transacción y del dispositivo. Para señalar la capacidad para SPC, la solicitud puede incluir un indicador como threeDSRequestorSpcSupport establecido en 'Y' (o similar, dependiendo de la implementación del proveedor de ACS).
2. Respuesta de autenticación inicial (ARes #1): Si el ACS determina que se requiere un desafío y opta por SPC, responde con un ARes que indica esto. El transStatus podría establecerse en 'S' (indicando que se requiere SPC) u otro valor específico. Este ARes contiene la carga de datos necesaria para la llamada a la API de SPC.
3. Invocación de la API de SPC y autenticación FIDO: El componente solicitante 3DS del comercio recibe el ARes #1 y utiliza la carga de datos para invocar la API de SPC del navegador. El usuario interactúa con su autenticador a través de la interfaz de usuario segura del navegador.
4. Devolución de la aserción FIDO: Tras una autenticación de usuario exitosa, el navegador devuelve los datos de la aserción FIDO al solicitante 3DS.
5. Segunda solicitud de autenticación (AReq #2): El solicitante 3DS construye y envía un segundo mensaje AReq al ACS. El propósito principal de este mensaje es transportar los datos de la aserción FIDO. Típicamente incluye:
   • ReqAuthData: Conteniendo la aserción FIDO.
   • ReqAuthMethod: Establecido en '09' (o el valor designado para la aserción SPC/FIDO).
   • Potencialmente el valor AuthenticationInformation del ARes #1 para vincular las solicitudes.
   • Opcionalmente, un SPCIncompletionIndicator si la llamada a la API de SPC falló o expiró.
6. Respuesta de autenticación final (ARes #2): El ACS recibe el AReq #2, valida la aserción FIDO utilizando la clave pública del titular de la tarjeta y determina el resultado final de la autenticación. Envía de vuelta el ARes #2 que contiene el estado definitivo de la transacción (por ejemplo, transStatus = 'Y' para autenticación exitosa, 'N' para fallida).

Este flujo de dos AReq representa una desviación de los métodos de desafío 3DS tradicionales (como OTP u OOB manejados a través de mensajes CReq/CRes o RReq/RRes) que típicamente se completan dentro del ciclo inicial AReq/ARes después de recibir un transStatus = 'C'. Aunque la parte de interacción del usuario de SPC (escaneo biométrico, entrada de PIN) es a menudo significativamente más rápida que escribir un OTP, la introducción de una segunda ronda completa de AReq/ARes añade latencia de red entre el servidor 3DS, el servidor de directorio y el ACS. Los implementadores y proveedores deben optimizar cuidadosamente este flujo y manejar posibles tiempos de espera para asegurar que el tiempo total de la transacción de extremo a extremo siga siendo competitivo y cumpla con las expectativas del usuario.

Secure Payment Confirmation está posicionada para una adopción global debido a su doble estandarización. Está formalmente definida como un estándar web por el World Wide Web Consortium (W3C), habiendo alcanzado el estado de Candidata a Recomendación a mediados de 2023, con trabajo en curso para convertirse en una Recomendación completa. Simultáneamente, SPC ha sido integrada en las especificaciones de EMV® 3-D Secure a partir de la versión 2.3, gestionada por EMVCo, el organismo técnico global para los estándares de pago. Esta integración asegura que SPC funcione dentro del marco global establecido para la autenticación de transacciones CNP. La colaboración entre el W3C, la Alianza FIDO y EMVCo subraya el esfuerzo de toda la industria para crear estándares interoperables para pagos en línea seguros y fáciles de usar.

Aunque el diseño de SPC, particularmente su capacidad para vincular criptográficamente la autenticación del usuario a detalles específicos de la transacción ("vinculación dinámica"), ayuda a satisfacer los requisitos de Autenticación Reforzada de Cliente (SCA) bajo regulaciones como la Directiva de Servicios de Pago de Europa (PSD2), su utilidad no se limita a estas regiones con mandatos. SPC es un estándar técnico global aplicable en cualquier mercado, incluidos Estados Unidos y Canadá, siempre que los componentes necesarios del ecosistema estén en su lugar.

En mercados sin mandatos explícitos de SCA para cada transacción, los principales impulsores para adoptar SPC son:

• Mejora de la experiencia del usuario: Ofrecer un método de desafío potencialmente más rápido y conveniente (por ejemplo, usando datos biométricos del dispositivo) en comparación con los OTPs tradicionales o las preguntas basadas en conocimiento, lo que podría reducir el abandono de carritos. Los pilotos han mostrado reducciones significativas en el tiempo de autenticación en comparación con los desafíos tradicionales.
• Seguridad mejorada: La autenticación basada en FIDO inherente a SPC es resistente a los ataques de phishing, credential stuffing y otras amenazas comunes dirigidas a contraseñas y OTPs.

Por lo tanto, los emisores y comercios en regiones como Norteamérica pueden optar por implementar SPC estratégicamente para mejorar la seguridad y proporcionar una mejor experiencia al cliente, incluso sin un requisito regulatorio para hacerlo en todas las transacciones.

El despliegue exitoso y la adopción generalizada de Secure Payment Confirmation (SPC) dependen en gran medida de una preparación coordinada en múltiples componentes del ecosistema de pagos. Aunque los estándares FIDO subyacentes y la tecnología de passkeys están madurando rápidamente, el soporte específico a nivel de navegador para la API de SPC y la integración completa en toda la cadena de pagos siguen siendo obstáculos críticos. Otros actores del ecosistema están avanzando en general a buen ritmo.

Resumen de la preparación del ecosistema (Estado en mayo de 2025)

Qué significa esto en la práctica (mayo de 2025)

El principal factor limitante para la adopción de SPC es la capa del user-agent (navegador):

• Safari (macOS y iOS): ❌ WebKit todavía carece del método de solicitud de pago secure-payment-confirmation. Cualquier sitio visitado en Safari debe recurrir a otros métodos de autenticación (OTP, OOB, potencialmente experiencias WebAuthn no SPC). Apple no ha expresado interés en implementar la extensión.
• Chrome / Edge (Chromium): ⚠️ El SPC base (creación de credenciales + autenticación) es estable, pero las claves aún no se almacenan en autenticadores de hardware y solo se han utilizado en pilotos. Los implementadores deben esperar posibles cambios disruptivos y estar preparados para restringir la funcionalidad basándose en comprobaciones de disponibilidad de la API (por ejemplo, canMakePayment()) o indicadores de funciones.
• Firefox: ❌ El equipo ha señalado interés pero no tiene un cronograma de implementación comprometido; los comercios deben planificar rutas de respaldo adecuadas.

Dado que la infraestructura del emisor (ACS, servidores FIDO) y los servidores de directorio de los esquemas están en gran medida listos o avanzando rápidamente, y las herramientas de los comercios/PSPs están cada vez más disponibles, la principal barrera para el uso generalizado de SPC es el soporte de los navegadores. Una vez que la cobertura de los navegadores mejore, las tareas restantes implicarán principalmente la integración por parte de los comercios/PSPs (actualización a EMV 3DS v2.3+, adición de la lógica de invocación de SPC, manejo del flujo de dos AReq) y la ampliación del registro de passkeys por parte de los emisores específicamente para contextos de pago.

Por ahora, es de esperar que SPC aparezca solo en una porción limitada de las transacciones. Hasta que Safari (y por lo tanto todo el ecosistema de iOS) ofrezca soporte, SPC no podrá alcanzar el soporte del mercado.

El análisis revela una clara divergencia en la preparación de las dos principales integraciones de FIDO dentro de EMV 3DS a fecha de mayo de 2025. Si bien los elementos fundamentales para Secure Payment Confirmation (SPC) como método de desafío están avanzando —particularmente las capacidades de los emisores/ACS y la preparación de los esquemas—, su adopción generalizada se ve significativamente obstaculizada por el cuello de botella crítico del soporte de navegadores, especialmente la falta de implementación en Safari de Apple (bloqueando todos los dispositivos iOS/iPadOS) y Firefox, junto con las limitaciones en las implementaciones actuales de Chromium. SPC sigue siendo un estado futuro prometedor, pero no es una solución práctica y universal a día de hoy.

Basándonos en el estado actual del ecosistema, se establecen las siguientes recomendaciones:

• Comercios:
  • Priorizar la adopción de Passkeys: Implementar passkeys para el inicio de sesión y la autenticación de usuarios. Más allá de mejorar su propia seguridad y experiencia de usuario (factores no detallados aquí), esto crea los datos necesarios para los flujos sin fricción de 3DS.
  • Transmitir los datos FIDO: Asegurarse de que su integración 3DS rellene correctamente el campo threeDSRequestorAuthenticationInfo con los detalles de las autenticaciones con passkey previas y exitosas durante la sesión de pago. Trabajar con su proveedor de PSP/servidor 3DS para habilitar esto.
• Emisores:
  • Registrar las Passkeys de los usuarios: Comenzar a ofrecer y animar a los titulares de tarjetas a registrar passkeys directamente con ustedes (para el acceso a la aplicación bancaria, futuro SPC, etc.). Construir la infraestructura de Relying Party FIDO necesaria.
  • Aprovechar ya los datos de Passkeys de los comercios: Indicar a su proveedor de ACS que ingiera y utilice los datos FIDO transmitidos por los comercios (threeDSRequestorAuthenticationInfo) como una señal positiva fuerte dentro de su motor de RBA. Mantener registros de las passkeys de comercios de confianza asociadas a los usuarios siempre que sea posible. El objetivo es aumentar significativamente las aprobaciones sin fricción para las transacciones precedidas por una autenticación fuerte con passkey del comercio.
  • Prepararse para SPC y monitorizar activamente: Asegurarse de que su hoja de ruta de ACS incluya soporte completo para SPC de EMV 3DS v2.3.1+, pero tratarlo como una mejora futura. Monitorizar continuamente los desarrollos de los navegadores (especialmente Safari) para evaluar cuándo SPC podría ser viable a gran escala.
• Proveedores de ACS:
  • Mejorar el RBA con inteligencia de Passkeys: Invertir fuertemente en la capacidad de su motor de RBA para procesar y confiar en los datos de FIDO/passkeys proporcionados por los comercios. Desarrollar una lógica para rastrear el uso de passkeys en las compras de un comercio para un usuario/dispositivo determinado. Almacenar las claves públicas (del registro directo del emisor) para verificar la integridad criptográfica de los datos de autenticación del comercio si se proporcionan. Vincular directamente el uso exitoso de passkeys a tasas de aprobación sin fricción más altas.
  • Construir capacidades de SPC robustas: Continuar desarrollando y certificando el soporte completo del flujo de desafío de SPC (EMV 3DS v2.3.1+) en preparación para la futura adopción del mercado.
• Esquemas/Redes de pago:
  • Promover los datos FIDO para el flujo sin fricción: Promover activamente y potencialmente incentivar la transmisión y utilización de los datos de autenticación FIDO del comercio (threeDSRequestorAuthenticationInfo) dentro del flujo 3DS. Proporcionar una guía clara y apoyo a los emisores y proveedores de ACS sobre cómo aprovechar estos datos de manera efectiva para el RBA.
  • Continuar la promoción de SPC y el compromiso con los navegadores: Mantener los esfuerzos para estandarizar y promover SPC, comprometiéndose críticamente con los proveedores de navegadores (Apple, Mozilla, Google) para fomentar una implementación completa e interoperable del estándar de la API de SPC.

La oportunidad inmediata y tangible reside en mejorar el flujo sin fricción aprovechando la creciente adopción de passkeys a nivel de comercio. Todos los participantes del ecosistema deben priorizar la habilitación de la creación, transmisión y consumo inteligente de estos datos de autenticación previos dentro del marco existente de EMV 3DS. Este camino ofrece beneficios a corto plazo en la reducción de la fricción y potencialmente del fraude sin esperar al soporte universal de SPC en los navegadores. Al mismo tiempo, preparar el terreno para SPC —particularmente el registro de passkeys por parte del emisor y la preparación del ACS— asegura que el ecosistema esté posicionado para adoptar este método de desafío superior una vez que se resuelva el cuello de botella de los navegadores.