Visão geral

A API Real-time Data Exchange (RDX) integra-se ao Visa Consumer Authentication Service (VCAS) para ajudar nas decisões de autenticação de transações. O RDX permite que o emissor decida o quanto gostaria de estar envolvido no processo de transação, compartilhando dados entre o VCAS e o emissor ou processador do emissor.

RDX 2.2.3 suporta EMV 3DS versão 2.2.0 e implementações EMV 3DS de emissores específicos. Cada protocolo EMV 3DS pode exigir elementos de dados específicos para completar a autenticação. Verifique com sua equipe VCAS para mais detalhes

RDX oferece suporte a quatro chamadas de APIs:

• Risk-Based Analysis ou chamada Risk
• Chamada de Stepup
• Chamada de Initiate Action
• Chamada de Validate

Usando o RDX, um emissor pode informar ao VCAS por que o titular do cartão respondeu daquela maneira usando os campos Código do Motivo e Descrição do Motivo. Por exemplo, um emissor pode informar ao VCAS que respondeu com SUCCESS para a resposta Stepup depois que o titular do cartão autenticar a transação com sucesso.

Nota: RDX usa PascalCase para nomes de objetos e campos.

Nota: Não adicione validação estrita em nenhum campo marcado como opcional desta especificação.

Risk-Based Analysis ou chamada de Risk

A chamada de Risk é a primeira etapa do processo RDX e correlaciona informações de transação, comerciante, consumidor e dispositivo para determinar o nível de risco em uma determinada transação. As respostas para a chamada de risco incluem:

SUCCESS: Termina a transação com um status de autenticação bem-sucedido para o comerciante.
STEPUP: Continua com o fluxo do desafio.
FAILURE: Termina a transação com status de falha de autenticação para o comerciante.
FAILWITHFEEDBACK: Apresenta uma tela ao titular do cartão com instruções para obter ajuda e retornará um status de falha na autenticação ao comerciante.
ERROR: Retorna um status de autenticação indisponível para o comerciante.
BLOCKED: Bloqueia o cartão e retorna um status de falha de autenticação ao comerciante, futuras tentativas de autenticação falharão até serem desbloqueadas.
REJECTED: Este status encerra a transação com um status de autenticação rejeitada para o comerciante e indica que ele não deve prosseguir com a autorização. Suportado apenas para transações 2.x.x.

As primeiras quatro condições resultarão na finalização da transação e o portador do cartão será redirecionado ao site do estabelecimento comercial com o status 3DS correspondente. O resultado do reforço da autenticação resultará em uma outra autenticação do portador do cartão.

Como explicado anteriormente, com RDX, o Emissor pode decidir o quanto se envolverá no processo de decisão. Por exemplo, o Emissor pode implementar uma ligação de Risco que lhe permita usar suas próprias regras/mecanismo de risco na avaliação do risco. Outra opção é usar VCAS na avaliação do risco.

Chamada de Step-up (reforço de autenticação)

Se o resultado da avaliação do risco for o status Step-up, isso determinará o tipo de desafio que o emissor quer enviar ao portador do cartão. O resultado desse passo consiste principalmente em uma lista de maneiras pelas quais o portador do cartão pode ser desafiado, também chamada de “Credenciais”.

O Emissor poderá optar por não compartilhar os dados ou credenciais do portador do cartão com VCAS e implementar uma chamada de Step-up para dizer à VCAS como desafiá-lo. Nesse caso, VCAS informaria o PAN ao Emissor durante a chamada de Step-up para que este pesquise o portador do cartão e envie ao portador uma das muitas opções de desafio na resposta de Step-up. A outra opção é o Emissor fornecer os dados do portador do cartão à VCAS na forma de “credenciais” para que estes sejam usados para desafiar o portador.

Chamada de Initiate Action

A chamada de Initiate Action acontece quando um método de autenticação (step-up) é iniciado. No caso do OTP (código de uso único), este será enviado ao portador do cartão pelo método de contato que ele indicou. Como resultado da chamada Initiate Action, o portador vê a tela “Validar”. Essa tela lhe dará instruções de como completar a autenticação, seja inserindo um OTP ou interagindo com um aplicativo externo. O emissor tem várias opções de desenvolvimento à sua disposição, dependendo de sua preferência..

• Opção 1: VCAS gera, entrega e valida o OTP. Neste caso, o Emissor não implementaria a ligação “Iniciar Ação”.
• Opção 2: O Emissor gera, entrega e valida o OTP. Neste caso, o Emissor implementaria as ligações “Iniciar Ação” e “Validar”.
• Opção 3: VCAS gera o OTP, o Emissor o entrega e VCAS faz a validação. Neste caso, o Emissor implementaria a ligação “Iniciar Ação”.

Nota: Quando o fluxo OOB é incorporado, a chamada Initiate Action não é aplicável.

Chamada de Validate

Para o caso de autenticação via OTPs, a chamada de Validate ocorre quando o portador do cartão envia esse código para validação. Após a validação, é enviado um status. Os possíveis status são:

• SUCCESS: Termina a transação com um status de autenticação bem-sucedido para o comerciante.
• RETRY: : Permite que o titular do cartão tente novamente a autenticação e a lógica de validação pode ser criada para limitar o número de tentativas de autenticação. Nota: Este status só é aplicável quando o VCAS não está validando o valor OTP ou Token do emissor.
• STEPUP: Permite que o titular do cartão seja desafiado novamente e reinicie o processo RDX com uma nova solicitação de etapa RDX.
• PENDING: Iniciará uma solicitação de validação do VCAS para o emissor após 2 segundos e só será usada quando o StepUpResponse ➤ Tipo é OUTOFBANDOTHER ou BIOMETRIC.
• FAILURE: Termina a transação com status de falha de autenticação para o comerciante.
• FAILWITHFEEDBACK: Apresenta uma tela ao titular do cartão com instruções para obter ajuda e enviará de volta um status de falha na autenticação ao comerciante.
• ERROR: Retorna um status de autenticação indisponível para o comerciante.
• BLOCKED: Bloqueia o cartão e retorna um status de falha de autenticação ao comerciante, futuras tentativas de autenticação falharão até serem desbloqueadas.
• REJECTED: Suportado apenas para transações 2.x.x. Este status encerra a transação com um status de autenticação rejeitada para o comerciante e indica que ele não deve prosseguir com a autorização.

Se o portador do cartão inserir o OTP corretamente, a transação é bem-sucedida e retorna à página do estabelecimento comercial. Se o portador do cartão inserir um código inválido, pode ocorrer uma falha ou bloqueio e a transação é completada com um status correspondente no 3DS.

Se o portador do cartão inserir um código inválido, o Emissor pode decidir o número de tentativas permitidas antes que a transação seja considerada falha ou bloqueada. O emissor pode ainda pedir para o portador do cartão resolver outro desafio, o que envolveria o reenvio de um OTP ou na escolha de um método de entrega diferente.

Por exemplo, se o portador do cartão inserir o OTP via SMS várias vezes sem sucesso, o Emissor pode enviá-lo novamente ou pedir para o portador escolher outro método de envio. O portador do cartão também tem a opção de solicitar o reenvio se o OTP original não estiver funcionando corretamente. Um exemplo seria se o portador do cartão tivesse pedido que o OTP fosse enviado via SMS, mas gostaria de tentar recebê-lo por e-mail porque a mensagem de texto não está chegando.

O status PENDING (PENDENTE) é usado para métodos de autenticação OOB (“out of band”) , pr exemplo “BIOMETRICS”; se o portador do cartão ainda não foi autenticado, o Emissor receberia esse status.

Valores do indicadores de risco (Risk Indicator)

O valor RiskIndicator é definido durante os fluxos de risco ou desafio para indicar o nível de risco ou o tipo de desafio. A seguir, o valor é usado na interpretação de certos Valores de Autenticação (AV). Por exemplo, o CAVV Usage 3 Version 0 permite que esse valor seja passado dentro do valor AV enviado para o DS (Servidor de Diretório) da rede.

Consulte Risk Indicator Values , converse com seu gerente de implementação ou consulte a documentação “VCAS Enhanced Authentication Value Support Guide”.

Backwards Compatibility

O RDX apresenta compatibilidade com versões anteriores para lidar perfeitamente com novas versões EMV 3DS à medida que são introduzidas. Este recurso permite que os clientes VCAS atualizem sua versão RDX independentemente quando novas versões EMV 3DS estiverem disponíveis. Quando o VCAS habilita uma nova versão do EMV 3DS, qualquer campo EMV 3DS existente que receba um novo valor será mapeado novamente para um valor de versão anterior do EMV 3DS (por exemplo o Merchant Challenge Indicator e 3RI Indicator). Para qualquer novo campo e valor líquido, eles serão descartados para qualquer versão anterior do RDX, o que permitirá que os emissores atualizem para a versão mais recente do RDX com base em seus próprios cronogramas de desenvolvimento.

Conteúdo e Tipoos de mensagem

Todas as solicitações e respostas de RDX devem ser enviadas usando o Tipoo de dados JSON. Cada solicitação deve estar acompanhada de um cabeçalho Content-Type do aplicativo/json. Atualmente, a estrutura de todos os campos JSON será Pascal-Case, conforme mostrado nas colunas “Nome” abaixo.

Nota: Em muitos casos, a plataforma VCAS só recebe valores de campo do servidor de diretório da maneira como eles são enviados pelos estabelecimentos comerciais ou por outras partes. Portanto, VCAS não poderá definir comprimentos específicos para esses campos. Os comprimentos documentados nesta especificação representam os comprimentos de campo conhecidos e os cenários mais favoráveis. Pode ser que os emissores precisem se envolver na validação de campos não validados por VCAS.