Servicio de control de acceso (ACS): autenticación 3DS

Si alguna vez compraste algo en línea y tu banco te mostró una notificación en la aplicación pidiéndote que aprobaras el pago, ya conociste un servicio de control de acceso. El ACS es la pieza de infraestructura que opera el emisor de tu tarjeta y que está detrás de cada autenticación 3D Secure. Los comercios no lo ven directamente — el ACS habla con el 3DS Server del comercio a través del directory server de la red de tarjetas — pero es el sistema que en última instancia decide si pasas sin problemas, recibes un desafío o quedas bloqueado.

Qué hace realmente un ACS

El ACS está alojado por el emisor de la tarjeta (o por un proveedor de 3DS que actúa en nombre del emisor). Su trabajo es autenticar al titular de la tarjeta durante una transacción 3D Secure 2. Eso abarca tres cosas:

• Evaluación de riesgo. Cuando el comercio envía una solicitud de autenticación, el ACS examina los datos del dispositivo, las señales de comportamiento, el importe de la transacción, la categoría del comercio y el historial del titular. A partir de eso decide si la transacción es de riesgo lo bastante bajo como para aprobarla sin fricción o lo bastante arriesgada como para desafiarla.
• Entrega del desafío. Si hace falta un desafío, el ACS elige un método — código por SMS de un solo uso, notificación push en la aplicación bancaria, biometría en la aplicación del emisor u otro paso adicional — y lo ejecuta. El titular interactúa con el ACS, no con el comercio.
• Firma del resultado. Una vez finalizada la autenticación, el ACS devuelve un resultado firmado a través de la red. Ese resultado es lo que el comercio presenta después al adquirente para reclamar la transferencia de responsabilidad en un contracargo.

Dónde encaja el ACS en el flujo de 3DS

3D Secure tiene tres dominios con nombre: el dominio del adquirente (el comercio y su banco adquirente), el dominio de interoperabilidad (el directory server de la red de tarjetas) y el dominio del emisor. El ACS vive en el dominio del emisor. Una transacción EMV 3DS 2 típica se ve así:

1. El comprador llega al checkout. El 3DS Server del comercio empaqueta los datos del dispositivo, la información de facturación y los detalles de la transacción en una solicitud de autenticación (AReq).
2. El comercio envía la AReq al directory server (Visa, Mastercard, Amex, Discover, etc.). El directory server busca qué ACS atiende al rango de BIN de ese emisor y reenvía la solicitud.
3. El ACS hace su comprobación de riesgo. Si el riesgo es bajo y el emisor está conforme, devuelve una respuesta de autenticación sin fricción — sin necesidad de interacción del comprador.
4. Si el riesgo es mayor, el ACS activa un desafío. El comprador ve una pantalla o un aviso en la aplicación servido por el ACS, completa el paso adicional, y el ACS envía de vuelta el resultado autenticado final.
5. El comercio usa el valor de autenticación en la autorización posterior. El adquirente lo transmite, y la responsabilidad por contracargos de fraude pasa al emisor.

El ACS en 3DS 1 frente a 3DS 2

En el 3D Secure original (Verified by Visa, Mastercard SecureCode), el ACS siempre mostraba un desafío en el navegador — una ventana emergente o un iframe que pedía una contraseña estática. Esa es la versión que todos recuerdan haber odiado. Las redes de tarjetas retiraron 3DS 1 en 2022.

Con EMV 3DS 2, el ACS es mucho más inteligente. Puede autenticar sin fricción usando la huella del dispositivo y datos de comportamiento — más del 90 % de las transacciones nunca llegan a ver una pantalla de desafío. Cuando hace falta un desafío, el ACS admite métodos fuera de banda como aprobaciones en la aplicación bancaria y verificaciones biométricas, no solo contraseñas estáticas. Por eso 3DS 2 sumó conversión en lugar de restarla.

ACS, SCA y la PSD2

En el Reino Unido y la UE, el ACS es el motor que entrega la autenticación reforzada de cliente para pagos sin presencia física de la tarjeta bajo la PSD2. Hay que comprobar dos de tres factores — conocimiento, posesión, inherencia — y el ACS es el sistema que ejecuta esas comprobaciones. Sin una vía de desafío del ACS que funcione, un emisor no puede cumplir con SCA, y el adquirente rechazará de forma blanda las transacciones que deberían haberse autenticado.

Eso también significa que el ACS aplica las exenciones de la PSD2. Las exenciones por bajo importe, bajo riesgo, pagos recurrentes y beneficiarios de confianza se señalan en la AReq, y el ACS decide si las respeta y omite el desafío.

Dónde se cruza el ACS con los pagos telefónicos

La mayoría asocia 3D Secure con el checkout web, pero sin presencia física de la tarjeta es sin presencia física de la tarjeta — los pedidos por teléfono también cuentan. Cuando un comercio recibe una tarjeta por teléfono usando un terminal virtual seguro asistido por un agente, puede aplicarse el mismo flujo de 3DS: el 3DS Server del comercio envía la solicitud de autenticación, el ACS hace su comprobación de riesgo y, si hace falta un desafío, puede entregarse fuera de banda (normalmente a través de la aplicación bancaria del emisor, que no necesita que el agente ni quien llama compartan ningún código).

Esto importa para SCA. Los pagos telefónicos sin una vía de autenticación cada vez más reciben rechazos blandos de los emisores en el Reino Unido y la UE. Enrutar las transacciones telefónicas a través de un ACS de la misma forma que se enrutan las transacciones web es como los comercios mantienen altas las tasas de autorización.

El ángulo de PCI DSS

El ACS en sí reside en el emisor, no en el comercio — así que el alcance de PCI DSS del ACS es problema del emisor. Pero el 3DS Server del comercio y la forma en que recoge los datos de tarjeta sí están dentro del alcance de PCI del comercio. Si un comercio captura el PAN por teléfono, lo teclea en un terminal virtual y ese terminal virtual inicia 3DS, el agente y la grabación de la llamada quedan dentro del alcance, a menos que el PAN se enmascare antes de llegar a cualquier persona o sistema que pudiera almacenarlo.

Por eso el enmascaramiento DTMF importa aquí: el PAN nunca llega al agente ni a la llamada grabada, la solicitud de 3DS igual se dispara, el ACS igual autentica y el alcance de PCI del comercio se mantiene reducido.

Fallos habituales del ACS

• ACS no disponible. A veces el ACS del emisor está caído o inaccesible. El directory server devuelve un estado que indica que el ACS no pudo autenticar. Que el comercio siga adelante depende de la política y el apetito de riesgo de su adquirente.
• Tiempo de espera del desafío agotado. El comprador no completa el desafío dentro de la ventana del ACS (normalmente unos pocos minutos). El resultado vuelve como no autenticado.
• Desajuste de la Method URL. 3DS 2 incluye un paso de 3DS Method en el que el ACS recoge los datos de huella del dispositivo antes de la autenticación principal. Una gestión mal configurada del iframe aquí provoca fallos silenciosos que parecen baja conversión.
• Exención de SCA rechazada. El comercio solicitó una exención por bajo riesgo, pero el ACS decidió desafiar igualmente. El comprador recibe un desafío que no esperaba.

Lo que los comercios deberían saber

Tú no operas un ACS. Pero la forma en que construyes tu checkout — qué datos del dispositivo recoges, qué señales de riesgo transmites, si solicitas exenciones — afecta directamente a lo que hace el ACS. Una integración de 3DS Server bien hecha, más datos de riesgo ricos, más indicadores de exención, equivale a muchas más autenticaciones sin fricción. Una integración descuidada equivale a más desafíos, más abandonos y peor conversión.