# 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](https://www.google.com/search?q=/en/products/online-payments/regional-api%3Fdoc%3Dreference-core-cards%233ds-authentication-20). Para todas as transações dentro do Espaço Econômico Europeu (EEE), a autenticação 3DS é obrigatória em conformidade com a Diretiva Revisada de Serviços de Pagamento (PSD2) e os requisitos de Autenticação Forte do Cliente (SCA). Todos os pagamentos com cartão processados na Europa devem ser autenticados usando o 3DS, a menos que uma isenção válida de SCA seja aplicada e aceita pelo emissor do cartão. Para obter mais informações sobre isenções de SCA e como aplicá-las, consulte a documentação de referência de [Impostos e Regulamentações](https://www.google.com/search?q=/developer-resources/taxes-regulations%23spain). ## 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: | Campo | Descrição | | :--- | :--- | | **tdsver** | A versão do protocolo 3DS usada na autenticação (por exemplo, "1.0.2" ou "2.2.0") | | **xid** | Um identificador de transação exclusivo gerado no fluxo 3DS, vinculando a autenticação ao pagamento | | **ucaf** | *Universal Cardholder Authentication Field* - um valor criptográfico comprovando que a autenticação foi concluída (usado em versões mais antigas do 3DS) | | **eci** | *Electronic Commerce Indicator* - um código que indica o resultado e o nível da autenticação | | **tdsdsxid** | Um identificador de transação gerado pelo protocolo 3DS 2.x (equivalente a `ds_trans_id`) | ### 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](https://www.google.com/search?q=/en/products/online-payments/regional-api%3Fdoc%3Dcreate-3ds-payment) 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](https://www.google.com/search?q=/en/products/online-payments/regional-api/swagger%23tag/cards/post/dpm/cofre-gw-proxy/v1/tokens/card) * [Referência da API - enrollments initial](https://www.google.com/search?q=/en/products/online-payments/regional-api/swagger%23tag/payments/post/dpm/security-gwproxy/v2/enrolments-initial) * [Referência da API - enrollments continue](https://www.google.com/search?q=/en/products/online-payments/regional-api/swagger%23tag/payments/post/dpm/security-gwproxy/v2/enrolments-continue) * [Referência da API - validations](https://www.google.com/search?q=/en/products/online-payments/regional-api/swagger%23tag/payments/post/dpm/security-gwproxy/v2/validations)