A prevenção de fraude em pagamentos online não é um único controle. É uma cadeia deles, distribuída por três momentos: antes da transação, durante ela e depois que o estorno chega, semanas mais tarde. A maioria dos comerciantes tem algo em cada janela e lacunas entre elas, e os fraudadores vivem nas lacunas. Este guia percorre os principais tipos de fraude em pagamentos online, as camadas de prevenção que travam cada um e onde uma fonte de sinais no nível do navegador se encaixa numa arquitetura que você provavelmente já usa.
O enquadramento que mais importa: uma transação fraudulenta e uma legítima parecem idênticas no seu banco de dados. O número do cartão foi validado, o endereço bateu, o CVV estava correto e o pedido foi enviado. A diferença só aparece depois, quando o titular real a contesta. Uma prevenção eficaz consiste em capturar os sinais que distinguem os dois enquanto a sessão ainda está aberta, porque, uma vez que ela fecha, esses sinais desaparecem.
O que conta como fraude em pagamentos online
A fraude em pagamentos online é qualquer transação em que quem paga não está autorizado a usar o meio de pagamento, ou em que uma compra legítima é depois contestada falsamente. Abrange cartões roubados, card testing automatizado, tomada de conta e abuso de estorno. Não inclui erros genuínos de processamento nem devoluções legítimas, embora estes se misturem no mesmo funil de disputas.
A razão pela qual é difícil travá-la apenas com dados de transação é que o payload que o seu provedor de serviços de pagamento (PSP) recebe é escasso. Ele carrega o número do cartão, o valor e o endereço, mas não o dispositivo que o enviou, a forma como o formulário foi preenchido nem se a conexão estava oculta atrás de um proxy. Isso vive no navegador durante a sessão e nunca chega ao PSP. Essa é a lacuna de provas que o resto deste guia busca fechar.
Os quatro principais tipos de fraude em pagamentos online
Card testing (carding)
O card testing é a fase de reconhecimento. Os atacantes que compraram um lote de números de cartão roubados precisam saber quais ainda funcionam, então executam pequenas cobranças, muitas vezes de um dólar ou uma doação, em centenas de números para separar os cartões vivos dos mortos. Os cartões validados são depois usados para compras reais ou revendidos a um preço mais alto.
O card testing é quase sempre automatizado. Ninguém digita mil números de cartão à mão. Essa automação é a fraqueza: o ataque é rápido, repetitivo e conduzido por máquina de uma forma que um checkout humano nunca é. As regras de velocidade pegam a versão grosseira, mas os operadores sofisticados distribuem as tentativas para ficar abaixo dos limites. O caso de uso de card testing cobre o padrão de detecção em profundidade.
Fraude com cartão roubado (transação não autorizada)
Uma vez validado um cartão, ele é usado. A fraude com cartão roubado é o caso clássico: alguém compra bens com um cartão que não lhe pertence, envia-os para um endereço de reenvio ou para um laranja, e o titular real descobre no extrato. Essa é uma fraude de terceiros genuína, e é o que a maioria das pessoas imagina ao ouvir "fraude em pagamentos".
O sinal que ajuda aqui é a continuidade de dispositivo. Um cartão usado a partir de um dispositivo que nunca foi associado a esse titular, ou a partir de um dispositivo já ligado a fraude anterior, é um risco materialmente diferente do mesmo cartão usado no telefone conhecido do titular. Os dados de transação não conseguem ver o dispositivo. Uma impressão no nível do navegador consegue.
Estornos e fraude amigável
Nem todos os estornos são criminosos. Uma grande parte é "fraude amigável", em que um titular real contesta uma cobrança que de fato fez, às vezes por engano (não reconheceu o descritor do comerciante) e às vezes deliberadamente (quer os bens e o reembolso). As estimativas variam por fonte e setor, mas as pesquisas do setor situam consistentemente a fraude amigável na maioria dos estornos de e-commerce, e não numa minoria.
A fraude amigável é um problema de prevenção que se ganha depois da transação, na disputa. O comerciante que consegue mostrar que o próprio dispositivo do titular estava presente, e que a sessão se comportou como humana, tem provas de que uma alegação de "nunca fiz esta compra" é falsa. Essa prova precisa ser capturada durante o checkout e exportada num formato que as redes de cartões aceitem. A exportação de provas de estorno da cside foi construída exatamente para isso.
Tomada de conta no checkout
A tomada de conta (ATO) fica na interseção da fraude em pagamentos e da fraude de identidade. Em vez de usar um cartão roubado bruto, o atacante assume o controle da conta de um cliente legítimo, geralmente por credential stuffing, e paga com os cartões salvos já registrados. Isso é mais difícil de pegar porque a conta, o endereço e o meio de pagamento batem. A única coisa errada é quem está por trás do teclado.
A impressão de dispositivo é o principal sinal pré-autenticação aqui: um login ou checkout a partir de um dispositivo que nunca tocou nesta conta é a pista, mesmo quando todas as credenciais estão corretas. O caso de uso de tomada de conta aprofunda o padrão de credential stuffing que a alimenta.
As camadas da prevenção de fraude em pagamentos online
Nenhuma ferramenta única cobre toda a jornada. Uma arquitetura eficaz em 2026 combina várias, cada uma fechando uma janela diferente.
- Controles das redes de cartões e emissores. 3-D Secure (3DS2), as verificações de CVV e AVS e o monitoramento no nível da rede são a base. Eles transferem parte da responsabilidade e pegam a fraude óbvia, mas adicionam atrito e não conseguem ver a sessão do navegador.
- Pontuação de fraude nativa do PSP. Ferramentas como Stripe Radar ou Adyen RevenueProtect pontuam a transação com aprendizado de máquina. São genuinamente úteis e, na maioria, gratuitas em baixo volume, mas só veem o que o PSP vê: os sinais de navegador anteriores à autorização e a reutilização de dispositivos entre PSPs ficam fora de sua janela.
- Um motor de pontuação ou de regras. Uma plataforma dedicada ingere o histórico de transações e devolve uma decisão de aprovar/bloquear/desafiar. Essa é a sua camada de decisão, e ela é tão boa quanto os sinais que você lhe fornece.
- Uma fonte de sinais no nível do navegador. Essa é a camada que falta à maioria das arquiteturas. Ela roda na página de pagamento e captura os sinais de dispositivo, comportamento e rede que o registro da transação nunca carrega: impressão de dispositivo, marcações de automação e de agentes de IA, status de VPN e proxy e comportamento de sessão.
- Automação de disputas de estorno. Depois do fato, ela empacota as provas nos formatos exigidos pelas redes de cartões e apresenta a resposta. Sem boas provas capturadas, ela apenas automatiza a derrota.
O sentido das camadas é que a detecção anterior à transação reduz a sua taxa de fraude e de disputas, enquanto as provas posteriores à transação recuperam dinheiro que você perderia de outra forma. Investir apenas em automação de disputas recupera receita que você já perdeu; investir na camada de navegador trava a perda mais cedo e produz as provas de que a camada de disputas precisa.
Onde a cside se encaixa numa arquitetura de prevenção de fraude em pagamentos
A cside é a fonte de sinais no nível do navegador dessa lista. Ela é implantada como um único trecho de JavaScript de origem própria carregado a partir do seu próprio domínio, então não há domínio de coleta de terceiros que uma lista de filtros ou um atacante possa bloquear. Ela não fica na frente do seu tráfego e não é um proxy; ela lê a sessão de checkout e devolve um veredicto. Há três partes do problema de pagamento onde ela mais contribui.
Inteligência de dispositivo no checkout. A cside constrói uma impressão de dispositivo a partir de mais de 250 sinais de navegador, dispositivo e rede por sessão, e mantém essa identidade estável através do modo anônimo, das conexões VPN e da limpeza de cookies. É isso que torna a continuidade de dispositivo utilizável: você consegue distinguir um cartão usado no dispositivo conhecido do seu dono do mesmo cartão num dispositivo que você nunca viu. A solução de inteligência de dispositivo explica como a impressão é construída.
Detecção de card testing e automação. Como o trecho também lê canais comportamentais, a cside roda modelos separados para movimento do cursor, cadência de digitação e comportamento mais amplo na sessão, e depois combina seus veredictos. Ela marca sessões automatizadas e de agentes de IA, incluindo frameworks de automação como Playwright, Puppeteer e Selenium e navegadores agênticos como OpenAI Operator e Claude for Chrome. Uma rodada de carding conduzida por um deles é visível mesmo quando cada cobrança individual é pequena demais para acionar uma regra de velocidade.
Provas de estorno. O mesmo ID de impressão indexa a exportação de provas de estorno da cside, que empacota a prova no nível do dispositivo no formato Compelling Evidence 3.0 da Visa para as respostas a disputas. Quando uma disputa de fraude amigável chega, as provas que pontuaram a transação se tornam as provas que ganham a disputa, em vez de apodrecer num arquivo de log.
No celular, a cside roda o mesmo motor por meio de SDKs nativos de iOS e Android, atualmente em beta (acesso antecipado), que capturam o mesmo conjunto de sinais do cliente web mais sinais que só um aplicativo consegue ver. Fale com a equipe se a cobertura móvel estiver no seu escopo.
Duas coisas que a cside deliberadamente não é: não é uma plataforma de decisão (combine-a com o seu motor de pontuação ou de regras, que consome o veredicto dela como características adicionais), e não impede que um cartão seja roubado em primeiro lugar. O que ela faz é fechar a lacuna de provas entre a sessão de checkout e tudo o que vem depois.
Construindo o seu plano de prevenção
Se você está montando ou afinando uma arquitetura de prevenção de fraude em pagamentos online, trabalhe nesta ordem:
- Cubra a base. Confirme que 3DS2, CVV e AVS estão ativados e que a pontuação de fraude nativa do seu PSP está habilitada e ajustada. Isso é o mínimo e, na maioria, gratuito.
- Capture provas de navegador no checkout. Adicione a camada para a qual a sua plataforma de pontuação e o seu PSP são cegos, para que os sinais de dispositivo, automação, VPN e comportamento sejam registrados durante a sessão, não reconstruídos depois.
- Alimente os sinais na sua camada de decisão. Não substitua o seu motor de pontuação; passe os sinais de navegador a ele como características adicionais para que as decisões de aprovar/bloquear melhorem.
- Automatize as provas CE 3.0 para as disputas. Quando um estorno dispara, os sinais que pontuaram a transação devem fluir direto para a resposta da disputa no formato que as redes de cartões aceitam.
Para um olhar mais profundo sobre a lacuna de provas no checkout e por que os dados de sessão precisam ser capturados ao vivo, veja detecção de fraude em pagamentos: a lacuna de provas no checkout. Se você está escolhendo entre fornecedores, o melhor software de detecção de fraude em pagamentos em 2026 classifica as plataformas e mostra onde uma fonte no nível do navegador se combina com uma plataforma de pontuação.
