Autenticación 3D Secure
3-Domain Secure™ (3-D Secure o 3DS) es un protocolo de seguridad que agrega una capa adicional de seguridad a las compras en línea al exigir a los titulares de tarjetas que se autentiquen con el emisor de la tarjeta al realizar pagos. Ayuda a prevenir transacciones en línea no autorizadas, reduce el riesgo de fraude y puede proteger al negocio de los contracargos si la transacción se autentica correctamente. Cuando un titular de tarjeta realiza una compra en línea, el emisor utiliza su Servidor de control de acceso (ACS) para validar la identidad del titular.
3DS, también conocido como 3DS2 en Mastercard Gateway, es la última versión del protocolo de seguridad, diseñado para mejorar la seguridad en las compras en línea y al mismo tiempo proporcionar procesos de pago fluido a los pagadores que la ACS considera de bajo riesgo. La ACS determina el riesgo utilizando la información proporcionada por el negocio, las huellas digitales del explorador y las interacciones previas con el pagador. El servidor ACS plantea un desafío al pagador (por ejemplo, el ingreso de un PIN) solo cuando se requiere una verificación adicional para autenticar al pagador, lo que proporciona un aumento de las tasas de conversión. Los esquemas de autenticación admitidos incluyen Mastercard SecureCode™, Verified by Visa™, American Express SafeKey™, Diners Club/Discover ProtectBuy, JCB J/Secure, ITMX Local Switch EMVCo y mada Secure.
Terminología
La siguiente tabla enumera los términos clave a los que se hace referencia en la documentación de integración de 3DS.
| Término | Descripción |
|---|---|
| API de JavaScript de 3DS | API de JavaScript del lado del cliente que le permite iniciar la autenticación 3DS desde el explorador del pagador utilizando la autenticación basada en sesión.
Esta API se utiliza con el método de integración de Hosted Session. |
| Servidor de control de acceso (ACS) | Componente que opera en el dominio del emisor, que verifica si la autenticación está disponible para un número de tarjeta y el tipo de dispositivo y autentica transacciones específicas. |
| Llamada de método ACS | Una llamada que permite a la ACS recopilar datos adicionales para determinar la puntuación de riesgo del pagador. Cuando 3DS2 está disponible y cuando los detalles de la llamada de ACS se devuelven en la respuesta después de iniciar la autenticación, estos detalles se pasan al explorador del pagador, y se envían como un formulario publicado en un iframe oculto, para que el ACS pueda recopilar datos adicionales. |
| Canal de autenticación | Ubicación donde se realiza la autenticación 3DS: en el explorador del pagador, en una aplicación en el dispositivo móvil del pagador o en su sistema sin ningún pagador presente para interactuar. |
| Propósito de la autenticación | Finalidad de la acción de autenticación 3DS. Por lo general, usted desea autenticar al pagador para procesar un pago para una tarjeta específica o procesar una autenticación sin pago, en la que simplemente verifica una nueva tarjeta que el pagador desea almacenar en su aplicación o sitio web para pagos futuros. |
| Flujo de desafío | Flujo de autenticación en el que se redirige al pagador al ACS y se le pide que responda a un desafío para identificarse, porque el ACS no tiene suficiente información del pagador para considerarlo de bajo riesgo. |
| Flujo fluido | Flujo de autenticación en el que no se requiere que el pagador responda a un desafío porque el ACS considera que el pagador es de bajo riesgo. |
| Autenticación de negocio | Mecanismo que permite al negocio autenticar las solicitudes de API al motor de pagos, por ejemplo, contraseña/certificado/autenticación de sesión. |
| API de autenticación del pagador | API del lado del servidor que consta de dos operaciones, Initiate Authentication y Authenticate Payer, que deben enviarse desde su servidor al servidor del motor de pagos. También se puede usar como API del lado del cliente mediante la autenticación basada en sesión. Esta API se utiliza con el método de integración de Direct Payment. |
| Sesión de pago | Una sesión de pago, o simplemente sesión, es un contenedor temporal para cualquier campo de solicitud y valor de operaciones que hagan referencia a una sesión. Puede utilizarlo en una operación para hacer referencia a los campos de solicitud y valores, en lugar de proporcionarlos directamente en la solicitud de operación. Cuando el motor de pagos recibe una operación que hace referencia a una sesión, la solicitud final se forma al combinar los campos de solicitud de la sesión y aquellos proporcionados directamente en la solicitud. Para obtener más información, consulte Conceptos básicos de las sesiones. |
| Autenticación con sesión | Autenticación mediante una sesión de pago. Este método de autenticación permite a los pagadores proporcionar sus detalles de pago directamente al motor de pagos a través de una interacción del cliente con el motor de pagos, ya sea a través del explorador de un pagador o de una aplicación en el dispositivo móvil del pagador. Utiliza un mecanismo básico de autenticación HTTP (similar a la autenticación con contraseña), en el que debe proporcionar 'merchant.<your gateway merchant ID>' en la parte de ID de usuario y el ID de sesión en la parte de contraseña. Para usar este tipo de autenticación, primero debe crear una sesión enviando una solicitud de sesión (consulte Create Session) desde su servidor al servidor de motor de pagos. |
Flujo de autenticación 3DS
El siguiente diagrama ilustra el flujo de autenticación para un pago en el que el pagador se autentica mediante 3DS.
El flujo de autenticación para una autenticación con éxito es el siguiente:
- Un pagador navega por su sitio web, selecciona uno o más productos, accede a la página de pago y selecciona pagar con una tarjeta compatible con 3DS.
- Envíe la solicitud de INITIATE AUTHENTICATION para pedirle al motor de pagos que verifique con el esquema de la tarjeta si la tarjeta está registrada para 3DS.
- Si la autenticación 3DS del pagador está disponible, el motor de pagos devuelve los detalles de autenticación de la llamada al método ACS admitido en la respuesta.
- Envíe los detalles de la llamada al método ACS como una publicación de formulario en un iframe oculto, para que ACS pueda iniciar la autenticación y recopilar datos adicionales sobre el pagador.
- Envíe la solicitud de AUTHENTICATE PAYER para pedirle al motor de pagos que realice la autenticación iniciada.
- El motor de pagos le proporciona los detalles de autenticación según el flujo de autenticación:
- Flujo sin fricciones donde se completa la autenticación: El motor de pagos redirige al pagador a su sitio web.
- Flujo de desafío donde se requiere la interacción del pagador para completar la autenticación: si el emisor requiere que el pagador responda a un desafío, su aplicación redirige el explorador web del pagador al ACS, que presenta su IU de autenticación. El emisor devuelve el resultado de la autenticación al motor de pagos. El motor de pagos redirige al pagador directamente a su sitio web.
- Envíe el pago para su procesamiento mediante la solicitud AUTHORIZE o PAY e incluya el ID de transacción de autenticación 3DS en la solicitud.
- Mostrar la página de confirmación del pedido al pagador.
authentication.redirect.html que debe incluirse en el explorador del pagador a través de un iframe oculto. Esto ayuda a minimizar el tiempo de espera de los pagadores cuando reciben un error "SERVER_BUSY". Adición de 3DS a su integración
Prerrequisitos
- Para utilizar el servicio de autenticación 3DS del motor de pagos:
- Debe estar registrado con su adquirente para usar 3DS.
- Su perfil de negocio en el motor de pagos debe estar habilitado para al menos un esquema 3DS para una versión de 3DS compatible.
- Debe utilizar API v57 o posterior.
Modos de autenticación 3DS
- El motor de pagos admite los siguientes modos de autenticación 3DS:
- Solo autenticación: la autenticación 3DS se realiza mediante el motor de pagos. Puede optar por enviar el pago (utilizando los detalles de autenticación) en una etapa posterior a través de este motor de pagos u otro motor de pagos.
- Autenticación y transacción de pago: la autenticación 3DS se realiza usando este motor de pagos y se procede a enviar el pago (usando los detalles de autenticación) a través de este motor de pagos.
- Transacción de pago previamente autenticada: la autenticación 3DS se realiza con un proveedor externo y se proporcionan los detalles de autenticación al enviar un pago a través de este motor de pagos.
Opciones de integración 3DS
El motor de pagos admite las siguientes opciones de integración para 3DS.
| Método de integración | Integración de 3DS | Cuándo usar | Modo de autenticación admitido |
|---|---|---|---|
| Hosted Checkout | 3DS con Hosted Checkout | Esta es la opción de integración más sencilla. Si admite 3DS, la Hosted Payment Page maneja automáticamente la autenticación 3DS en su integración de Hosted Checkout. |
|
| Hosted Session | API de JavaScript de 3DS | Esta es una integración de JavaScript con la que puede iniciar la autenticación 3DS desde la página de pago de su sitio web. Use esta opción si desea permitir que el pagador envíe sus detalles de pago directamente al motor de pagos desde el explorador. Para iniciar la autenticación 3DS y otras operaciones de 3DS directamente desde el explorador del pagador, primero debe establecer el canal de autenticación donde su servidor de negocio debe comunicarse con el servidor del motor de pagos para crear una sesión en el motor de pagos. El ID de sesión generado por el motor de pagos se incluye en todas las solicitudes de autenticación iniciadas por el explorador como campo de contraseña (consulte Opciones de autenticación). |
|
| Direct Payment | API de autenticación del pagador | Esta es una opción de integración del lado del servidor que le brinda control total sobre su integración, pero requiere el mayor esfuerzo de integración. Use esta opción si debe personalizar las interacciones de API entre el explorador del pagador y el motor de pagos. Debe realizar las operaciones necesarias para administrar los flujos de integración de 3DS directamente desde su servidor de negocio al servidor del motor de pagos. La API de autenticación del pagador también admite sesiones de pago (consulte Conceptos básicos de las sesiones). |
|
| Integración móvil | Integrado en el SDK | Si admite 3DS, puede iniciar la autenticación con una llamada de función y el resto del proceso lo maneja automáticamente el SDK. |
|
Preguntas frecuentes
¿Cómo veo los detalles de autenticación en la Merchant Administration?
Puede ver los detalles de autenticación para las autenticaciones individuales y las autenticaciones que continuaron con el pago en Merchant Administration. Busque el pedido o la transacción en la página de búsqueda y vea los detalles de autenticación.
¿Cómo recupero los resultados de la autenticación 3DS?
Si desea recuperar los resultados de autenticación en cualquier etapa, utilice la operación RETRIEVE TRANSACTION. Los campos que solo se utilizan durante la autenticación, por ejemplo, authentication.redirect.html, no persisten en el motor de pagos y, por lo tanto, no se devuelven.
¿Cómo envío una solicitud de pago previamente autenticada?
Si ha utilizado un MPI (complemento del negocio) de 3DS externo para autenticar al pagador, debe proporcionar la información sobre el resultado de la autenticación en el objeto de autenticación de la operación AUTHORIZE o PAY.
Como el estado de la transacción determina si el MPI de 3DS externo le proporcionó campos específicos, todos los campos son opcionales. Sin embargo, si tiene los datos, proporciónelos:
authentication.3ds.acsEciindicador de comercio electrónico devuelto en el mensaje de respuesta de autenticación.
-
authentication.3ds.authenticationTokenValor codificado base64 generado por el emisor de la tarjeta devuelto en el mensaje de respuesta de autenticación.
El resultado de la llamada al método ACS iniciada a través de la publicación del formulario no se proporciona automáticamente y su aplicación debe enviar la solicitud de AUTHENTICATE PAYER para obtener una respuesta. -
authentication.3ds.transactionIdIdentificador de transacción único generado por el motor de pagos para la autenticación 3DS. El campo corresponde al identificador asignado por el servidor del directorio del esquema.
-
authentication.3ds2.protocolVersionVersión del protocolo 3DS utilizado para realizar la autenticación 3DS, en el formato especificado por EMVCo. Por ejemplo, 2.1.0.
-
authentication.3ds2.transactionStatusResultado de la autenticación del pagador con el emisor.
-
authentication.3ds2.statusReasonCodeCódigo que indica el motivo del estado de la transacción devuelto en
authentication.3ds2.transactionStatus. Debe proporcionar esto cuandoauthentication.3ds2.transactionStatusdevuelveN,UoR. -
authentication.amountMonto de la autenticación. Debe proporcionar valores en este campo cuando el monto de autenticación difiera de
order.amount. Consulte con Your payment service provider (PSP) antes de utilizar este campo. -
authentication.timeFecha y hora de la autenticación del pagador. Consulte con su PSP antes de utilizar este campo.
Si usted es un negocio de comercio electrónico con un vínculo de adquirente de mada en el Reino de Arabia Saudita y un pagador completamente autenticado por 3DS fuera del motor de pagos, debe estar integrado a API v76 o posterior y proporcionar los siguientes detalles de autenticación en la operación AUTHORIZE o PAY para enviar correctamente una transacción con tarjeta de mada de marca compartida, tarjeta de mada de insignia única o internacional:
-
authentication.3ds2.acsReferenceNúmero de referencia que EMVCo asigna al ACS del emisor tras la aprobación del ACS. Este campo corresponde al campo
acsReferenceNumberde EMVCo. -
authentication.3ds2.dsReferenceNúmero de referencia que EMVCo asigna al servidor de directorio (DS) tras la aprobación del DS. Este campo corresponde al campo EMVCo dsReferenceNumber.
-
authentication.3ds2.acsTransactionIdIdentificador de transacción único que el ACS asigna para identificar la transacción 3DS.
-
authentication.timeFecha y hora de la autenticación del pagador. Este campo corresponde al campo
purchaseDatede EMVCo. -
authentication.3ds.acsEciValor del indicador de comercio electrónico (ECI) que proporciona el ACS del emisor para indicar los resultados del intento de autenticar al pagador.
-
authentication.3ds.authenticationTokenValor codificado en Base64 que genera el emisor. Este campo corresponde al Valor de autenticación.
-
authentication.3ds.transactionIdID de transacción. Este campo corresponde al ID de la transacción DS.
-
authentication.3ds2.protocolVersionVersión del protocolo 3DS que se utiliza para realizar la autenticación 3DS. Por ejemplo, 2.1.0.
-
authentication.3ds2.transactionStatusEstado de la transacción. Este campo corresponde al campo
transStatusde EMVCo. -
authentication.3ds2.authenticationSchemeEsquema de autenticación. Para transacciones de marca compartida de mada autenticadas externamente, debe proporcionar
MADA,MASTERCARDoVISApara especificar el DS de 3DS a través del cual se autenticó la transacción. Para transacciones mada de marca única autenticadas de manera externa, puede proporcionarMADAo no enviar este campo. Para otras tarjetas, puede proporcionar el esquema de autenticación respectivo o no enviar este campo.
¿Cómo puedo enviar una solicitud de autenticación sin pago?
Si desea realizar la autenticación para verificar únicamente la identidad del pagador sin proceder al pago, debe indicar el propósito de la autenticación en la solicitud INITIATE AUTHENTICATION. Por ejemplo, si desea autenticar al pagador cuando ingresa los datos de su tarjeta para su uso posterior durante el registro del cliente o la creación de una cuenta en su sitio web. La capacidad de completar el proceso de autenticación en un entorno que no sea de pago mejora la experiencia del pagador y reduce los índices de abandono del pagador.
- Para realizar una autenticación sin pago, proporcione los siguientes campos en la solicitud INITIATE AUTHENTICATION:
order.currencycualquier moneda admitida en los vínculos de adquirente.authentication.purpose- Contexto en el que se solicita la autenticación del pagador. Puede especificar una de las siguientes opciones:
- ADD_CARD: la autenticación se realiza antes de que usted almacene directamente la tarjeta de un pagador en el archivo o de que la tarjeta se almacene mediante la característica de Tokenization del motor de pagos. No se está procesando un pago.
- MAINTAIN_CARD: la autenticación se realiza antes de que usted directamente actualice los detalles de la tarjeta de un pagador en el archivo o de que la tarjeta se almacene mediante la característica de Tokenization del motor de pagos. No se está procesando un pago.
Si el esquema de autenticación no admite el propósito que ha solicitado, el motor de pagos devuelve AUTHENTICATION_NOT_SUPPORTED en el campo de respuesta authenticationStatus. De forma predeterminada, el motor de pagos establece este campo en PAYMENT_TRANSACTION para permitir que se utilice la autenticación para una transacción de pago.
¿Cómo utilizar 3DS como negocio agregador?
Los negocios agregadores pueden habilitar sus subnegocios para que utilicen la API de autenticación en el motor de pagos. Los subnegocios no están obligados a tener una relación contractual con el adquirente ni con el motor de pagos. El negocio agregador puede enviar los detalles del subnegocio necesarios para iniciar la autenticación a través de la operación INITIATE AUTHENTICATION. Para obtener más información, consulte Agregador.
¿Cómo se representan las interacciones 3DS en el motor de pagos?
La API de autenticación del pagador registra los detalles de la autenticación del pagador utilizando 3DS como transacción AUTHENTICATION en el pedido. Para obtener detalles sobre las transacciones AUTHENTICATION, consulte la lista de campos de respuesta para la operación AUTHENTICATE PAYER.
Cuando se recupera un pedido mediante la operación RETRIEVE ORDER o recibe una respuesta de API de Reporting, puede contener una transacción AUTHENTICATION adicional. Además, cuando se utilizan notificaciones de Webhook, puede recibir una notificación adicional para la transacción AUTHENTICATION.
¿Puedo usar tokens de red como fuente de fondos en la autenticación del pagador?
Puede utilizar tokens de red para la autenticación del pagador desde API v57 en adelante. Para obtener información detallada, consulte Tokenización de red.
Si su PSP lo ha habilitado para la Tokenization de red, cualquier solicitud al motor de pagos para un token de motor de pagos también intenta generar un token de red correspondiente para los esquemas habilitados, cuando lo admita el emisor de la tarjeta. El motor de pagos también intenta realizar la Tokenization de red para cualquier tarjeta aplicable que ya esté almacenada en el depósito de tokens del motor de pagos. La solicitud INITIATE AUTHENTICATION utiliza el token de red, si está disponible. De lo contrario, se utiliza el PAN de financiamiento (FPAN) almacenado en el token del motor de pagos. Este modelo actualmente solo admite tokens MDES.
¿Puedo usar tokens de pago mediante dispositivo como fuente de fondos en la autenticación del pagador?
Puede utilizar tokens de pago del dispositivo para la autenticación del pagador desde API v55 en adelante. Solo se admiten tokens de pago obtenidos del SDK de Google Pay. Puede proporcionar un token de pago cifrado o el PAN obtenido de un token de pago descifrado para la autenticación del pagador. El motor de pagos solo acepta solicitudes de autenticación con FPAN, las solicitudes con DPAN se rechazan. Para proporcionar detalles de la tarjeta a través de un token de pago, proporcione los siguientes campos:
-
order.walletProvider = GOOGLE_PAY -
sourceOfFunds.provided.card.devicePayment.paymentTokenToken de pago cifrado obtenido del SDK de Google Pay. Solo es aplicable si el motor de pagos descifra el token de pago.
-
sourceOfFunds.provided.card.numberClave JSON de Google Pay PAN. Solo es aplicable si usted descifra el token de pago.
¿Cómo implemento integraciones de sesiones de pago avanzadas?
Si utilizó una sesión de pago (ID de sesión) para almacenar los detalles de autenticación, la solicitud POST enviada por el explorador del pagador a su sitio web al completar la solicitud de AUTHENTICATE PAYER se parametrizará para permitirle determinar el resultado de la autenticación. Los campos de autenticación individuales, por ejemplo, authentication.3ds2.transactionStatus.data, pueden resultar útiles en una integración avanzada o si tiene la necesidad de proporcionar los datos de autenticación en un pago procesado a través de otro motor de pagos. Para hacerlo, puede enviar una solicitud de RETRIEVE TRANSACTION, o bien optar por descifrar los datos de autenticación cifrados de la siguiente forma:
- Crear una sesión mediante la operación CREATE SESSION.
- Agregue datos relevantes al ID de sesión (devuelto en la respuesta de CREATE SESSION) utilizando la solicitud UPDATE SESSION.
- Utilice el ID de sesión en las solicitudes INITIATE AUTHENTICATION y AUTHENTICATE PAYER.
- La redirección del explorador del pagador a su sitio web contiene detalles de autenticación del pagador en el campo
encryptedData. Es un objeto JSON cifrado que contiene los datos de autenticación obtenidos durante el proceso de autenticación. Contiene los siguientes campos:encryptedData.ciphertextauthentication.3ds.acsEciauthentication.3ds.authenticationTokenauthentication.3ds.transactionIdauthentication.3ds1.veResEnrolledauthentication.3ds1.paResStatusauthentication.3ds2.transactionStatusauthentication.3ds2.dsTransactionIdtransaction.authenticationStatusauthentication.3ds2.statusReasonCodesourceOfFunds.provided.card.numbersourceOfFunds.provided.card.expiry.monthsourceOfFunds.provided.card.expiry.yearsourceOfFunds.tokenorder.idtransaction.id
encryptedData.nonceencryptedData.tag
- Para descifrar el contenido devuelto en el campo
encryptedData.ciphertext, utilice el valor del camposession.aes256Key(devuelto en la respuesta CREATE SESSION) en el modo GCM. La clave codificada en base64 es secreta y solo usted debe conocerla.
public final class SessionDataDecrypter {
/**
* The algorithm used for encryption/decryption
*/
private static final String SYMMETRIC_ALGORITHM = "AES/GCM/NoPadding";
/**
* The algorithm to be associated with the secret key material
*/
private static final String SYMMETRIC_KEY_TYPE = "AES";
/**
* The secret key associated with the session, as returned in the session.aes256Key in a Create Session response.
*/
private final byte[] key;
/**
* Constructs a new object with the given key. The key is Base64 encoded, as returned in the session.aes256Key
* field in a Create Session response. This key must be kept secret, as it may be used to encrypt, decrypt and
* authenticate data for that session.
*
* @param encodedKey Key to be used for decryption.
*/
public SessionDataDecrypter(String encodedKey) {
key = Base64.getDecoder().decode(encodedKey);
}
/**
* Performs decryption of the given ciphertext, using the key passed in the constructor and the associated nonce.
* The tag is used to authenticate the ciphertext.
*
* @param ciphertext Encrypted and authenticated session data
* @param nonce Nonce/Initialization vector associated with the ciphertext
* @param tag Authentication tag
* @return The decrypted session data
* @throws AEADBadTagException if the data cannot be authenticated with the given tag
* @throws InvalidKeyException if the key cannot be constructed properly. This may indicate that it has not been
* correctly retrieved from the response field
* @throws GeneralSecurityException other than {@link AEADBadTagException} and {@link InvalidKeyException}, should
* not be thrown in a correctly set up environment
*/
public String decrypt(String ciphertext, String nonce, String tag)
throws GeneralSecurityException {
Key keySpec = new SecretKeySpec(key, SYMMETRIC_KEY_TYPE);
// The Java crypto classes expect the ciphertext and tag to be a single input, so they need to be concatenated
byte[] encryptedBytes = Base64.getDecoder().decode(ciphertext);
byte[] tagBytes = Base64.getDecoder().decode(tag);
byte[] input = new byte[encryptedBytes.length + tagBytes.length];
System.arraycopy(encryptedBytes, 0, input, 0, encryptedBytes.length);
System.arraycopy(tagBytes, 0, input, encryptedBytes.length, tagBytes.length);
// Configure the cipher with AES, using GCM parameter specifying the nonce/initialization vector
byte[] iv = Base64.getDecoder().decode(nonce);
GCMParameterSpec parameterSpec = new GCMParameterSpec(tagBytes.length * Byte.SIZE, iv);
final Cipher decrypter = Cipher.getInstance(SYMMETRIC_ALGORITHM);
decrypter.init(Cipher.DECRYPT_MODE, keySpec, parameterSpec);
// Perform the decryption and return the value.
byte[] decryptedBytes = decrypter.doFinal(input);
return new String(decryptedBytes, StandardCharsets.UTF_8);
}
}
¿Qué puedo hacer para aumentar las posibilidades de un flujo fluido?
La solicitud AUTHENTICATE PAYER puede incluir mucha información sobre el pagador y la transacción. Por ejemplo, puede proporcionar los siguientes datos en la solicitud utilizando los campos del objeto customer.account, lo que ayuda al ACS del emisor a evaluar el nivel de riesgo asociado con la actividad. Con los pagos legítimos, ayuda al ACS a confirmar que es probable que el pagador sea el titular real de la tarjeta.
- ¿El pagador está usando una cuenta existente?
customer.account.history.creationDate
- ¿Desde cuándo existe la cuenta?
-
customer.account.history.lastUpdated -
customer.account.history.passwordLastChanged
-
- ¿Con qué frecuencia ha comprado el pagador con usted?
-
customer.account.history.addCardAttempts -
customer.account.history.annualActivity -
customer.account.history.recentActivity -
customer.account.history.shippingAddressDate
-
-
customer.account.history.issuerAuthentication.acsTransactionId -
customer.account.history.issuerAuthentication.time -
customer.account.history.issuerAuthentication.type
-
- ¿Ha observado actividad sospechosa (por ejemplo, intentos fallidos de inicio de sesión) en la cuenta?
-
customer.account.history.suspiciousActivity -
customer.account.authentication.method -
customer.account.authentication.time
-
También puede proporcionar los siguientes campos recomendados para cada esquema de tarjeta en la solicitud AUTHENTICATE PAYER. Esta lista no es definitiva y puede estar sujeta a cambios.
Campos recomendados para cada esquema de tarjeta en AUTHENTICATE PAYER
| Campo | Mastercard | Visa | American Express | Notas |
|---|---|---|---|---|
shipping.contact.email | - | - | Y | Obligatorio para calcular el riesgo del negocio |
shipping.method | - | - | Y | Obligatorio para calcular el riesgo del negocio |
order.valueTransfer.amount | - | - | Y | Obligatorio para calcular el riesgo del negocio. Aplicable únicamente a tarjetas de regalo |
order.valueTransfer.numberOfCards | - | - | Y | Obligatorio para calcular el riesgo del negocio. Aplicable solo a tarjetas de regalo. |
order.valueTransfer.currency | - | - | Y | Obligatorio para calcular el riesgo del negocio. Aplicable solo a tarjetas de regalo. |
order.supply.preorderAvailabilityDate | - | - | Y | Obligatorio para calcular el riesgo del negocio. |
order.supply.preorder | - | - | Y | Obligatorio para calcular el riesgo del negocio. |
order.supply.reorder | - | - | Y | Obligatorio para calcular el riesgo del negocio. |
order.valueTransfer.accountType | - | Y | - | Obligatorio para Visa y para otros esquemas en ciertos mercados (por ejemplo, Brasil). No es aplicable si order.valueTransfer.accountType = NOT_A_TRANSFER. |
¿Cómo determino el estado de autenticación?
El motor de pagos proporciona el estado de autenticación en el campo transaction.authenticationStatus. Este campo puede devolver uno de los siguientes valores según la etapa de autenticación:
AUTHENTICATION_ATTEMPTEDSe intentó la autenticación del pagador y se obtuvo una prueba del intento de autenticación.
AUTHENTICATION_AVAILABLELa autenticación del pagador está disponible para el método de pago proporcionado.
AUTHENTICATION_FAILEDEl pagador no fue autenticado. No continúe con esta transacción.
AUTHENTICATION_NOT_SUPPORTEDEl método de autenticación solicitado no es compatible con este método de pago.
AUTHENTICATION_NOT_IN_EFFECTNo hay información de autenticación asociada con esta transacción.
AUTHENTICATION_PENDINGLa autenticación del pagador está pendiente de completar un proceso de desafío.
AUTHENTICATION_REJECTEDEl emisor rechazó la solicitud de autenticación y le solicitó a usted que no intente la autorización de un pago.
AUTHENTICATION_REQUIREDSe requiere autenticación del pagador para este pago, pero no se proporcionó.
AUTHENTICATION_SUCCESSFULEl pagador se autenticó exitosamente.
AUTHENTICATION_UNAVAILABLEEl pagador no se pudo autenticar debido a un problema técnico o de otro tipo.
El período de validez de los datos de autenticación de pago puede depender de su caso de uso. Póngase en contacto con su PSP si necesita una aclaración.
Para utilizar una transacción recurrente con autenticación, consulte Transacciones con credencial en archivo.
¿Cómo utilizar la conversión dinámica de moneda con autenticación del pagador?
Antes de iniciar la autenticación del pagador, puede obtener una cotización de tasa de conversión dinámica de moneda (DCC) del proveedor de DCC mediante el envío de la solicitud PAYMENT OPTIONS INQUIRY.
Si el proveedor de DCC ha hecho una oferta y usted ha proporcionado esta oferta al pagador, debe indicar la reacción del pagador en la solicitud INITIATE AUTHENTICATION:
- Si el pagador ha aceptado la oferta, utilice:
currencyConversion.requestIdcomo se devolvió en la respuesta de PAYMENT OPTIONS INQUIRYcurrencyConversion.uptake = ACCEPTED
- Si el pagador rechazó la oferta, utilice:
currencyConversion.requestIdcomo se devolvió en la respuesta de PAYMENT OPTIONS INQUIRYcurrencyConversion.uptake = DECLINED
Si no se requiere DCC para esta transacción, envíe la solicitud INITIATE AUTHENTICATION con currencyConversion.uptake = NOT_REQUIRED:
Si está configurado para usar DCC y no proporciona currencyConversion.uptake en la solicitud INITIATE AUTHENTICATION, la respuesta de INITIATE AUTHENTICATION indica currencyConversion.uptake = NOT_REQUIRED.
Si el pagador acepta la oferta de DCC, el proceso de autenticación del pagador usa la moneda del pagador y el monto del pagador. En todos los demás casos, el proceso de autenticación del pagador utiliza el monto del pedido y la moneda del pedido.
Puede utilizar la información de DCC proporcionada en la solicitud INITIATE AUTHENTICATION en la solicitud de pago posterior haciendo referencia a la transacción de autenticación (authentication.transactionId). La información de DCC que se envió durante la autenticación del pagador se aplica a su transacción de pago.
También puede enviar la misma información de DCC en las transacciones de pago posteriores que en la autenticación, si así lo desea. Sin embargo, si la transacción de pago posterior hace referencia a la transacción de autenticación y contiene información de DCC que difiere de la autenticación, la transacción de pago se rechaza.
authentication.purpose = REFRESH_AUTHENTICATION).