Introducción

Real-time Data Exchange (RDX) es una API que se integra con Visa Consumer Authentication Service (VCAS) para colaborar con las decisiones en las transacciones. RDX trabaja tanto con EMV 3DS como con 3DS 1.0. Le permite al Emisor decidir cuánto quiere involucrarse en el proceso de la transacción al compartir información entre VCAS, el emisor y el procesador del emisor.

RDX 2.2.3 admite la versión 2.2.0 de EMV 3DS y las implementaciones específicas del emisor de EMV 3DS. Cada protocolo EMV 3DS puede requerir elementos de datos específicos para completar la autenticación. Consulte con su equipo de VCAS para obtener más detalles.

RDX admite cuatro llamadas API:

• Risk-Based Analysis or Risk Call
• Stepup Call
• Initiate Action Call
• Validate Call

Durante la autenticación de la transacción con RDX, un emisor puede utilizar el Reason Code y Reason Description campo para informar a VCAS por qué respondieron de la manera que lo hicieron. Por ejemplo, los emisores pueden decirle a VCAS que respondieron con SUCCESS para la respuesta de Stepup después de que el titular de la tarjeta autentica con éxito la transacción.

Nota: RDX uses PascalCase for Objeto and field Nombres.
Nota: No agregue validación estricta en ningún campo opcional en esta especificación.

Análisis basado en riesgo o solicitud de riesgo

El riesgo es el primer paso en el proceso RDX y es la culminación de la transacción, comercio, consumidor e información del dispositivo que se utiliza para evaluar si la transacción tiene algún riesgo. Las respuestas posibles a la solicitud de riesgo son:

SUCCESS: Finaliza la transacción con un estado de autenticación exitoso para el comercio.
STEPUP: Continúa con el flujo de desafío.
FAILURE: Finaliza la transacción con un estado de autenticación fallido para el comerciante.
FAILWITHFEEDBACK: Presenta una pantalla al titular de la tarjeta con instrucciones para obtener ayuda y enviará un estado de autenticación fallido al comercio.
ERROR: Devuelve un estado de autenticación no disponible para el comercio.
BLOCKED: Bloquea la tarjeta y devuelve un estado de autenticación fallido al comercio, los futuros intentos de autenticación fallan hasta que se desbloquea.
REJECTED: Solo se admite para transacciones 2.x.x. Este estado finaliza la transacción con un estado de autenticación rechazado para el comerciante e indica que no deben proceder con la autorización.

Los primeros cuatro estados que se muestran arriba indican que la transacción se completó y el tarjetahabiente será redireccionado al sitio del comercio con el estado 3DS que corresponda. En el caso de Step-up, se requerirá mayor autenticación del tarjetahabiente.

Como se indica anteriormente, con RDX el Emisor puede decidir cuánto se involucrará en el proceso de decisión. Por ejemplo, el Emisor puede implementar una solicitud de riesgo que le permitirá utilizar su propio motor de riesgo/reglas para determinar el riesgo. El Emisor también tiene la opción de utilizar VCAS para la evaluación de riesgo.

Solicitud Step-up (autenticación adicional)

Si la evaluación de riesgo arroja un estado de Step-up, se determinará el tipo de desafío que el emisor quiere enviar al tarjetahabiente. El resultado de este paso consiste, mayormente, en una lista de formas también llamada “Credentials” (Credenciales) en las que el tarjetahabiente puede ser desafiado.

El emisorpuede optar por no compartir la información del tarjetahabiente o las credenciales con VCAS y puede implementar la solicitud de Step-up para indicarle al VCAS cómo desafiar al tarjetahabiente. En este escenario, VCAS le pasaría el PAN al emisordurante la solicitud Step-up para que el emisorpueda buscar al tarjetahabiente y en la respuesta de Step-up enviar desde una a varias opciones para desafiar al tarjetahabiente. La otra opción es que el emisorle brinde a VCAS la información del tarjetahabiente en forma de “credenciales” para su uso al momento de desafiar al tarjetahabiente.

Solicitud de inicio de acción (Initiate action)

La solicitud de inicio de acción (Initiate action) se produce al comenzar un step-up. En el caso de “One-Time Passcode” (código de un solo uso) u OTP, este debe enviarse a través del medio de contacto seleccionado por el tarjetahabiente. El resultado de la solicitud de inicio de acción (Initiate action) es que el tarjetahabiente verá la pantalla de “Validación” Esta pantalla le brindará instrucciones al tarjetahabiente sobre cómo completar la autenticación, ya sea ingresando un OTP o interactuando con una aplicación de terceros.

El emisor tiene múltiples niveles de envolvimiento disponibles dependiendo de su preferencia.

• Opción 1: El VCAS genera, entrega y valida el OTP. Para esto, el emisor no implementará la solicitud de inicio de acción (Initiate action).
• Opción 2: El emisor genera, entrega y valida el OTP. Para esto, el emisor implementará una solicitud de inicio de acción (Initiate Action) y una solicitud de validación (Validate).
• Opción 3: El VCAS genera, entrega y valida el OTP. Para esto, el emisorimplementará la solicitud de inicio de acción (Initiate action).

Nota: Para el flujo OOB incorporado, la llamada de acción de inicio no es aplicable.

Validación

En el caso del One-Time Password, el paso de validación es donde el tarjetahabiente envía ese código para ser validado. Cuando se haya completado la validación, se envía un estado. Los posibles estados son:

• SUCCESS: Finaliza la transacción con un estado de autenticación exitoso para el comercio.
• RETRY: Permite al titular de la tarjeta volver a intentar la autenticación y se puede construir una lógica de validación para limitar el número de intentos de autenticación. Nota: Este estado solo es aplicable cuando VCAS no está validando el OTP del emisor o el valor del Token.
• STEPUP: Permite que se desafíe nuevamente al titular de la tarjeta y comenzará el proceso RDX de nuevo con una nueva Solicitud de Paso RDX.
• PENDING: Iniciará otra Solicitud de Validación de VCAS al emisor después de 2 segundos y solo se utilizará cuando StepUpResponse ➤ Type sea OUTOFBANDOTHER o BIOMETRIC.
• FAILURE: Finaliza la transacción con un estado de autenticación fallido para el comercio.
• FAILWITHFEEDBACK: Presenta una pantalla al titular de la tarjeta con instrucciones para obtener ayuda y enviará un estado de autenticación fallido al comercio.
• ERROR: Devuelve un estado de autenticación no disponible para el comercio.
• BLOCKED: Bloquea la tarjeta y devuelve un estado de autenticación fallido al comercio, los futuros intentos de autenticación fallan hasta que se desbloquea.
• REJECTED: Solo se admite para transacciones 2.x.x. Este estado finaliza la transacción con un estado de autenticación rechazado para el comerciante e indica que no deben proceder con la autorización.

Si un titular de tarjeta ingresa correctamente el OTP, la transacción es exitosa y se devuelve a la página del comerciante. Si el titular de la tarjeta ingresa un código inválido, puede producirse un fallo o bloqueo, completando así la transacción con el estado 3DS correspondiente.

Si el titular de la tarjeta ingresa un código inválido, el emisor puede decidir cuántos intentos se permiten antes de que la transacción sea un fracaso o esté bloqueada. El emisor también puede optar por volver a desafiar al titular de la tarjeta, lo que puede resultar en un reenvío de un OTP o elegir un método de entrega diferente.

Por ejemplo, si un titular de tarjeta ingresa el OTP a través de SMS demasiadas veces sin éxito, el emisor puede reenviar el OTP o hacer que elija un método de entrega diferente. El titular de la tarjeta también puede pedir un reenvío si el OTP original no funciona correctamente. Un ejemplo es si el titular de la tarjeta solicita un OTP a través de SMS pero no ha recibido ningún SMS y le gustaría probar la entrega por correo electrónico en su lugar.

El estado "PENDING" se utiliza para métodos de autenticación fuera de banda (por ejemplo, biometría); si el titular de la tarjeta aún no se ha autenticado, el emisor devolvería un estado de "PENDING". El cliente es responsable de gestionar y hacer un seguimiento de la validación, por lo que tener esto señalado aquí les ayudará a pensar en cómo hacer un seguimiento internamente.

Risk Indicator Values

El valor del indicador de riesgo se establece durante los flujos de riesgo o desafío para indicar el nivel de riesgo o el tipo de desafío. Luego, el valor se utiliza en la construcción de ciertos valores de autenticación (AV). Por ejemplo, CAVV Uso 3 Versión 0 y CAVV Uso 3 Versión 7 permiten que este valor se pase dentro del valor AV que se envía al servidor de directorio de redes (DS).

Consulte Valores del Indicador de Riesgoo contacte a su representante de VCAS o consulte la documentación "VCAS Enhanced AV" para obtener más detalles.

Backwards Compatibility

RDX presenta compatibilidad hacia atrás para manejar de manera elegante las nuevas versiones de EMV 3DS a medida que se introducen. Esta característica permite a los clientes de VCAS actualizar su versión de RDX independientemente de cuándo estén disponibles las nuevas versiones de EMV 3DS. Cuando VCAS habilita una nueva versión de EMV 3DS, cualquier campo existente de EMV 3DS que obtenga un nuevo valor será reasignado a un valor de versión anterior de EMV 3DS (por ejemplo, indicador de desafío del comerciante e indicador 3RI). Para cualquier campo y valores completamente nuevos, estos se eliminarán para cualquier versión anterior de RDX, lo que permitirá a los emisores actualizar a la última versión de RDX según sus propios plazos de desarrollo.

Content and Message Formats

Todas las solicitudes y respuestas RDX deben enviarse utilizando el formato de datos JSON. Acompañando a cada solicitud habrá una cabecera Content-Type de application/json. Actualmente, el uso de mayúsculas y minúsculas de todos los campos JSON será Pascal-Case, como se muestra en las columnas "Name" a continuación.

Nota: En muchos casos, la plataforma VCAS solo recibe valores de campo del servidor de directorio tal como los recibe de los comerciantes y otras partes. Por lo tanto, VCAS puede no establecer longitudes específicas para estos campos. Las longitudes documentadas en esta especificación representan las longitudes de campo conocidas y los mejores escenarios posibles. Los emisores pueden necesitar abordar la validación para los campos que VCAS no valida.