¿Falló la autenticación 3D Secure de tu tarjeta cripto? Causas y soluciones

Al comprar por internet o pagar suscripciones con una tarjeta de pago vinculada a criptoactivos, puede ocurrir algo desconcertante: la tarjeta tiene saldo suficiente, el número y la fecha de vencimiento son correctos, pero la página de pago muestra «3D Secure authentication failed» o «Authentication unsuccessful». En ocasiones, el titular incluso completa la verificación de identidad y, aun así, el pago falla.

Estos mensajes no necesariamente indican el mismo problema. La transacción puede haberse interrumpido durante la autenticación 3D Secure o haber superado esa etapa y ser rechazada posteriormente durante la autorización del pago.

Para investigar el problema, primero hay que identificar en qué etapa se produjo el fallo. Esto permitirá determinar si corresponde revisar la configuración de la tarjeta, contactar al comercio o solicitar asistencia al emisor.

¿Qué significa realmente un fallo de autenticación 3D Secure?

3D Secure (3DS) es un protocolo de autenticación para transacciones en línea con tarjetas bancarias, basado principalmente en el estándar EMV 3-D Secure. Permite que comercios, proveedores de servicios de pago, redes de tarjetas y emisores intercambien información de autenticación para ayudar a comprobar que quien realiza el pago está autorizado a utilizar la tarjeta.

El servicio correspondiente de Visa se denomina Visa Secure, mientras que el de Mastercard se conoce como Mastercard Identity Check.

Una autenticación 3DS habitual puede seguir dos modalidades:

• Flujo sin fricción (Frictionless Flow): el emisor evalúa la transacción mediante señales de riesgo, como el importe, la información del dispositivo y los datos del comercio, sin requerir acciones adicionales del titular.

• Flujo de desafío (Challenge Flow): el titular debe realizar una comprobación adicional de identidad, por ejemplo, introducir una contraseña de un solo uso (OTP), aprobar la operación desde la aplicación del emisor o utilizar otro método de autenticación admitido.

Por lo tanto, que no aparezca una ventana para introducir un código no significa que el comercio no haya utilizado 3DS. La autenticación podría haberse completado en segundo plano o no haberse iniciado correctamente. Para conocer lo ocurrido, es necesario revisar el resultado de autenticación devuelto por el proveedor de servicios de pago.

Para conocer los fundamentos técnicos de ambos flujos, puede consultarse el documento técnico de EMVCo sobre EMV 3-D Secure.

La autenticación y la autorización del pago son etapas distintas

3DS se encarga de la autenticación (Authentication), mientras que la autorización del pago (Authorization) determina si la transacción se aprueba.

Aunque el titular introduzca correctamente la OTP o confirme su identidad en una aplicación, el emisor puede rechazar el pago por fondos insuficientes, límites de transacción, el estado de la tarjeta o sus controles de riesgo.

Esta distinción es especialmente importante para las tarjetas de pago con criptoactivos. Algunos productos utilizan un saldo previamente cargado; otros requieren convertir criptoactivos en el momento de la compra o calculan la capacidad de gasto conforme a otros mecanismos de financiación. Que una cuenta muestre tenencias de USDT o USDC no significa que todos esos activos estén disponibles directamente para autorizar la transacción.

Si la autenticación ya se completó correctamente, la investigación debe centrarse en el resultado de la autorización, en lugar de solicitar nuevos códigos una y otra vez.

Identifica primero qué ocurrió durante el pago

El mensaje «Payment Failed» de un comercio suele reflejar únicamente el resultado final del pago, no necesariamente el error subyacente. Incluso si la página indica «3DS Failed», puede ser necesario revisar por separado los registros de autenticación y autorización.

Esta tabla sirve para orientar la investigación, pero no sustituye los registros de transacción. Cuando la página del comercio no proporciona un código de error específico, el usuario normalmente no puede determinar por sí solo si el fallo se produjo durante la autenticación o durante la autorización.

Si no llega la OTP, revisa la cuenta del titular y no solo los datos de registro

Las contraseñas de un solo uso son un método habitual de autenticación mediante desafío 3DS, pero el canal de envío depende del servicio de emisión de la tarjeta.

La empresa que opera la marca de una tarjeta cripto puede ser distinta de la entidad que realmente la emite. El número de teléfono utilizado para registrarse en una plataforma de criptoactivos no necesariamente coincide con el asociado a la cuenta del titular para recibir códigos de autenticación 3DS.

Si no llega la OTP, entra primero en la interfaz oficial de administración de la tarjeta. Comprueba que el teléfono o correo electrónico destinado a verificar transacciones sea correcto y averigua si el producto utiliza SMS, correo electrónico o autenticación mediante aplicación.

Un SMS puede no llegar por problemas con la mensajería internacional, filtros del operador, cambios de número o fallos del servicio de envío. La ausencia del mensaje no permite determinar, por sí sola, qué parte es responsable.

Si la tarjeta utiliza notificaciones push en una aplicación, comprueba que hayas iniciado sesión en la aplicación oficial, que el dispositivo tenga conexión y que no existan operaciones pendientes de aprobación. Algunos procesos de autenticación no envían mensajes SMS.

Si recibes varios códigos, ten presente que podrían corresponder a sesiones de autenticación distintas. Solicitar repetidamente un código nuevo puede invalidar el anterior. Asimismo, al cerrar la página de pago, la sesión original podría haber vencido.

En ese caso, primero verifica si el pedido continúa en proceso y si existen autorizaciones pendientes en la tarjeta. Después, si corresponde, inicia un nuevo pago. No sigas intentando utilizar una página cuya sesión ya expiró.

Si los datos de contacto son correctos, pero nunca llegan las solicitudes de autenticación, el proveedor de la tarjeta o el emisor debe revisar el estado del envío y el servicio de autenticación. Seguir modificando los datos de facturación en el sitio del comercio no resolverá ese problema.

La página de autenticación no abre o no vuelve al comercio después de verificar

La autenticación mediante desafío 3DS no depende únicamente del emisor. También requiere una integración correcta entre la página de pago del comercio y su proveedor de servicios de pago.

En un navegador, la autenticación puede realizarse mediante una ventana integrada o una redirección. Una vez que el titular completa la verificación, el sistema del comercio todavía debe procesar correctamente el resultado para que el pago continúe.

Si aparece una ventana en blanco, la página se carga repetidamente o no es posible regresar al comercio después de autenticarse, conviene comprobar lo siguiente:

• Si la página de pago se abrió desde el navegador integrado de una aplicación de redes sociales o de correo electrónico.

• Si las extensiones del navegador, los bloqueadores de scripts o la configuración de privacidad interfieren con la página de autenticación.

• Si la conexión de red se interrumpió durante la redirección o el proceso de autenticación.

• Si la página de pago original seguía activa después de aprobar la operación en la aplicación.

La prueba más directa consiste en acceder nuevamente al sitio oficial del comercio desde un navegador convencional del dispositivo y volver a intentar el pago después de comprobar el estado de la transacción original.

Si es necesario, pueden descartarse temporalmente las interferencias de las extensiones del navegador. Sin embargo, no se deben ignorar los errores de certificados, las advertencias de seguridad ni las redirecciones sospechosas.

Si una misma tarjeta completa 3DS sin problemas en otros comercios, pero falla repetidamente en un sitio específico, la investigación debería concentrarse en la integración de pagos y el proceso de autenticación de ese comercio.

Por el contrario, si varios comercios sin relación entre sí presentan errores similares, conviene solicitar al proveedor de la tarjeta que investigue el servicio de autenticación del lado del emisor. Cambiar de navegador puede solucionar problemas de compatibilidad de la interfaz, pero no una tarjeta sin el servicio de autenticación habilitado, canales mal configurados o fallos en los sistemas del emisor.

Según la arquitectura de EMV 3DS, el sistema 3DS del comercio debe coordinarse con el servidor de control de acceso (Access Control Server, ACS) del emisor para realizar la autenticación. El ACS también puede estar gestionado por un proveedor contratado por el emisor. Los titulares normalmente no tienen acceso a estas comunicaciones internas, por lo que suele ser necesaria la intervención del comercio, el proveedor de servicios de pago o el emisor.

¿Por qué algunos comercios exigen autenticación y otros no?

No es extraño que una misma tarjeta cripto siga distintos procesos 3DS según el comercio.

La decisión de iniciar 3DS y exigir o no un desafío al titular depende de factores como la configuración de pagos del comercio, la evaluación de riesgo del emisor, las reglas de las redes de tarjetas y los requisitos regulatorios aplicables.

Una transacción puede completarse mediante autenticación sin fricción, mientras que otra requiere introducir una OTP. En determinados pagos en línea, si el comercio no realiza la autenticación exigida, el emisor también puede rechazar la autorización y solicitar una verificación adicional de identidad.

Stripe identifica uno de estos rechazos relacionados con la autenticación mediante el código authentication_required. Según su documentación oficial sobre códigos de rechazo, las integraciones de pago normalmente deben gestionar el requisito de autenticación y, cuando sea necesario, permitir que el titular vuelva a participar en el proceso de pago.

Sin embargo, si la transacción ya se autenticó correctamente y el emisor sigue devolviendo authentication_required, Stripe recomienda contactar al emisor. No debe interpretarse automáticamente como una indicación de que el usuario debe repetir indefinidamente la autenticación.

En mercados como el Espacio Económico Europeo, donde se aplican los requisitos de autenticación reforzada de clientes (Strong Customer Authentication, SCA), los pagos en línea con tarjeta también están sujetos a las disposiciones regulatorias correspondientes. SCA no significa que todas las transacciones deban mostrar una ventana para introducir códigos. Las exenciones aplicables y los mecanismos específicos de autenticación pueden modificar el proceso que ve el usuario.

Lo mismo sucede con las suscripciones. Al establecer una suscripción por primera vez puede ser necesaria la autenticación del titular, mientras que determinadas transacciones posteriores iniciadas por el comercio pueden realizarse sin exigir su participación en cada ocasión.

¿El mensaje «Card not enrolled» significa que la tarjeta no admite 3DS?

No necesariamente.

«Card not enrolled» puede estar relacionado con un registro 3DS incompleto de la cuenta del titular, la configuración de autenticación de un programa de tarjetas o la imposibilidad de que el servicio correspondiente reconozca la tarjeta. La causa concreta debe confirmarse a partir de los registros del error.

Que la tarjeta esté activada, que el usuario haya completado KYC o que aparezca el logotipo de Visa o Mastercard no demuestra, por sí solo, que admita la autenticación 3DS exigida por el comercio.

Las tarjetas de pago con criptoactivos pueden operar con distintos emisores y servicios de autenticación. Incluso dentro de una misma marca puede haber diferencias de configuración según la región de emisión, el programa de tarjetas o la versión del producto.

Si el comercio devuelve expresamente «3D Secure not supported» o «Card not enrolled», se puede consultar al proveedor de la tarjeta:

• Si la tarjeta tiene habilitado el servicio de autenticación 3DS correspondiente y está registrada en él.

• Qué métodos de autenticación admite el programa y si existen restricciones regionales o del producto.

• Qué procedimiento debe seguirse si es necesario completar el registro, actualizar los datos de verificación o reactivar el servicio.

También hay que distinguir entre la compatibilidad con 3DS y las políticas del comercio sobre tarjetas aceptadas. Algunos comercios restringen las tarjetas prepagadas, virtuales o emitidas en determinados países o regiones. Que una tarjeta tenga 3DS plenamente funcional no garantiza que el comercio la acepte.

Si la autenticación fue correcta, ¿por qué se rechazó el pago?

Si los registros del comercio o del emisor confirman que la autenticación 3DS se completó correctamente, pero el pago fue rechazado después, la investigación debe centrarse en la autorización.

En las tarjetas cripto de saldo precargado, conviene revisar el saldo disponible, los límites de transacción y el estado de la cuenta. En productos que requieren conversión de criptoactivos en tiempo real u otros mecanismos de financiación, también se debe confirmar la capacidad efectiva de gasto y las condiciones de uso de los fondos.

Algunos comercios pueden solicitar una preautorización o enviar un importe de autorización distinto del precio mostrado. Sin embargo, esas situaciones corresponden a la autorización del pago, no a un fallo de autenticación 3DS propiamente dicho.

Si aparecen importes pendientes en la cuenta de la tarjeta mientras el comercio indica que el pago falló, primero deben comprobarse el pedido y el estado de las autorizaciones. Volver a pagar repetidamente podría generar autorizaciones duplicadas o retenciones temporales de varios importes.

Para investigar problemas de saldo, restricciones de comercios y rechazos de autorización habituales, consulta la guía de UCard Radar sobre transacciones rechazadas con tarjetas cripto.

Si la autenticación falla repetidamente, evita seguir intentando

Después de varios fallos en un mismo pago, continuar introduciendo códigos o reenviando la transacción normalmente no solucionará problemas de configuración de autenticación o conectividad entre sistemas. Además, podría activar límites a los intentos de autenticación.

En su documentación de solución de problemas de 3D Secure para emisión de tarjetas, Adyen indica que, para las tarjetas emitidas a través de su servicio, cinco intentos consecutivos de autenticación fallidos provocan un bloqueo temporal de nuevas autenticaciones 3DS. Normalmente, la restricción se levanta automáticamente después de una hora; también es posible contactar a su equipo de soporte.

Adyen relaciona este control con los requisitos regulatorios de PSD2. No obstante, el límite de cinco fallos y el desbloqueo tras una hora son reglas concretas de implementación descritas por ese proveedor. No pueden extrapolarse directamente a otros emisores.

Si aparece el mismo error dos veces consecutivas, especialmente cuando se rechaza una OTP, el servicio de autenticación no está disponible o la cuenta muestra una restricción temporal, conviene detener los intentos y revisar el mensaje de error y el estado de la tarjeta.

Cambiar frecuentemente de dirección IP, falsear la región de la cuenta o proporcionar datos de facturación incorrectos tampoco soluciona los problemas de configuración de autenticación. Por el contrario, podría provocar revisiones de seguridad adicionales.

¿Contactar al comercio o al emisor? Depende de quién tenga los registros del fallo

Investigar problemas con tarjetas de pago vinculadas a criptoactivos puede ser más complejo de lo que sugiere la interfaz que ve el usuario.

Una plataforma de criptoactivos puede encargarse de la marca y la atención al cliente, una entidad emisora autorizada asumir la responsabilidad de emisión, un procesador independiente gestionar las autorizaciones y un proveedor especializado de ACS realizar la autenticación 3DS.

Por eso, la aplicación de la marca no necesariamente muestra un historial completo de las autenticaciones.

Adyen Issuing ofrece un ejemplo concreto. Su documentación oficial de solución de problemas explica que, cuando la autenticación 3DS falla e impide que la transacción avance más allá de esa etapa, la solicitud de autorización no se envía a Adyen. En consecuencia, no se genera ninguna solicitud de autorización reenviada ni el webhook correspondiente, y la transacción tampoco aparece en la lista Payments de Adyen Customer Area. Se trata de un caso de procesamiento específico de Adyen Issuing y no permite concluir que todas las tarjetas cripto u otros emisores utilicen el mismo mecanismo de registro.

Por lo tanto, que no aparezca una operación en el historial de la tarjeta no significa que el comercio no haya intentado iniciar la autenticación 3DS.

La prioridad de contacto puede determinarse según el problema observado:

Antes de contactar a soporte, conviene reunir la fecha y hora de la transacción con su zona horaria, el nombre del comercio, el importe y la moneda, los últimos cuatro dígitos de la tarjeta, el mensaje de error exacto, el punto alcanzado en la autenticación y el estado del pedido y las autorizaciones pendientes.

Al consultar al comercio, puedes preguntar directamente:

¿Podrían confirmar si se inició la autenticación 3D Secure para esta transacción, cuál fue su estado final y si el pago llegó a la etapa de autorización? Si la autenticación falló, ¿podrían proporcionar el código de error correspondiente o el motivo del fallo?

Esta información suele ayudar mucho más a localizar el problema que preguntar de manera general por qué no se pudo pagar.

¿Cómo interpretar los códigos transStatus de 3DS?

Si el equipo técnico del comercio puede facilitar registros de autenticación más detallados, es posible que incluyan el campo transStatus de EMV 3DS.

Este campo refleja el estado de autenticación o verificación de la cuenta, aunque su interpretación y presentación pueden variar según la etapa del intercambio de mensajes, la versión del protocolo y el proveedor de servicios.

Los estados C y D no deben considerarse automáticamente fallos definitivos de autenticación. Del mismo modo, A e I no equivalen a Y. Para determinar si la autenticación terminó correctamente, es necesario considerar la etapa del mensaje, los resultados relacionados y la forma en que el proveedor de servicios de pago los procesa.

Según la especificación del protocolo 3DS de EMVCo, I significa Informational Only e indica que se ha reconocido la preferencia de desafío expresada por el solicitante de 3DS. No significa que el titular haya completado la autenticación.

Por su parte, la referencia de la API de 3D Secure 2 de Adyen describe I como «Authentication / exemption granted by Issuer», es decir, que el emisor ha concedido la autenticación o una exención. Esta es la descripción específica de la documentación de la interfaz de Adyen y no debe confundirse directamente con la definición del protocolo EMV 3DS. Tampoco puede equipararse una exención de autenticación con la autenticación correcta que representa Y. El mismo documento incluye códigos transStatusReason, que los equipos técnicos de los comercios pueden utilizar para investigar el resultado.

Los titulares normalmente no pueden acceder directamente a estos campos, pero pueden pedir al comercio que confirme el resultado final de autenticación. Si esta fue correcta, habrá que verificar después si se envió una solicitud de autorización y si el emisor la rechazó.

Al compartir capturas de pantalla o información de transacciones, proporciona únicamente los datos necesarios, debidamente ocultados o parcialmente censurados. Nunca compartas el número completo de la tarjeta, el CVV, la contraseña de la cuenta, las OTP ni la frase de recuperación de tu billetera.

Si utilizas con frecuencia tarjetas de pago con criptoactivos para suscripciones, comercio electrónico internacional o servicios en línea, antes de solicitar una tarjeta nueva conviene comprobar si ofrece 3DS, qué canales de autenticación utiliza y quién se encarga de brindar asistencia cuando la verificación falla. Estos detalles permiten evaluar mejor la capacidad de soporte de una tarjeta en su uso cotidiano que una simple afirmación de que «admite pagos en línea en todo el mundo».