Resumen
La norma 3D Secure (también conocida por los nombres comerciales asociados a las redes de tarjetas como Visa Secure, Mastercard Identity Check o American Express SafeKey), tiene el objetivo de reducir el fraude y lograr que los pagos electrónicos sean más seguros.
3D Secure 2 (3DS2) ofrece una «autenticación sin fricciones» y mejora la experiencia de compra en comparación con su predecesora: 3D Secure 1. Se trata del principal método de autenticación de tarjetas para cumplir con los requisitos de la autenticación reforzada de clientes (SCA) en Europa y un mecanismo clave para que las empresas soliciten exenciones con relación a la SCA.
Stripe admite 3D Secure 2 en nuestras API de pagos, SDK para dispositivos móviles y Stripe Checkout.
Breve historia de 3D Secure 1
A pesar de las medidas de seguridad adicionales, como el sistema de verificación de domicilio (AVS) o la verificación del CVC utilizados en algunos mercados, los pagos con tarjetas de crédito y débito aún pueden presentar un alto riesgo de fraude. De hecho, ese alto riesgo es el causante de que los clientes puedan disputar pagos fraudulentos efectuados con sus tarjetas.
Para abordar este problema, las redes de tarjetas implementaron la primera versión de 3D Secure en 2001. Si sueles comprar artículos en línea, es posible que estés familiarizado con el flujo de 3D Secure: ingresas los datos de tu tarjeta para confirmar un pago y, luego, se te redirige a otra página donde tu banco te solicita un código o una contraseña para aprobar la compra. Como estas páginas de autenticación incluyen elementos de las marcas de las redes de tarjetas, la mayoría de los clientes suelen estar más familiarizados con los nombres comerciales de 3D Secure, como Visa Secure, Mastercard Identity Check o American Express SafeKey.
Las ventajas que el uso de 3D Secure aporta a las empresas es evidente, al solicitar una capa adicional de protección contra el fraude para garantizar que solo se acepten pagos con tarjeta de clientes legítimos. Como incentivo adicional, autenticar un pago con 3D Secure se transfiere la responsabilidad por los contracargos causados por transacciones fraudulentas de la empresa al banco del cliente. Esta protección adicional es la razón por la que 3D Secure suele aplicarse a compras grandes, como boletos de avión.
A pesar de las muchas ventajas, el uso de 3D Secure 1 también tiene algunos inconvenientes: el paso adicional necesario para completar el pago agrega fricción al flujo de compra y puede llevar a los clientes a que abandonen la compra. Además, algunos bancos siguen obligando a que los titulares de tarjetas creen y recuerden contraseñas estáticas para completar la verificación con 3D Secure. Si los clientes no consiguen recordar rápidamente su contraseña en el momento de la verificación adicional, la tasa de abandono del carrito puede incrementar de forma significativa.
¿En qué se distingue de 3D Secure 2?
EMVCo, una organización formada por seis grandes redes de tarjeta, lanzó una nueva versión de 3D Secure. El protocolo 3D Secure 2 (también conocido como EMV 3-D Secure, 3D Secure 2.0 o 3DS2) tiene como objetivo solucionar muchos de los defectos de 3D Secure 1 que mencionamos en la sección anterior a través de una autenticación menos problemática y una mejor experiencia de usuario.
Autenticación sin fricciones
3D Secure 2 permite que las empresas y sus proveedores de servicios de pagos envíen más datos sobre cada transacción al banco del titular de la tarjeta, además de los datos específicos del pago (como la dirección de envío), también se comparten datos contextuales, como el ID del dispositivo del cliente o el historial de transacciones anteriores.
El banco del titular de la tarjeta puede utilizar esta información para evaluar el nivel de riesgo de la transacción y seleccionar una respuesta adecuada:
Si los datos son suficientes para que el banco confíe en que el titular real de la tarjeta es quien hace la compra, la transacción pasa por el flujo «sin fricciones» y la autenticación se completa sin necesidad de un proceso de verificación adicional.
Si el banco decide que necesita más pruebas, la transacción pasa por el flujo de «comprobación» y se le pide al cliente que proporcione información adicional para autenticar el pago.
Si bien 3D Secure 1 ya disponía de un sistema de autenticación basado en el riesgo, este era bastante limitado. Con 3D Secure 2, esa posibilidad de compartir más datos tiene como objetivo aumentar la cantidad de transacciones que se pueden autenticar sin pasos adicionales para el cliente.
Ejemplo del flujo de autenticación de un pago usando 3D Secure 2 con soporte para 3D Secure 1 como alternativa
Aunque la transacción siga el flujo sin fricciones, la empresa obtendrá el mismo beneficio de la transferencia de responsabilidad que con las transacciones que pasen por un flujo de comprobación.
Una mejor experiencia de usuario
A diferencia de su predecesora, 3D Secure 2 se diseñó después del surgimiento de los teléfonos inteligentes y permite que los bancos ofrezcan experiencias innovadoras de autenticación a través de sus aplicaciones móviles (en ocasiones denominada «autenticación fuera de banda»). En lugar de ingresar una contraseña o de recibir un mensaje de texto, el titular de la tarjeta puede usar su huella digital o incluso el reconocimiento facial a través de la aplicación del banco para autenticar un pago. Prevemos que muchos bancos ofrecerán estas experiencias de autenticación más rápidas y sencillas con 3D Secure 2.
La segunda mejora con respecto a la experiencia de usuario es que 3D Secure 2 está diseñada para integrar el flujo de comprobación directamente dentro de los flujos de compra, tanto en el sitio web y a través del dispositivo móvil, sin necesidad de redirigir al usuario a una página distinta. Si un cliente realiza la autenticación en tu sitio o página web, la confirmación de 3D Secure ahora aparece de forma predeterminada en un cuadro de diálogo modal en la página de checkout (flujo de navegador).
Flujo de navegador de 3D Secure 2
Si estás desarrollando una aplicación, los SDK para dispositivos móviles creados para 3D Secure 2 te permiten diseñar un flujo de autenticación en la propia aplicación (lo que se conoce en inglés como un in-app flow) y evitar por completo los redireccionamientos desde el navegador.
3D Secure 1: flujo de autenticación móvil mediante redireccionamiento al navegador
3D Secure 2 (3DS2): flujo de autenticación móvil mejorado dentro de la aplicación
3D Secure 2 y la autenticación reforzada de clientes
La introducción de la autenticación reforzada de clientes (SCA) hace que 3D Secure 2 sea aún más importante si haces negocios en Europa. Esta normativa te exige aplicar una autenticación adicional en los pagos europeos, por lo que la experiencia de usuario mejorada que ofrece 3D Secure 2 puede reducir el impacto negativo en la conversión.
El protocolo 3D Secure 2 también permite que los proveedores de servicios de pago como Stripe puedan solicitar exenciones a la SCA y, así, evitar que los pagos de bajo riesgo tengan que pasar por una autenticación adicional. Los pagos que requieran SCA deberán pasar por el flujo de «comprobación», mientras que las transacciones eximidas de dicha autenticación podrán pasar por el flujo «sin fricciones». Sin embargo, es importante tener en cuenta que si el proveedor de servicios de pagos solicita una exención para los pagos que requieren SCA y la transacción pasa por el flujo «sin fricciones», no se beneficiará de la transferencia de responsabilidad.
¿De qué forma Stripe admite 3D Secure 2?
Stripe admite el flujo de autenticación por navegador de 3D Secure 2 en nuestras API de pagos y Stripe Checkout, lo que te permite aplicar 3D Secure de forma dinámica a los pagos de alto riesgo para proteger tu empresa contra el fraude. Aplicaremos 3D Secure 2 siempre que sea compatible con el banco del titular de la tarjeta y solo recurriremos a 3D Secure 1 si el banco todavía no admite la nueva versión.
Si estás desarrollando una aplicación móvil, nuestros SDK para iOS y Android te permiten crear un flujo de autenticación en la aplicación para ofrecer una experiencia de autenticación «nativa». De este modo, no es necesario redirigir a tus clientes fuera de la aplicación. Además, si el banco del titular de la tarjeta todavía no acepta 3D Secure 2, nuestros SDK para dispositivos móviles mostrarán de forma dinámica una vista web para 3D Secure 1 incorporada en tu aplicación.
Obtén más información sobre nuestras API para pagos, SDK para dispositivos móviles o Stripe Checkout para empezar a usar 3D Secure 2.
|
MIT
|
En el caso de las transacciones iniciadas por el comerciante (MIT), la SCA solo debe aplicarse en el momento de configurar la orden, pero no para las MIT posteriores. Para estas transacciones, se introduce un derecho de reembolso incondicional de ocho semanas, similar al de los débitos directos SEPA. |
|---|---|
|
MOTO
|
Si se trata de transacciones de pedidos telefónicos o por correo (MOTO), el requisito de que no sea digital solo se aplica al inicio de la transacción de pago a fin de que esta pueda estar exenta de la SCA. |
|
Enlace dinámico
|
Los elementos de la SCA que enlazan de forma dinámica la transacción con un importe específico y un emisor del pago deben usarse para las transacciones de pago electrónico en las que se efectúa un pago a través del dispositivo de quien emite el pago mediante la tecnología de proximidad (por ejemplo, la comunicación de campo cercano, o NFC), y la aplicación de la SCA exige el uso de Internet en el dispositivo del emisor del pago. |
|
Servicios de información de cuentas
|
En el caso de los PSP que prestan servicios de información de cuentas en el marco de la banca abierta, la SCA solo se exige en el primer acceso a los datos. Sin embargo, la SCA es obligatoria cuando los clientes acceden a los datos agregados de la cuenta en el dominio del proveedor de servicios de información de cuentas, al menos cada 180 días. |
|
Tokenización
|
La tokenización exige la aplicación de la SCA cuando el titular de la tarjeta participa activamente en el proceso de tokenización (por ejemplo, al registrar o reemplazar una tarjeta en una billetera o en una solución de registro de tarjetas). |
|
Supervisión de las transacciones
|
La Autoridad Bancaria Europea establecerá Normas técnicas de regulación para la supervisión de las transacciones a cargo de los proveedores de servicios de pago, que tendrán en cuenta factores ambientales y de comportamiento (por ejemplo, la ubicación del cliente o los hábitos de gasto). Esto fundamenta el uso de las exenciones a la SCA para las transacciones que plantean un nivel de riesgo bajo (por ejemplo, exenciones de análisis de riesgo de las transacciones). |
|---|---|
|
Exenciones de la SCA
|
La ABE también se encarga de elaborar Normas técnicas de regulación adicionales sobre los requisitos y exenciones de la SCA, para lo que tiene en cuenta un enfoque basado en el riesgo y el uso de la tecnología. |
|
Autenticación en dos pasos
|
Las nuevas reglas sugieren que los factores utilizados para la autenticación en dos pasos en el marco de la SCA no tienen por qué pertenecer a categorías diferentes, siempre que su independencia se conserve plenamente. Esto podría permitir a los clientes autenticarse con dos contraseñas, o bien con una huella y reconocimiento facial. |
|
Accesibilidad
|
Los PSP deben ofrecer diferentes formas de aplicar la SCA, por ejemplo, mediante SMS, que no dependan del uso de un dispositivo inteligente. |
|
Responsabilidades para los proveedores de servicios técnicos (TSP)
|
Los TSP y los operadores de los sistemas de pago asumirán la responsabilidad por la falta de soporte en la aplicación de la SCA. Con esto, se pretende garantizar una mayor cooperación entre todas las partes que participen en la aplicación de la SCA. |
|---|---|
|
Externalización
|
Los proveedores de servicios de pago que dependan de los proveedores de servicios técnicos para ofrecer y verificar elementos de la SCA deben tercerizar acuerdos con estos proveedores. La ABE establecerá los requisitos para estos acuerdos externos. |