3DS 2.2: frictionless, challenge y la ingeniería entre medias

3-D Secure 2.2 divide la autenticación en dos caminos. Frictionless: el emisor confía en los datos de riesgo que viajan con la petición y aprueba en silencio — el cliente nunca ve un challenge. Challenge: el emisor quiere pruebas y el cliente pasa por OTP o biometría. La diferencia de conversión entre ambos es enorme, así que la verdadera pregunta de producto es quién decide qué camino se dispara.

La respuesta ingenua es “siempre challenge” (seguro, mata la conversión) o “nunca” (rápido, desplaza la responsabilidad hacia el lado equivocado). La respuesta correcta es adaptativa: puntúa primero la transacción y pide el challenge solo cuando el riesgo lo justifica. El cliente recurrente en un dispositivo conocido pasa flotando; la primera compra a medianoche desde un dispositivo nuevo sube el escalón.

La ingeniería de debajo es donde la mayoría de integraciones se rompen en silencio. El ACS redirige al cliente de vuelta con un callback — y las implementaciones del ACS reintentan callbacks. Si tu handler no es idempotente, un callback doble se convierte en un cargo doble. La solución es una clave de idempotencia compuesta sobre (intent, transacción de autenticación): el primer callback gana y cada reintento recibe el mismo resultado guardado.

Luego está el zoológico de fallos: el cliente abandona a mitad del challenge, el banco agota el tiempo, el redirect nunca llega. Cada uno debe aparcar el pago en un estado explícito de “sin resolver” y dejar que un barrido de conciliación establezca la verdad después — nunca adivines. Y si la propia iniciación 3DS falla en un adquirente, un failover pre-3DS puede reenrutar el intento a otro banco antes de que el cliente note nada.

Bien hecho, 3DS deja de ser un impuesto a la conversión. Se convierte en un instrumento de precisión: fricción exactamente donde vive el fraude, invisible en todo lo demás.