ZHENESJAKOTHVIRUFRAR

3D Secure

Definición

3D Secure (3DS) es un protocolo de autenticación adicional impulsado por las grandes redes de tarjetas —Visa, Mastercard, American Express y Discover— que añade una capa extra de verificación cuando un cliente paga online. Su objetivo es confirmar que quien está introduciendo los datos de la tarjeta es realmente el titular legítimo, y no un ciberdelincuente que ha robado el número.

En el ecosistema DTC y de ecommerce, 3DS se traduce en la práctica en esa pantalla que aparece tras pulsar «Pagar»: el banco del comprador le envía un código SMS, le pide confirmar en su app bancaria o le solicita una huella/rostro. Solo si supera esa verificación, el pago se autoriza.

El nombre «3D» proviene de las tres dimensiones de seguridad que cubre: el emisor (el banco del cliente), el adquirente (el banco del comercio) y el dominio de interoperabilidad (la red de la tarjeta que conecta ambos).


Analogía

Piensa en 3DS como el portero automático de un edificio de oficinas.

Cuando llegas a la puerta con tu tarjeta de acceso, el sistema no te deja entrar directamente: primero comprueba con la central (tu banco) si realmente eres tú. La central te llama al móvil, te pide un código o te reconoce la cara. Solo entonces el portero te abre.

En ecommerce ocurre lo mismo: el comercio no decide por sí solo si el pago es legítimo; delega la decisión final en el banco del cliente. Esa cesión de responsabilidad es clave, porque cambia quién asume el coste si hay fraude.


Cómo funciona (fórmula operativa)

El flujo estándar de una transacción con 3DS 2.0 se resume así:

Pago autorizado = (Datos de tarjeta válidos)
                 × (Autenticación 3DS superada)
                 × (Fondos disponibles)

Donde la autenticación se resuelve mediante frictionless flow (el banco aprueba sin pedir nada al cliente) o challenge flow (se solicita OTP, biometría o confirmación en app).

Tres datos concretos para dimensionar su impacto en DTC:

- Reducción del fraude: 3DS 2.0 disminuye el fraude en pagos online hasta un 70 % en comercios que lo implementan correctamente.

- Conversión: en España, la tasa de abandono en el *challenge flow* ronda el 15-25 %, frente al 5-8 % del *frictionless flow*.

- Coste del chargeback: cada contracargo fraudulento cuesta al comercio entre 15 € y 25 € en comisiones, además del importe perdido; 3DS traslada esa responsabilidad al emisor en la mayoría de casos.


3DS 1.0 vs 3DS 2.0: comparativa

Característica3DS 1.03DS 2.0
Experiencia de usuarioRedirección a página del banco, siempreFlujo invisible o *challenge* según riesgo
DispositivosSolo navegador webWeb, app móvil, wallets, IoT
Datos analizadosPocos (importe, tarjeta)+150 variables (dispositivo, historial, geolocalización)
AutenticaciónContraseña estática / OTPBiometría, app bancaria, OTP dinámico
Compatibilidad PSD2/SCALimitadaNativa, cumple SCA europea
Tasa de conversión típicaBaja (abandono 20-30 %)Alta (abandono 5-15 %)
Responsabilidad por fraudeCompartidaTrasladada al emisor si se autentica

Aplicación en DTC y ecommerce

1. Cumplimiento PSD2/SCA en Europa

Desde 2021, la normativa europea exige Strong Customer Authentication (SCA) en la mayoría de pagos online. 3DS 2.0 es el mecanismo estándar para cumplirla. Sin él, el banco puede rechazar la transacción directamente.

2. Optimización de conversión

Los comercios DTC configuran reglas de exención (Low Value, TRA – Transaction Risk Analysis) para no pedir verificación en pedidos de bajo importe o bajo riesgo. Por ejemplo, pedidos por debajo de 30 € suelen pasar sin *challenge*.

3. Suscripciones y recurrencia

En modelos de suscripción (skincare, café, suplementos), 3DS se aplica en el primer pago y luego se usan *merchant-initiated transactions* (MIT) exentas, siempre que se marquen correctamente las banderas.

4. Checkout móvil

Las apps nativas usan 3DS SDK, que permite la verificación biométrica dentro de la propia app sin salir a un navegador. Esto eleva la conversión en móvil, donde se produce más del 60 % del tráfico DTC en España.


Errores comunes

1. Creer que 3DS elimina todo el fraude. Reduce el fraude por tarjeta robada, pero no el *friendly fraud* (el propio cliente que luego dice no haber comprado). Ese sigue siendo responsabilidad del comercio.

2. Activar 3DS sin estrategia de exenciones. Forzar el *challenge* en todos los pagos hunde la conversión. Hay que segmentar por importe, historial y país.

3. No configurar correctamente los códigos de respuesta. Un authentication failed mal mapeado puede hacer que el cliente vea un error genérico y abandone, cuando en realidad podría reintentar.

4. Ignorar la analítica de *challenge*. Medir la tasa de *challenge* y la de éxito por emisor permite ajustar reglas y detectar bancos problemáticos.

5. Confundir 3DS con tokenización. Son capas distintas: 3DS autentica al titular; la tokenización sustituye el número de tarjeta por un token. Se complementan, no se sustituyen.

6. No informar al cliente. Un mensaje claro antes del *challenge* («Tu banco va a pedirte una confirmación») reduce el abandono hasta un 10 %.


Términos relacionados

- SCA (Strong Customer Authentication): requisito regulatorio europeo que 3DS ayuda a cumplir.

- PSD2: directiva europea de servicios de pago que introdujo SCA.

- Chargeback: contracargo; 3DS mitiga los fraudulentos.

- Frictionless flow: autenticación sin interacción del cliente.

- Challenge flow: autenticación con verificación activa (OTP, biometría).

- MIT (Merchant-Initiated Transaction): transacción iniciada por el comercio, típica en suscripciones.

- Tokenización: sustitución del PAN por un token seguro.

- Payment Orchestrator: plataforma que enruta pagos y decide cuándo aplicar 3DS.

- TRA (Transaction Risk Analysis): análisis de riesgo que permite exenciones de SCA.


En resumen: 3DS no es un simple «paso extra» en el checkout, sino una palanca estratégica que equilibra seguridad, cumplimiento normativo y conversión. Bien implementado, protege al comercio del fraude y del coste del chargeback; mal configurado, se convierte en la principal causa de carritos abandonados en DTC.