La estandarización de 3DS es una tarea pendiente para operadores multi-PSP enterprise

Un líder de pagos enterprise le preguntó a un proveedor algo que delata todo el problema: "¿Soportan 3DS standalone, o tiene que correr adentro del PSP?". Esa pregunta solo la hace alguien que descubrió que sus tres PSPs ejecutan tres políticas distintas, ya visible en los datos de autorización. The Paypers publicó un explainer sobre autenticación EMV 3DS el 29 de abril de 2026, recorriendo el protocolo a un nivel apropiado para alguien que lo estudia por primera vez. Esa misma semana, en conversaciones privadas, líderes de pagos en merchants multi-PSP hacían una pregunta más avanzada. Habían leído la spec años atrás. Lo que querían saber era qué hacer con que cada PSP la implementaba distinto.

EMV 3DS es un protocolo estandarizado. La política de autenticación que se ejecuta encima no lo es, porque la política vive en el PSP, y cada PSP tiene la propia. Hace dos años eso era una molestia operacional. Ahora se vuelve una deadline arquitectónica, porque dos presiones convergentes se encuentran en el mismo lugar: relojes regulatorios que redibujan quién es responsable de Strong Customer Authentication, y variabilidad operacional que empeora con cada PSP agregado. Ambas se resuelven en la misma pregunta: ¿dónde vive el 3DS Server? Y la mayoría de los enterprises la respondieron por defecto hace tres años sin pensarla.

‍

El protocolo está estandarizado. La política no.

EMV 3DS 2.x define el formato del mensaje: cómo el 3DS Server del merchant habla con el Directory Server del scheme, cómo el Directory Server rutea al Access Control Server del emisor, qué datos circulan, y cómo vuelve el resultado, el valor ECI y el Cardholder Authentication Verification Value. Esa parte está estandarizada. Toda implementación certificada maneja el mismo protocolo.

Lo que no está estandarizado es la capa de toma de decisiones que se apoya encima: cuándo solicitar una exención de Transaction Risk Analysis, cuándo marcar un pago como low-value, cuándo usar el indicador de merchant-initiated transaction, cómo poblar los campos opcionales de riesgo, qué hacer con un soft decline. Esas decisiones se configuran por PSP. El merchant que se conecta a tres PSPs hereda tres configuraciones, tres estrategias de exención por defecto, y tres handlers de soft decline. El protocolo detrás es idéntico. La política no.

‍

Por qué el calendario regulatorio importa ahora

El framing de "tarea pendiente" tiene un calendario adjunto. Tres deadlines llegan en la misma ventana, y cada una eleva el costo de dejar la política de 3DS dentro del PSP.

El Digital Authentication Framework de Visa termina en septiembre de 2026, y desde entonces Visa Secure corre sobre la versión más alta del protocolo EMV 3DS que soporte cada emisor, negociada por transacción a través del flujo PReq/PRes. Un merchant cuyos tres PSPs negocien esa versión independientemente con cada emisor produce resultados inconsistentes por diseño.

La PSR, la mitad directamente aplicable del paquete PSD3, fue acordada políticamente en noviembre de 2025 y se espera que entre en vigor en 2027 tras una transición de 21 meses. Su cláusula de delegated authentication permite al emisor tercerizar SCA a un proveedor técnico bajo acuerdo escrito, con la parte que autentica cargando la responsabilidad por fraude. Bajo PSD2, SCA era implícitamente trabajo del emisor, ejecutado vía 3DS. Bajo la PSR, el merchant o su orchestrator pueden ser la parte que autentica — pero solo si el merchant es dueño del 3DS Server. Un merchant cuyo 3DS vive adentro de tres PSPs no tiene camino para aceptar delegated authentication; solo puede consumir lo que sus PSPs produzcan.

El target de migración a AES de Visa, señalado para 2030, significa que las primitivas criptográficas debajo de 3DS cambian al mismo tiempo que se redibuja el perímetro regulatorio. La variabilidad existe hace años. El reloj regulatorio cambia lo que cuesta: pasa de operacionalmente inconveniente a estructuralmente cara, en un horizonte de 12 a 18 meses.

‍

Lógica de exenciones: dónde empieza la variabilidad operacional

Los Regulatory Technical Standards de PSD2 permiten varias exenciones de SCA: Transaction Risk Analysis para transacciones de bajo riesgo bajo un value band, Low-Value Payments por debajo de treinta euros (con límite acumulado de cien euros o cinco transacciones consecutivas), Merchant-Initiated Transactions tras setup autenticado, whitelisting de beneficiarios confiables, y Secure Corporate Payments. Visa Europe estima que entre el 40 y el 50 por ciento de las transacciones de e-commerce por volumen podría calificar para exención de SCA si se cumplen los criterios.

La fuente estructural de variabilidad multi-PSP es la mecánica de exención TRA. Bajo los RTS de la European Banking Authority, la tasa de fraude que determina elegibilidad para TRA se calcula a nivel del PSP en base trimestral móvil. Tres PSPs sirviendo al mismo merchant tienen tasas de fraude, value bands y elegibilidad de exención distintos. El adquirente al 0,11 por ciento de tasa de fraude califica para la exención hasta un umbral más alto; el adquirente al 0,14 por ciento no califica para nada por encima del band más bajo. Sumando las decisiones de implementación de cada PSP — pedir el flag TRA agresivamente, pedirlo solo por encima de un score de riesgo configurado, o no pedirlo nunca porque el merchant no configuró la integración — el merchant que no hace nada distinto entre los tres PSPs obtiene tres resultados de SCA distintos en transacciones idénticas. El impacto en la tasa de aprobación es invisible en el dashboard de cualquier PSP individual, porque cada uno solo ve lo que él ruteó.

Normalizar la lógica de exenciones entre PSPs significa tomar la decisión de exención en un solo lugar, antes del routing, contra la política de riesgo propia del merchant y no contra los defaults de cada PSP. La decisión después se comunica al PSP que procese la autorización.

‍

Comportamiento del challenge rate: la parte invisible del spread

La tasa frictionless es el porcentaje de transacciones 3DS que se completan sin challenge al cardholder. Depende de tres inputs que el merchant no controla directamente: el modelo de riesgo del emisor en su Access Control Server, la calidad de los datos que llegaron al emisor, y la señalización de exención del PSP.

El segundo input es donde el merchant multi-PSP paga más. EMV 3DS 2.x soporta más de 170 elementos de datos que el 3DS Server del merchant puede poblar para autenticación basada en riesgo. Los emisores usan esa información para decidir si emiten challenge. Los PSPs varían en cuánto pueblan desde el checkout: calidad del device fingerprint, datos del browser, historial de transacciones previas, indicadores de riesgo del merchant, verificación de dirección, antigüedad de cuenta, señales de comportamiento. Un PSP que puebla 40 campos va a producir un challenge rate distinto que uno que puebla 110, sobre la misma tarjeta, en la misma sesión, con el mismo emisor.

The Paypers publicó una entrevista separada el 21 de abril de 2026 sobre la psicología de la fricción en el checkout, señalando que los challenge rates afectan la conversión de maneras que varían por mercado y dispositivo. La implicancia para operadores multi-PSP es que la medición de la conversión a nivel agregado oculta la variabilidad emisor-por-PSP que genera el spread. Hacer benchmarking requiere datos a nivel BIN unidos a datos de routing por PSP. Sin eso, la capa analítica no puede ver qué PSP está empujando hacia arriba el challenge rate del emisor.

Mecánicas operacionales para normalizar el challenge rate: capturar los elementos de datos 3DS 2.x disponibles en la capa de orchestration, antes de invocar el 3DS Server del PSP, para setear la calidad una sola vez y no por integración; trackear el challenge rate por BIN del emisor por PSP, no solo por PSP o por mercado, para hacer visible la variabilidad que el dashboard por PSP no muestra; y tratar el challenge rate como un input ajustable del routing, no como una caja negra por PSP.

‍

Manejo de fallback: el costo que se compone con cada PSP agregado

Un soft decline es una respuesta del emisor indicando que la transacción sería aprobada si se ejecutara SCA. EMV 3DS 2.x y PSD2 esperan que el merchant reintente con challenge SCA completo. El código de soft decline de Visa para esto es 20154, con códigos paralelos de Mastercard. Manejarlos correctamente es la diferencia entre recuperar la transacción y perderla.

En una arquitectura multi-PSP donde 3DS vive dentro de cada PSP, el manejo de soft decline tiene un modo de falla oculto. Cuando una transacción se rutea al PSP A, recibe soft decline por SCA, y se cascadea al PSP B para reintentar, la autenticación 3DS del PSP A no se puede reutilizar en el PSP B. El cardholder, que acaba de completar un challenge SCA momentos antes, tiene que completar otro. En mercados PSD2, el operador le pide al cliente autenticarse dos veces en el mismo intento de pago. La tasa de drop-off en el segundo challenge es sustancialmente peor que en el primero.

La causa estructural es la misma que el problema de lógica de exenciones. El resultado de la autenticación 3DS está atado al PSP que lo produjo. No hay un artefacto de autenticación portable que sobreviva una decisión de routing. La guía de la industria para resolverlo es consistente: el merchant es dueño del 3DS Server, se vuelve PCI-L1 compliant donde es requerido, y corre la autenticación una sola vez antes de seleccionar el PSP. El resultado de la autenticación, ECI y CAVV incluidos, después se pasa al PSP que vaya a autorizar la transacción.

Esta es la arquitectura que el practitioner preguntando por "3DS standalone" sabía que existía. No es un gap de producto. Es una pregunta de patrón de despliegue. Que el 3DS Server del merchant sea independiente de la capa de routing del PSP es la pregunta que determina si el cascading de soft decline funciona sin re-autenticar al cliente, si el merchant puede aceptar delegated authentication bajo la PSR, y si la migración a AES en 2028 es un proyecto único o tres.

‍

Un escenario que debería resultar familiar

Un marketplace de alto volumen operando en EE.UU. y Europa integra tres PSPs hace dieciocho meses para expandir cobertura de acquiring. Cada PSP maneja 3DS a su manera y cumple su SLA individual. En el mes nueve, el equipo construye un dashboard a nivel BIN uniendo autenticación con routing por PSP, y descubre un spread de seis a ocho puntos en tasa frictionless entre los tres PSPs sobre BINs superpuestos. El PSP con el frictionless rate más bajo es también el más barato en fees de acquiring, así que las reglas de routing le mandan el mayor volumen. El arrastre de conversión, anualizado, excede el ahorro de acquiring por un orden de magnitud.

El fix no es un cambio de regla de routing. El fix es mover el 3DS Server fuera de los tres PSPs y a la capa de orchestration, para que el mismo flagging de exenciones, la misma población de datos, y el mismo manejo de fallback apliquen sin importar qué PSP autoriza. El equipo que haga esto en 2026 tiene datos limpios a nivel BIN entrando a la ventana de enforcement de la PSR. El equipo que lo posponga reconstruye la misma arquitectura bajo presión de deadline en 2027.

‍

El costo asumido

Ser dueño del 3DS Server en la capa de orchestration no es el camino de menor esfuerzo. Requiere certificación directa contra EMV 3DS, mantenimiento ongoing a medida que avanza el protocolo, y responsabilidad operacional por un componente que solía estar adentro del PSP. El primer trimestre corriéndolo produce menos time-to-launch que delegarlo a un PSP. Los números cambiaron porque la variabilidad por PSP se compone cada mes que la arquitectura está mal, y la ventana regulatoria para convertir esa variabilidad de costo a capacidad se cierra entre fines de 2026 y 2027.

El costo de correr 3DS fragmentado se paga todos los meses en autorizaciones perdidas y conversiones perdidas. El costo de unificarlo se paga una sola vez.

‍

Qué deberían evaluar los operadores multi-PSP antes de agregar el próximo PSP

El diagnóstico es corto. ¿Dónde vive el 3DS Server por cada PSP integrado? Si la respuesta es "adentro del PSP", la lógica de exenciones, el comportamiento del challenge rate, y el manejo del soft decline están configurados por PSP en lugar de por merchant. ¿Qué flags de exención se piden en qué transacciones, y por la política por defecto de qué PSP? Si el merchant no puede responder sin abrir la UI de configuración de cada PSP, la política está fragmentada. ¿Qué pasa cuando un soft decline en PSP A cascadea al PSP B? Si el cliente enfrenta un segundo challenge SCA, el manejo de fallback es lo siguiente en moverse a la capa de orchestration. ¿Quién carga con la responsabilidad por SCA cuando la PSR entre en vigor? Si la respuesta es "el PSP", el merchant no tiene camino para optimizar la economía de conversión en la capa de autenticación.

EMV 3DS estandarizó el formato del mensaje. La estandarización que importa para el operador multi-PSP - la parte donde exenciones, challenges y fallbacks se comportan igual sin importar qué PSP autorizó - quedó como tarea a cargo del merchant. Hace tres años era fácil de posponer porque la variabilidad era chica y la responsabilidad regulatoria vivía con el emisor. Los próximos doce meses definen si la termina el operador que decide hacerse cargo, o si la pospone el que sigue asumiendo que sus PSPs la hacen por él. Quien sea dueño del 3DS Server es dueño de la política. Esa es la parte que sigue pendiente.