Resumen
La normativa 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 como finalidad reducir el fraude y hacer más seguros los pagos por Internet.
3D Secure 2 (3DS2) incorpora una «autenticación sin fricciones» y mejora la experiencia de compra en comparación con su predecesora: 3D Secure 1. Con la entrada de la normativa de autenticación reforzada de clientes (SCA) en Europa, 3DS2 se convierte en el principal método de autenticación de tarjetas y un mecanismo imprescindible para que las empresas puedan solicitar exenciones a la SCA.
Stripe admite 3D Secure 2 en nuestras API para pagos, SDK para móviles y Stripe Checkout.
Breve historia de 3D Secure 1
A pesar de las medidas de seguridad adicionales, como la verificación CVC que se utiliza en algunos mercados o el sistema de verificación de domicilio (AVS, por sus siglas en inglés), los pagos con tarjeta 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 realizados con su tarjeta.
Para abordar este problema, las redes de tarjetas implementaron la primera versión de 3D Secure en 2001. Si sueles comprar artículos por Internet, es probable que conozcas el flujo de 3D Secure: introduces 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 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 3D Secure aporta a las empresas son evidentes: al solicitar información adicional, se añade 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, al 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 añadida es uno de los motivos principales por los que 3D Secure se aplica a menudo a compras de importes elevados, como los billetes de avión.
A pesar de sus muchas ventajas, 3D Secure 1 también tiene algunos inconvenientes: ese paso adicional a la hora de completar el pago añade fricción al flujo del checkout y puede hacer que los clientes 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 de 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 de carritos puede aumentar significativamente.
¿Cuáles son las diferencias con 3D Secure 2?
EMVCo, una organización formada por seis grandes redes de tarjetas, lanzó una nueva versión de 3D Secure. 3D Secure 2 (también conocida como EMV 3-D Secure, 3D Secure 2.0 o 3DS2) tiene como objetivo eliminar muchos de los inconvenientes de 3D Secure 1 que mencionamos en la sección anterior a través de una autenticación menos disruptiva 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 que se haya elegido para el envío), también se comparten datos contextuales, como el identificador 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 realiza la compra, la transacción pasa por el flujo «sin fricción» y la autenticación se completa sin necesidad 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 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
Otra nota positiva de 3D Secure 2 es que las empresas se benefician de la transferencia de la responsabilidad tanto para las transacciones que siguen el flujo sin fricciones como para las que pasan por un flujo con comprobación.
Una mejor experiencia del usuario
A diferencia su predecesora, 3D Secure 2 se diseñó tras la aparición de los smartphones y permite que los bancos ofrezcan experiencias de autenticación más modernas a través de sus aplicaciones bancarias para móviles (en ocasiones denominada «autenticación fuera de banda»). En lugar de introducir una contraseña o de recibir un mensaje de texto, el titular de la tarjeta puede autenticar el pago a través de la aplicación bancaria usando su huella digital o mediante el reconocimiento facial. Prevemos que muchos bancos ofrecerán estas experiencias de autenticación más rápidas y sencillas con 3D Secure 2.
La segunda mejora en la experiencia del usuario es que 3D Secure 2 está diseñada para integrar estas comprobaciones en el propio flujo del proceso de compra, tanto en la web como en el móvil, sin necesidad de redireccionar al usuario a una páginas distinta. Si un cliente se autentica en tu sitio web, la confirmación de 3D Secure ahora aparece de forma predeterminada en un cuadro de diálogo modal en la página del checkout (flujo de autenticación por navegador).
Flujo de autenticación por navegador con 3D Secure 2 (3DS2)
Si estás creando una aplicación, los SDK móviles creados para 3D Secure 2 te permiten crear un flujo de autenticación en la propia aplicación (lo que se conoce en inglés como un in-app flow) y evitar 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 trabajas con clientes europeos. Esta normativa te obliga a aplicar una autenticación adicional para los pagos en Europa, por lo que la experiencia de usuario mejorada de 3D Secure 2 puede reducir el impacto negativo en la conversión.
El protocolo 3D Secure 2 también permite que los proveedores de pagos 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 requieren SCA deberán pasar por el flujo de «comprobación», mientras que las transacciones que pueden estar exentas de SCA se pueden enviar a través del flujo «sin fricción». Sin embargo, es importante señalar 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 fricción», no se beneficiará de la transferencia de responsabilidad.
¿Cómo aplica Stripe el estándar 3D Secure 2?
Stripe admite el flujo de autenticación por navegador de 3D Secure 2 desde nuestras API de pagos y Stripe Checkout, lo que te permite aplicar 3D Secure de manera dinámica a los pagos de alto riesgo para proteger tu negocio 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 acepta la nueva versión.
Si estás creando una aplicación móvil, nuestros SDK de iOS y Android te permiten crear un flujo de autenticación desde la propia aplicación para ofrecer una experiencia de autenticación nativa; de este modo, evitarás tener que redirigir a tus clientes fuera de la aplicación. Además, si el banco del titular de la tarjeta no admite 3D Secure 2, nuestros SDK para dispositivos móviles mostrarán de forma dinámica una vista web para 3D Secure 1 incrustada en tu aplicación.
Obtén más información sobre nuestras API para pagos, los SDK para 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 adeudos 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 beneficiario deben usarse para las transacciones de pago electrónico en las que se efectúa un pago a través del dispositivo de un pagador 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 pagador. |
|
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 un monedero o en una solución de registro de tarjetas). |
|
Supervisión de las transacciones
|
La Autoridad Bancaria Europea publicará 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 a la SCA
|
La ABE también se encarga de elaborar normas técnicas de regulación sobre los requisitos y las 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 disposiciones 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 el reconocimiento facial. |
|
Accesibilidad
|
Los PSP deben ofrecer diferentes formas de aplicar la SCA, como la recepción de SMS, que no dependan de la posesión de un dispositivo inteligente. |
|
Responsabilidades para los PST
|
Los proveedores de servicios técnicos (PST) 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 ello se pretende garantizar una mayor cooperación entre todos los agentes que participan en la aplicación de la SCA. |
|---|---|
|
Externalización
|
Los proveedores de servicios de pago que dependen de los PST para ofrecer y verificar elementos de la SCA deben suscribir acuerdos de externalización con los PST. La ABE establecerá los requisitos para estos acuerdos de externalización. |