Skip to main content
Os provedores antifraude assíncronos na Malga possuem um ciclo de vida que percorre quatro etapas, separadas em dois momentos:
  1. Pré Autorização
  2. Solicitação de Análise Antifraude
  3. Recebimento da Análise
  4. Captura e envio do webhook
No primeiro momento a transação é enviada para o provedor de cobrança para ser pré capturada e enviada para o provedor de antifraude como ilustra o diagrama a seguir. Fluxo Antifraude Assíncrono Num segundo momento, após a avaliação de risco ser feita pelo provedor antifraude, o mesmo retorna o status através de um webhook onde a automação de captura ou cancelamento acontece. Fluxo Notificação Antifraude Assíncrono
O comportamento automatizado do ciclo de vida da transação pode ser escolhido utilizando as configurações de captureOnApproved e refundOnReproved feitas diretamente no setup de provedor de antifraude para uso na Malga.
No sandbox, o final do documento do customer em fraudAnalysis simula o assíncrono: com final 0, a análise começa pendente e é aprovada cerca de 2 minutos depois; com final 9, começa pendente e é reprovada no mesmo prazo. Os demais finais estão em Testando antifraude em sandbox.

​
Cobrança com capture: true

Em cartão de crédito, inclusive Click to Pay, com antifraude configurado e sem fluxo de pagamentos, a Malga aceita capture: true e captura sozinha quando o antifraude aprova. Isso vale para o veredito síncrono e para o assíncrono, e acontece mesmo com captureOnApproved: false. Não vale para 3DS com setupId nem para MPI externo.
  • Durante a análise: a cobrança aparece como pre_authorized com capture: false.
  • Depois da captura: a cobrança passa a authorized com capture: true. Os webhooks seguem o status.
  • Prazo de 72 horas: uma aprovação que chega depois do prazo não captura. Uma pré-autorização sem veredito em 72 horas é cancelada automaticamente.
  • Reprovação e erro: seguem as opções captureOnReproved, refundOnReproved, captureOnError e refundOnError do provedor.
  • Sessão ou link de pagamento 1:1: um novo pagamento enquanto a cobrança está em análise recebe 409 com a mensagem “There is already a charge for this session under anti-fraud analysis”. Repetir a requisição com a mesma X-Idempotency-Key devolve a cobrança original.
O recurso está em liberação gradual. Enquanto a sua conta não for liberada, a API responde 400 com a mensagem “The capture cannot be true in this operation”. Fale com o suporte para habilitar. No sandbox, a simulação do veredito segue a mesma regra, mas o cancelamento automático em 72 horas não existe.
Não é possível configurar a opção runBeforeCharge=true utilizando produtos de antifraude que possuam fluxos de avaliação assíncronos ou híbridos. Caso tenha dúvidas sobre o suporte desta variável com o seu produto antifraude entre em contato com o nosso suporte.

​
Exemplos de uso do antifraude

Para utilizar análises antifraude em suas transações basta estar credenciado em um provedor antifraude e configurá-lo em seu fluxo de pagamentos. Assim, será possível processar uma transação enviando as informações adicionais de antifraude.

​
Exemplo de cobrança com Antifraude aprovado

Após a pré autorização, se a cobrança passar pela avaliação de risco, é aprovada e capturada na sequência.

​
Exemplo de cobrança com Antifraude reprovado

Após a pré autorização, se a análise de risco for reprovada, a transação é rejeitada e a pré autorização é cancelada automaticamente.
Sempre que a transação for reprovada no antifraude, faremos o cancelamento da pré autorização automaticamente. Caso a tentativa de cancelamento falhe, a transação manterá o status pre_authorized e poderá ser cancelada ou capturada manualmente, de acordo com a sua preferência.

​
Exemplo de cobrança com erro ao acessar Antifraude

Em cobranças com capture: false, caso um erro ocorra no provedor antifraude e nenhuma das opções de erro esteja habilitada, a transação é retornada ainda pré-autorizada. Em cobranças com capture: true e antifraude, a pré-autorização também existe até o veredito, e o desfecho segue captureOnError ou refundOnError. Exemplo de erro
Caso ocorra alguma instabilidade com o provedor antifraude, existem duas opções para lidar com este cenário que devem ser configuradas em seu fluxo de pagamentos:
  • captureOnError: Faz a captura mesmo que ocorra instabilidade no provedor de antifraude.
  • refundOnError: Faz o estorno da transação em caso de instabilidade no provedor de antifraude. Não pode ser ligada ao mesmo tempo que captureOnError.
Em cobranças com capture: false, quando captureOnError e refundOnError estão desligadas, a transação é retornada como pre_authorized. Em cobranças com capture: true e antifraude, a transação segue pré-autorizada até o veredito e, sem veredito em 72 horas, é cancelada automaticamente.
Para testar os diversos comportamentos das propriedades descritas acima, veja sobre Alterar o status do antifraude no ambiente de sandbox