Qué es el 3D Secure y por qué tu cliente no consigue pagar

Si un cliente te dice que su tarjeta funciona en otras webs pero en la tuya no, lo más probable es que el pago se esté cayendo en el paso de autenticación: el 3D Secure es la verificación que tu banco y el del cliente hacen antes de aprobar un cobro con tarjeta, y cuando ese paso falla el pago se rechaza aunque haya saldo de sobra. No es un fallo de tu tienda ni un capricho de la pasarela: es una obligación legal en Europa desde que se aplica la autenticación reforzada de cliente. Lo que sí está en tu mano es que ese paso se dé bien, se dé rápido y se dé las menos veces posibles.

Qué es exactamente el 3D Secure

El 3D Secure (3DS) es un protocolo que añade un paso de verificación entre el momento en que tu cliente pulsa «Pagar» y el momento en que el banco aprueba el cobro. En la práctica es esa pantalla o notificación en la que el cliente confirma la compra desde la aplicación de su banco, con huella, cara o un código.

El nombre viene de los tres «dominios» que participan: el banco del comprador, el banco que te ingresa el dinero y la red de la tarjeta que los conecta. La versión vigente es 3-D Secure 2, especificada por EMVCo, el organismo que reúne a las principales redes de tarjetas. La diferencia clave frente a la versión antigua es que 3DS2 envía al banco del comprador mucha más información de contexto (dispositivo, historial, importe, dirección de envío) para que pueda decidir si hace falta molestar al cliente o no.

Ese cambio es importante para ti: con 3DS2 bien implementado, buena parte de los pagos se aprueban sin que el cliente tenga que hacer nada. Es lo que en la jerga se llama flujo «sin fricción».

Por qué es obligatorio y no puedes desactivarlo

La autenticación reforzada de cliente, conocida como SCA, viene de la normativa europea de servicios de pago. La directiva de pagos PSD2 la establece y el Reglamento Delegado (UE) 2018/389 detalla cómo debe funcionar: el pago necesita al menos dos factores independientes de entre algo que el cliente sabe (un PIN), algo que tiene (su móvil) y algo que es (su huella o su cara).

Eso significa que ni tú ni tu proveedor podéis «quitar el 3D Secure» para vender más. Si un desarrollador o una pasarela te ofrece eso para operaciones europeas, desconfía: lo que conseguirás es que los bancos rechacen las operaciones directamente. Lo que sí permite la norma es aplicar exenciones concretas, que es justo la parte que casi nadie configura bien.

Las cinco causas reales de que el pago se rechace

Cuando revisas un carrito que no ha cuajado, el rechazo casi siempre entra en una de estas cinco cajas:

El cliente abandona la pantalla de autenticación. No reconoce la pantalla del banco, le llega la notificación cuando ya ha cerrado el navegador, o no tiene la aplicación del banco instalada en ese móvil. Es la causa más frecuente en móvil.
El comercio no envía datos suficientes. Si tu integración manda solo el importe y el número de tarjeta, el banco del comprador no tiene contexto para aprobar sin preguntar y fuerza la verificación siempre. Peor aún: si faltan datos obligatorios, puede rechazar sin más.
El banco del cliente decide que la operación es de riesgo. Importe alto, país distinto al habitual, primera compra en tu tienda, varios intentos seguidos. Aquí decide el banco emisor, no tú.
La integración no gestiona bien el retorno. El cliente se autentica correctamente, pero tu web pierde el hilo al volver de la pasarela y el pedido queda colgado. Para el cliente es indistinguible de un rechazo.
Datos que no cuadran. Tarjeta caducada, dirección de facturación distinta a la del banco, o el nombre del titular escrito de otra manera en un formulario que valida de más.

Fíjate en que solo la tercera está fuera de tu control. Las otras cuatro se arreglan con configuración y desarrollo.

Cómo saber cuál es tu caso

Antes de tocar nada, necesitas ver los rechazos. Toda pasarela profesional te da el código de respuesta de cada operación en su panel de administración: ahí verás si el pago murió en la autenticación, si lo denegó el banco emisor o si nunca llegó a salir de tu web.

Haz esto durante una semana:

Exporta las operaciones fallidas de tu pasarela con su código de error y la fecha.
Cruza esa lista con los pedidos que se quedaron en estado «pendiente de pago» en tu tienda. Los que están en la tienda pero no en la pasarela indican un problema de integración, no de banco.
Separa móvil de escritorio. Si el desastre está en móvil, tu problema es de flujo y de pantalla, no de normativa.
Mira si se repiten tarjetas o clientes. Un mismo cliente con cinco intentos fallidos es un caso de soporte, no una estadística.

Con esa tabla delante, la conversación con tu desarrollador o con tu banco deja de ser una queja y pasa a ser un diagnóstico.

Las exenciones que sí puedes aprovechar

El Reglamento Delegado (UE) 2018/389 contempla supuestos en los que se puede pedir al banco que apruebe sin autenticación. Estas son las que más se usan en comercio electrónico:

Exención	En qué consiste	Cuándo te interesa
Importe reducido	Operaciones de pequeño importe, con límites acumulados por número de operaciones y por suma total desde la última autenticación	Tickets bajos y compras repetidas: consumibles, recambios, contenidos
Análisis de riesgo de la operación	El proveedor de pago asume el análisis del riesgo y puede pedir la exención si su nivel de fraude se mantiene bajo	Tiendas con volumen y buen historial; lo aplica tu pasarela, no tú
Beneficiario de confianza	El cliente marca tu comercio como fiable en su banco y deja de autenticar cada compra	Clientes recurrentes; conviene sugerirlo tras la primera compra
Pagos iniciados por el comercio	Cobros recurrentes con un mandato ya autenticado la primera vez	Suscripciones, cuotas, renovaciones automáticas

Ninguna de estas exenciones es un atajo que activas y te olvidas: la decisión final siempre es del banco emisor, que puede pedir autenticación de todos modos. Pero pedirlas bien cambia mucho la proporción de pagos que pasan sin fricción.

Qué pedir a tu desarrollador para arreglarlo

Lleva esta lista a quien mantiene tu tienda. Son cosas concretas y comprobables:

Enviar todos los datos opcionales de 3DS2: dirección de facturación y envío, correo, teléfono, datos del dispositivo y del navegador. Cuanta más información, más probabilidad de flujo sin fricción.
Usar el flujo integrado en lugar de redirigir al cliente a otra web cuando la pasarela lo permita. Menos saltos, menos abandono.
Gestionar el retorno con webhooks y no depender de que el navegador del cliente vuelva a tu web. Así el pedido se confirma aunque el cliente cierre la pestaña.
Guardar y mostrar el código de rechazo en el panel de pedidos, para que atención al cliente sepa qué ha pasado sin abrir la pasarela.
Mostrar un mensaje útil al cliente: «tu banco no ha confirmado la operación, inténtalo de nuevo o prueba con otra tarjeta» en lugar de un error genérico.
Ofrecer una alternativa inmediata: Bizum, transferencia o pago en otra tarjeta en la misma pantalla del fallo.
Probar de verdad en el entorno de pruebas de tu pasarela, con los casos de autenticación correcta, autenticación fallida y abandono a mitad.

Qué puedes hacer tú desde mañana sin tocar código

Hay decisiones de negocio que reducen rechazos y no dependen del desarrollo:

Avisa antes del pago. Un aviso en el checkout del tipo «tu banco te pedirá confirmar la compra desde su aplicación» evita muchísimos abandonos por desconcierto.
No pidas datos de más. Cada campo obligatorio innecesario es una oportunidad de error de validación.
Revisa el nombre del comercio que aparece en el extracto y en la pantalla del banco. Si no se parece a tu marca, el cliente duda y cancela.
Recupera los pedidos caídos. Un correo automático al cliente cuyo pago falló, con enlace para reintentar, rescata ventas que ya estaban hechas.
Habla con tu banco adquirente. Si el rechazo viene sistemáticamente de un emisor concreto, tu banco puede investigarlo.

En resumen: el 3D Secure no es el enemigo

El 3D Secure protege a tu cliente y a ti frente al fraude, y además es obligatorio en Europa, así que la pregunta útil no es cómo evitarlo sino cómo hacer que pase desapercibido. Mide los rechazos con los códigos de tu pasarela, envía toda la información que 3DS2 permite, aprovecha las exenciones que te correspondan, gestiona el retorno del pago con webhooks y explica al cliente qué va a ocurrir antes de que ocurra. Con eso, la mayoría de las tiendas pasan de un checkout que pierde pedidos sin explicación a uno en el que los pagos se aprueban solos.

Si estás viendo rechazos y no sabes si el problema está en tu integración, en la configuración de la pasarela o en el flujo del checkout, cuéntanos cómo cobras en tu tienda y revisamos contigo dónde se está cayendo el dinero.