3-D Secure status guide
1. Introducción
Con la introducción de la directiva PSD2, es más importante que nunca hacer un seguimiento de tus transacciones 3-D Secure.
Tanto si utilizas Página de pago alojada como DirectLink, te lo ponemos muy fácil. Utiliza esta guía para saber dónde buscar y cómo interpretar la información disponible.
¡Conviértete en un experto en 3-D Secure en poco tiempo!
2. Comprender los estados de 3-D Secure
Además de las exclusiones y exenciones claramente definidas, todos tus clientes tendrán que pasar la autenticación 3-D Secure. La transacción alcanza tanto un estado 3-D Secure (que es el resultado de la comprobación de la autenticación) como un
estado global de la transacción (que indica el resultado de la solicitud de autorización).
Por lo tanto, ambos son el resultado de dos pasos diferentes:
- Estado de 3-D Secure: en primer lugar, el cliente tiene que demostrar que es el propietario legítimo de la tarjeta de crédito utilizada para la transacción. Esta comprobación de autenticación tiene lugar en el portal en línea del banco emisor de la tarjeta de tu cliente. Puedes consultar una descripción general de los posibles resultados en nuestro documento de referencia de parámetros
- Estado global de la transacción: en segundo lugar, tu entidad adquirente consulta al banco emisor de la tarjeta de tu cliente para comprobar si hay suficientes fondos disponibles para la transacción, lo que puede dar lugar a una autorización correcta o incorrecta. Puedes consultar una descripción general de los posibles resultados en nuestra guía de estados de transacciones
Puedes buscar los resultados manualmente en el Back Office y con nuestra herramienta Informes:
- Back Office: busca la transacción en Operaciones > Ver transacciones. En la descripción general, busca “Estado” (que es el estado global de la transacción) y la imagen combinada con una descripción (que es el estado de 3-D Secure)
La imagen muestra dónde consultar el estado de 3-D Secure y el estado global de la transacción en el Back Office - Informes: es muy importante que configures tu perfil de Electronic reporting tal y como se describe en nuestro vídeo dedicado a este asunto. Los parámetros ECI/STATUS indican el estado de 3-D Secure/estado global de la transacción, respectivamente
Si procesas transacciones a través de Página de pago alojada, nuestra plataforma despliega la versión 1 automáticamente por ti. .
Si procesas transacciones a través de DirectLink, tienes que desplegar la versión 1 por tu cuenta Descubre cómo hacerlo en el capítulo dedicado DirectLink. how to do it.
La siguiente tabla ofrece una visión completa de los posibles escenarios y de cómo nuestra plataforma te los muestra de una u otra manera:
| Estado de 3-D Secure (Back Office) | Estado de 3-D Secure (parámetro ECI en Informes | Estado de la transacción | Descripción |
|---|---|---|---|
| Todo el pulgar hacia arriba/ "Cardholder has been successfully identified! V1" |
5 | En función del resultado de la autorización por parte de tu entidad adquirente 2 5 9 |
Tu cliente ha pasado la comprobación de autenticación. En caso de devoluciones de cargos fraudulentas, el banco emisor de la tarjeta es el responsable |
| Medio pulgar hacia arriba/ “Cardholder not identified: liability shift rules to be applied (depending on transaction date and credit card country)” |
6 12 |
En función del resultado de la autorización por parte de tu entidad adquirente 2 5 9 |
Tu cliente no ha tenido la oportunidad de perfeccionar la comprobación de autenticidad. En caso de devoluciones de cargos fraudulentas, el banco emisor de la tarjeta es el responsable |
| Signo de exclamación/ "Cardholder authentication failed!" |
91 | 2 | Tu cliente no ha pasado la comprobación de autenticación debido, por ejemplo, a contraseña/PIN incorrectos. Nuestra plataforma no ejecuta el paso de autorización y se abandona la transacción |
| Ninguna imagen/ "Cardholder authentication not technically possible!!!" |
92 | En función del resultado de la autorización por parte de tu entidad adquirente y de tu preferencia 2 5 9 |
La autenticación no ha sido posible debido a un error técnico. De forma predeterminada, nuestra plataforma no ejecuta el paso de autorización y se abandona la transacción (estado 2). Sin embargo, nuestra plataforma te permite optar por la autorización, tal y como se describe en el capítulo dedicado. |
| Todo el pulgar hacia arriba/ "Cardholder has been successfully identified! V2 challenge" |
5 | En función del resultado de la autorización por parte de tu entidad adquirente 2 5 9 |
Tu cliente ha pasado la comprobación de autenticación y se ha identificado de forma activa según el protocolo SCA ("flujo con verificación"). En caso de devoluciones de cargos fraudulentas, el banco emisor de la tarjeta es el responsable |
| Todo el pulgar hacia arriba/ "Cardholder has been successfully identified! V2 frictionless"” |
5 | En función del resultado de la autorización por parte de tu entidad adquirente 2 5 9 |
Tu cliente ha pasado la autenticación. Como has proporcionado suficiente información junto con la transacción según el protocolo SCA, tu cliente no ha tenido que identificarse de forma activa ("flujo sin interacción") |
Ten en cuenta que son solo indicaciones, y que la responsabilidad definitiva depende de varios factores
3. Comprender el registro de autenticación
Además de conocer el estado de 3-D Secure de tus transacciones, nuestra plataforma almacena los archivos de registro de cada comprobación de autenticación. Estos archivos contienen información detallada sobre el flujo exacto que lleva al resultado de la comprobación de la autenticación.
Busca esta información para cualquier transacción en el Back Office en Operaciones > Ver transacciones. Si haces clic en "AUTHENTICATION LOG" en la descripción general, accederás a una tabla con descripciones. Cada línea representa un paso individual de un control de autenticación completo.
| Columna | Descripción |
|---|---|
| MsgType |
Paso ejecutado de la comprobación de autenticación actual.
Si nuestra plataforma tuviera que desplegar la versión 1 de 3-D Secure, los siguientes valores son posibles:
|
| Status |
Estado/resultado del paso ejecutado.
Si nuestra plataforma tuviera que desplegar la versión 1 de 3-D Secure, los siguientes valores son posibles:
|
| Date |
Marca de tiempo del paso ejecutado |
| Details |
Información/parámetros del paso ejecutado.
|
| Card N° |
La tarjeta utilizada durante cada paso respectivo |
La imagen muestra dónde buscar los registros de autenticación en el Back Office
La imagen muestra una tabla típica con registros de autenticación en el Back Office
Comprender y manejar el cambio a 3-D Secure v1
Es posible que nuestra plataforma procese las transacciones en modo 3-D Secure v1 (comprueba la columna “MsgType” en el registro de autenticación en consecuencia). Presta atención a esto ya que la v1 se retirará por completo en octubre de 2022. Para ayudarte a afrontar este tipo de operaciones echa un vistazo a la tabla con las posibles causas y soluciones:
| Mensaje de error (columna “MsgType”) | Descripción | Solución |
|---|---|---|
| V2ParamMissing | Faltan parámetros v2 obligatorios | Asegúrate de actualizar DirectLink integración. Si procesas las transacciones a través de nuestra Página de pago alojada nosotros nos encargamos de estas por ti |
| acquirerBIN/acquirerMerchantID not recognized | Tienes que estar inscrito a la v2 en MasterCard | Ponte en contacto con tu entidad adquirente o con nosotros para solicitarlo |
| "Detail":"billAddrCountry; V2Error caused fallback to v1 "Detail":"billAddrLine1,billAddrLine2 "Detail":"cardholderName; "Detail":"email; "Detail":"acctNumber; "Detail":"browserLanguage" "Detail":"acctInfo.nbPurchaseAccount,acctInfo.txnActivityDay,acctInfo.txnActivityYear" "Detail":"Name(s) of erroneous fields separated by (,) : acctInfo.suspiciousAccActivity,threeDSRequestorAuthenticationInfo.threeDSReqAuthMethod, acctInfo.shipAddressUsageInd,acctInfo.chAccAgeInd,acctInfo.shipNameIndicator,acctInfo.paymentAccAge,acctInfo.paymentAccInd,acctInfo.shipAddressUsage" |
Error recibido desde el directory server (DS). Código ISO no válido según las tablas ISO (para el país o la moneda) |
Parámetros no válidos enviados para parámetros v2 obligatorios Asegúrate de actualizar DirectLink integración. |
| Error received from the DS. Format of one or more elements is invalid according to the specification","Detail":"threeDSRequestorURL" | Los datos de tu sitio web en Back Office no son correctos (Configuración > Cuenta > Sus detalles administrativos > URL) |
Corrige tu URL en Back Office |
| Specific reason fallbacks to V1 because transaction status will be blocked by issuer MC Fallback to V1 since Transaction status reason is 82 Cb Fallback to V1 since Transaction status reason is 13 |
Errores no especificados |
Estos errores se producen en un tercero, la solución no está en tus manos |
4. Continuar/interrumpir el flujo de la transacción
De acuerdo con la directiva PSD2, de forma predeterminada las transacciones para las que no se ha podido realizar una comprobación de autenticidad debido a problemas técnicos, alcanzan el estado 2. Nuestra plataforma interrumpe la transacción omitiendo cualquier tipo de autorización.
Sin embargo, puedes anular este comportamiento predeterminado indicando a nuestra plataforma que continúe con el paso de autorización de todos modos. Para usar esta opción, sigue estos pasos:
- Inicia sesión en el Avanzado > Detección del fraude > 3D-Secure
- Selecciona el método de pago para el que deseas anular el comportamiento predeterminado haciendo clic en "EDITAR”
- Selecciona el botón de opción “Continue” para “Continuar/Interrumpir la transacción si un problema técnico impide la conexión al directorio MasterCard durante la comprobación del registro en 3D-Secure.” y “Continuar/Interrumpir la transacción si el servicio de identificación del titular de la tarjeta no está disponible temporalmente”. Confirma haciendo clic en “ENVIAR"
La imagen muestra dónde configurar la función de continuar / interrumpir en el Back Office
- Si utilizas esta opción, tal vez se te considere responsable de las devoluciones de cargos fraudulentas
- Existe una alta probabilidad de que tu transacción siga alcanzando el estado 2, ya que según la directiva PSD2 todo comprador en línea debe pasar un control de autenticación
5. Finalización parcial del cambio de responsabilidad
Todos los principales sistemas que se enumeran a continuación coinciden en su voluntad de asegurarse de que el abandono oficial de 3DS v1 se produzca en octubre de 2022:
- VISA
- Mastercard
- American Express
- JCB
- Diners Discover
VISA y Mastercard ya han anunciado un periodo de transición al EMV 3DS.
Básicamente, VISA y Mastercard solo admitirán las transacciones que se hayan autenticado completamente, lo que supondrá una reducción de la protección frente a la responsabilidad en caso de fraude para los comercios que utilicen 3DS v1
Esto aparecerá en el Back Office como "Cardholder not identified: liability shift rules to be applied (depending on transaction date and credit card country)" y ECI=12 en la información de post-sale.
Con el mismo mensaje “Cardholder not identified: liability shift rules to be applied (depending on transaction date and credit card country)” y ECI=6, el cambio de responsabilidad aún sigue siendo aplicable.
Visa
| Visa Secure 3DS V1 | Antes del 16 de octubre de 2021 | Después del 16 de octubre de 2021 |
|---|---|---|
| Autenticación completa (el banco emisor de la tarjeta participa) | La responsabilidad sobre fraudes se traslada al banco emisor de la tarjeta (ECI=5) | Sin cambios |
| Intento de autenticación (sin la participación del banco emisor de la tarjeta) | La responsabilidad sobre fraudes se traslada al banco emisor de la tarjeta (ECI=12) | La responsabilidad sobre fraudes la tiene el comercio (ECI=12) Resultado de la inscripción = N |
Mastercard
| Mastercard Identity Check 3DS V1 | Antes del 5 de octubre de 2021 | Después del 5 de octubre de 2021 |
|---|---|---|
| Autenticación completa (el banco emisor de la tarjeta participa) | La responsabilidad sobre fraudes se traslada al banco emisor de la tarjeta (ECI=5) | Sin cambios |
| Intento de autenticación (sin la participación del banco emisor de la tarjeta) | La responsabilidad sobre fraudes se traslada al banco emisor de la tarjeta (ECI=12) | La responsabilidad sobre fraudes la tiene el comercio (ECI=12) Resultado de la inscripción = N |