Autenticação 3DS 2.0

O que é a Autenticação 3DS?

O 3D Secure (3DS) é um protocolo de autenticação desenvolvido para aprimorar a segurança das transações online, verificando a identidade dos portadores de cartão antes que um pagamento seja processado. Ele reduz fraudes e fornece proteção de responsabilidade para os estabelecimentos comerciais e emissores.

Ao implementar a autenticação 3DS, você pode adicionar uma camada extra de segurança às suas transações e reduzir o risco de fraude ao processar pagamentos.

Entendendo o protocolo 3DS 2.x

O protocolo 3DS 2.x utiliza a autenticação baseada em risco para determinar o método de verificação apropriado. O fluxo de autenticação é determinado dinamicamente por muitos fatores, incluindo:

• Bandeira do cartão e banco emissor
• Infraestrutura e capacidades de autenticação do emissor
• Avaliação de risco realizada pelo emissor do cartão
• Características da transação (valor, localização, dispositivo)
• Histórico de autenticação do cliente

Você deve implementar a sua integração para lidar com qualquer um dos cenários possíveis que possam ser retornados pela API com base nesses fatores externos.

Disponibilidade regional

Para obter informações detalhadas sobre a disponibilidade da autenticação 3DS 2.0 por país e bandeiras de cartão suportadas, consulte Core Cards - 3DS Authentication 2.0.

Como o 3DS funciona

O processo de autenticação 3DS começa iniciando um fluxo de inscrição (enrollment) para verificar se o cartão está inscrito em um programa 3DS. A resposta da API indicará qual cenário se aplica a essa transação específica com base nos fatores externos mencionados acima.

Cenários de autenticação possíveis

Sua implementação deve estar preparada para lidar com qualquer um dos seguintes cenários, conforme determinado pelo campo status retornado do endpoint enrollments-initial:

Cenário 1: Autenticação direta (Attempt ou Authenticated)

A autenticação é concluída imediatamente pelo emissor do cartão, sem a necessidade de etapas adicionais.

• O status retorna como Authenticated ou Attempt.
• Os dados de autenticação ficam imediatamente disponíveis.

Esse cenário geralmente ocorre quando a avaliação de risco do emissor determina que a transação é de baixo risco e não é necessária nenhuma verificação adicional. No entanto, se o status for ATTEMPT, você é responsável por determinar se a autenticação está completa ou se um desafio (challenge) é necessário.

Cenário 2: Desafio após a inscrição inicial

O emissor do cartão exige a autenticação imediata do cliente sem processamento adicional.

• O status retorna como Pending Challenge.

• O estabelecimento comercial tem duas opções para redirecionamento:

• redirect_html_template: Renderizar um template HTML fornecido diretamente na aplicação.

• acs_redirect_form: Realizar uma solicitação POST manual usando action_url, creq e threeDSSessionData fornecidos na resposta. Esse método é recomendado para estabelecimentos comerciais que desejam evitar JavaScript externo e usar telas de transição personalizadas.

• Após a autenticação, o endpoint validations deve ser chamado.

• O endpoint continue não é usado neste fluxo.

Cenário 3: Inscrição pendente (Pending Enrollment Continue)

É necessário processamento adicional antes de determinar se a autenticação está completa ou se um desafio é necessário.

• O status retorna como Pending Enrollment Continue.
• O endpoint enrollments-continue deve ser chamado.
• A resposta do continue indicará então:
• Conclusão sem atrito (Frictionless): O status muda para Authenticated ou Attempt.
• Desafio obrigatório: O status muda para Pending Challenge. Nesse caso, o estabelecimento comercial pode escolher novamente redirecionar o cliente usando o template HTML fornecido ou o objeto ACS Direct Form.

Ponto principal

Sua integração deve ser flexível o suficiente para lidar com todos os três cenários. O fluxo é determinado por fatores fora de seu controle, incluindo a bandeira do cartão, o banco emissor e seus algoritmos de avaliação de risco. Sempre verifique o campo status nas respostas da API para determinar qual caminho a transação atual está seguindo.

Autenticação 3DS externa

Em alguns casos, você pode usar uma solução 3DS externa de terceiros para lidar com a autenticação fora da API da GetNet. Ao usar essa abordagem, a autenticação é realizada pelo provedor terceirizado, e você deve fornecer os dados de autenticação resultantes ao criar o pagamento por meio da GetNet.

Ao usar a autenticação 3DS externa, o processo funciona da seguinte forma:

1. O cliente conclui a autenticação por meio de seu provedor 3DS terceirizado.
2. Você recebe os dados de resposta de autenticação do provedor terceirizado.
3. Você inclui esses dados de autenticação ao criar o pagamento por meio da API de pagamentos da GetNet.

Campos de autenticação obrigatórios

Ao usar a autenticação 3DS externa, você deve capturar e fornecer os seguintes campos do seu provedor terceirizado:

Considerações importantes

• Garanta a integridade e a autenticidade dos dados de autenticação recebidos do provedor terceirizado antes de enviá-los para a GetNet.
• As transações podem ser rejeitadas pelo emissor se os campos de autenticação estiverem ausentes ou inválidos.
• O provedor externo deve suportar as bandeiras de cartão e os países em que você opera.

Próximos passos

Agora que você entende como a autenticação 3DS funciona e os diferentes cenários que sua integração deve lidar, você pode:

• Implementar a autenticação 3DS: Siga o guia Criar um pagamento com autenticação 3DS para obter instruções passo a passo, exemplos de código e práticas recomendadas.

• Revisar as referências da API: Consulte a documentação detalhada da API para obter os parâmetros de requisição, campos de resposta e especificações de endpoint:

  • Referência da API - token

  • Referência da API - enrollments initial

  • Referência da API - enrollments continue

  • Referência da API - validations