Personalização antifraude
Projete, teste e opere sinais de fraude, decisões do provedor, roteamento e feedback de resultados, sem depender do resultado de um navegador.
Nesta página
Personalize os controles de fraude como um sistema de decisão completo: colete sinais permitidos, solicite uma decisão ao provedor configurado, traduza essa decisão em uma ação de pagamento e retorne resultados confirmados para que o modelo possa melhorar.
Ciclo de vida da decisão de fraude#
01 · observe
Colete sinais aprovados
Envie informações precisas sobre o pedido, o cliente, o vendedor, o endereço e o dispositivo, que o provedor selecionado suporta.
02 · assess
Avalie o risco
A DEUNA invoca a conexão anti-fraude ativa no ponto configurado na estratégia de pagamento.
03 · act
Aplique a política
Continue, solicite autenticação, suspenda para revisão, roteie de forma diferente ou rejeite de acordo com o resultado padronizado.
04 · confirm
Reconcilie o estado do pagamento
Utilize o estado de pagamento autorizado ou um webhook verificado antes da conclusão.
05 · learn
Retorne resultados
Envie os resultados de fraude e contestação acordados para que o provedor possa avaliar o desempenho do modelo.
Diagrama de fluxo
O nível de risco sozinho não é um resultado de pagamento. Uma transação de baixo risco ainda pode ser rejeitada por um processador, e uma autenticação bem-sucedida ainda pode resultar em uma autorização malsucedida. Mantenha o status de fraude, autenticação e pagamento como campos separados.
Selecione a tarefa de personalização#
Impressão digital do dispositivoGere e envie o identificador do dispositivo esperado pelo provedor de fraude ou pagamento configurado.Web and supported SDK flowsModo sombraCompare as decisões do provedor em tráfego semelhante ao de produção antes que um novo modelo afete a jornada do cliente.Observe without blockingRetroalimentação do resultadoEnvie os resultados históricos de contestação acordados, sem confundir a ingestão de feedback com a gestão de disputas.Email or provisioned SFTPEstratégias de pagamentoRealize a avaliação de fraude antes ou depois da autorização e defina a ação para cada resultado suportado.Decision to actionStatus de fraudeAvalie a fraude separadamente do ciclo financeiro e do estado de revisão manual.State and decisionsRecursos dos provedoresVerifique onde cada provedor de anti-fraude está publicado e abra o guia de conexão.Country and capability filters
Determine onde a fraude é executada#
| Posicionamento | O que protege | Principal trade-off | Tratamento necessário |
|---|---|---|---|
| Antes da autorização | Evite enviar tentativas bloqueadas por políticas para o processador | Um tempo limite de fraude pode atrasar ou impedir o pagamento antes que uma autorização seja emitida. | Defina o tempo limite e o comportamento de fallback; não invente um resultado de pagamento. |
| Após a autorização | Permite que o provedor avalie o processador e o contexto da autorização. | Uma autorização aprovada pode precisar ser cancelada quando o risco rejeita o pedido. | Mantenha a conclusão bloqueada e verifique o resultado do cancelamento ou da captura. |
| Modo sombra | Mede o provedor sem alterar as decisões de pagamento. | Os resultados são observacionais e não devem se tornar automaticamente uma imposição. | Separe as métricas de comparação das entradas de roteamento em tempo real. |
| Revisão manual | Adiciona uma revisão humana ou do provedor antes da ação final. | O fluxo do cliente e da conclusão permanecem pendentes por mais tempo, | Trate manual_review como não resolvidos e consomem o estado autoritativo posterior. |
Uso Autenticação dinâmica Quando o resultado da fraude seleciona um controle de verificação, como o 3DS. Use Revisão manual para transações em espera e 3DS para o comportamento de autenticação do emissor.
Sinal de contrato#
Envie apenas dados precisos, permitidos e suportados pelo provedor selecionado. Mais campos não garantem automaticamente uma melhor decisão.
| Grupo de sinal | Exemplos | Regra de integração |
|---|---|---|
| Pedido | Valor, moeda, itens, entrega, descontos | Manter os totais consistentes com a ordem processada pelo backend |
| Cliente | Referência do cliente estável, histórico de contas, contexto de contato | Não coloque credenciais secretas ou dados pessoais irrelevantes em campos de texto livre |
| Dispositivo | Impressão compatível com o provedor ou identificador de sessão do dispositivo | Gerar no fluxo do cliente suportado e vincular à mesma tentativa de pagamento |
| Plataforma de marketplace | Identificadores de vendedores e atributos de vendedores aprovados | Confirmar quais marketplace_sellers campos o provedor realmente consome |
| Resultado | Resultado do pagamento, fraude confirmada ou estado de cobrança acordado | Enviar de forma idempotente com o identificador da transação da DEUNA |
Implementar com segurança#
- Confirmar suporte. Escolha o provedor, os mercados, os canais e a estratégia de avaliação, conforme definido na capacidade e no contrato comercial.
- Definir a política. Defina a ação para cada resultado de provedor suportado, tempo limite, resposta indisponível e resultado de revisão manual.
- Mapeie os sinais. Documente a fonte, o formato, a base de consentimento e a estratégia de fallback para cada campo que você envia.
- Valide no ambiente de teste. Teste os casos de baixo, médio, alto, indisponível, tempo limite, duplicado e sinal malformado.
- Compare em modo de sombra. Meça a cobertura e o desacordo antes de ativar um novo provedor ou modelo em produção.
- Lance gradualmente. Monitore os resultados de aprovação, contestação, revisão, falsos positivos, fraude e pagamento em conjunto.
- Feche o ciclo. Retorne os resultados aprovados através do fluxo de feedback de cobrança.
Lista de verificação operacional#
- Mantenha as credenciais do provedor privadas no DEUNA Admin ou em um backend seguro, nunca no código do navegador ou mobile.
- Correlacione a avaliação de fraude, a tentativa de pagamento, o pedido e o resultado final com identificadores estáveis.
- Torne os retornos idempotentes; um tempo limite do cliente não prova que uma avaliação ou pagamento falhou.
- Mantenha a referência original do provedor necessária para suporte, expondo apenas a decisão normalizada para a lógica de negócios.
- Notificação em caso de dados de dispositivo ausentes, avaliação de latência, respostas indisponíveis, desvio de decisões e falhas no processamento de feedback.
- Reavalie a estratégia sempre que um provedor, SDK, mercado ou sinal necessário mudar.