Detecção de fraude em pagamentos: onde os sinais de IP entram na sua stack

Pergunte a dez equipes de pagamentos o que impede a fraude e você ouvirá dez respostas únicas diferentes: regras, machine learning, 3-D Secure, revisão manual. A resposta honesta é uma stack. Toda defesa de pagamentos que funciona é em camadas, porque toda camada tem um ponto cego e os atacantes miram justamente na que você pulou. Este guia mapeia a stack de ponta a ponta e se concentra na camada que dispara primeiro e custa menos: a rede, geralmente condensada em uma pontuação de risco de IP de 0 a 100 sobre a qual você pode agir. Usada corretamente, a inteligência de IP elimina classes inteiras de ataque antes que elas cheguem ao seu processador de pagamentos e, discretamente, melhora todas as camadas que vêm depois.

O problema, dimensionado com honestidade

A fraude com cartões não está diminuindo. O Nilson Report estima as perdas mundiais com fraude de cartão em US$ 33,45 bilhões em 2022, com projeção de passar de US$ 43 bilhões até 2028, sendo as perdas nos EUA esmagadoramente um problema de cartão não presente (Nilson Report). E a assimetria de custo é brutal nas duas direções: cada US$ 1 de fraude custa US$ 4,61 aos varejistas e e-commerces dos EUA quando se contabilizam mão de obra, investigação e recuperação (The Paypers), enquanto o bloqueio excessivo de pedidos legítimos vaza receita em silêncio. Uma defesa de pagamentos precisa reduzir a fraude e as recusas indevidas ao mesmo tempo, e é exatamente para isso que servem os sistemas graduados e em camadas.

Conheça seu atacante: as quatro famílias de ataque a pagamentos

O catálogo de ameaças automatizadas da OWASP nomeia as versões industriais (OWASP Automated Threats):

A fraude amigável, em que o verdadeiro titular do cartão contesta uma compra genuína, fica fora desta tabela de propósito: nenhum sinal de rede a vê chegando, o que já é, por si só, uma lição sobre a stack.

A stack, camada por camada

1. Camada de rede (pré-autorização). Pontue o IP em todo checkout, atualização de cartão e tentativa de pagamento. É aqui que scripts de datacenter, sessões anonimizadas e origens de alta velocidade são filtrados antes de custarem qualquer coisa.
2. Camada de velocidade. Tentativas por IP, por prefixo /64, por cartão, por conta, por campanha. Contadores baratos pegam o que a reputação deixa passar.
3. Camada de dispositivo e comportamento. Fingerprints e comportamento de sessão reconhecem clientes recorrentes e identificam automação que sobreviveu ao filtro de rede. A divisão de trabalho é explicada em fingerprinting de dispositivo vs inteligência de IP.
4. Camada de autenticação do emissor. Autenticação baseada em risco do 3-D Secure, em que o emissor aprova sem atrito os pedidos de baixo risco e desafia o restante, e a responsabilidade pela fraude autenticada passa para o emissor (Visa sobre o 3-D Secure).
5. Camada de revisão e evidências. Filas de revisão manual para os casos genuinamente ambíguos e evidências registradas para as disputas que você vai enfrentar depois, como explicado em reduzir chargebacks com detecção de IP.

A ordem importa porque o custo aumenta com a profundidade. Uma consulta de IP leva milissegundos e custa frações de centavo. Um desafio 3-D Secure custa conversão. Uma revisão manual custa minutos de um analista humano. Um chargeback custa a mercadoria, as taxas e o seu índice de disputas. Todo ataque que você barra na camada um nunca gera cobrança na camada cinco.

O que a camada de IP contribui antes da autorização

Honestidade da infraestrutura. Clientes reais pagam a partir de conexões residenciais e móveis. Um checkout vindo de uma faixa de datacenter ou de hospedagem é automação até prova em contrário, e o tipo de conexão somado ao tipo de ASN é o filtro inicial mais barato que você pode rodar.

Anonimização na etapa de pagamento. Flags de VPN e proxy durante a navegação são, sozinhas, evidência fraca. As mesmas flags aparecendo especificamente na etapa de digitação do cartão, ou um nó de saída Tor no checkout, merecem atrito. A mecânica de detecção está em como funciona a detecção de VPN e proxy.

Consistência geográfica. Três países geralmente deveriam coincidir: a localização do IP, o país emissor do BIN do cartão e o endereço de entrega ou de cobrança. Uma divergência é um viajante ou uma VPN. Os três discordando em um primeiro pedido com entrega expressa é um padrão que vale a pena desafiar.

Velocidade indexada corretamente. O teste de cartão executa centenas de tentativas por origem. Indexe seus contadores pelo IP e, no caso de IPv6, pelo prefixo /64 em vez do endereço completo, ou um único grupo vai parecer milhares de usuários (limitar a taxa de IPv6 por /64).

Os amortecedores. O NAT de nível de operadora coloca milhares de clientes legítimos atrás de um único endereço, e 42% dos adultos dos EUA disseram usar VPN na pesquisa de agosto de 2026 da Security.org com 1.008 pessoas. Uma flag de CGNAT deveria suavizar sua resposta à velocidade de IP compartilhado, não endurecê-la.

Um nó de saída Tor e um relay do iCloud no mesmo checkout

A mesma pergunta sobre anonimização recebe respostas opostas dependendo do que o IP realmente é. Consultamos um nó de saída Tor e uma saída do iCloud Private Relay em 5 de outubro de 2026 (os resultados mudam à medida que as faixas se movem):

O nó de saída Tor tem pontuação 100 com recommended_action: "block", e detection_methods mostra por quê: tor_exit mais rdns_tor, vindo do seu DNS reverso, em infraestrutura de hospedagem. Essa é a faixa corroboradamente ruim que você barra antes da autorização. O relay tem pontuação 9 e allow, porque is_relay: true com relay_provider: "iCloud Private Relay" é um cliente Apple usando um recurso de privacidade nativo, não um proxy. Observe o país do lado do IP, Angola: uma saída de relay pode ficar longe do titular do cartão, então uma divergência entre o país do BIN e o do IP em um IP de relay é evidência fraca e não deveria, sozinha, empurrar o pedido para a faixa de bloqueio.

O teste de cartão merece um parágrafo próprio

O teste de cartão afeta cerca de um terço dos e-commerces no mundo (estatísticas de teste de cartão), e é o exemplo mais puro de um ataque que a camada de IP deveria simplesmente apagar. Os bots validam cartões roubados com pequenas autorizações, você paga as taxas de autorização e de recusa de qualquer forma, e cada cartão que eles validam vira fraude real em outro lugar. O perfil do tráfego é inconfundível: origens de datacenter e proxy, taxas de tentativa em velocidade de máquina, valores minúsculos ou zerados. Pontue o IP antes que a requisição chegue ao seu processador, limite a taxa por endereço e por prefixo, e rejeite discretamente ou isole em sandbox o que for reprovado. Barrar o teste de cartão na borda da rede é o controle de fraude de maior ROI que a maioria das equipes de pagamentos ainda não implantou por completo.

Alimente o emissor, não brigue com ele

O 3-D Secure não é rival da sua própria detecção; é uma camada que funciona à base de sinais. O emissor decide entre sem atrito e desafio com base no quadro de risco que consegue ver, e você decide quais pedidos enviar para esse fluxo. O padrão que funciona espelha os limiares de pontuação de risco por ação: aprove a faixa limpa sem atrito, encaminhe a faixa média para um desafio 3-D Secure para que a responsabilidade pela fraude autenticada passe para o emissor, e bloqueie a faixa corroboradamente ruim antes da autorização para que ela nunca afete sua taxa de aprovação. A inteligência de IP é o que separa essas faixas de forma barata e explicável.

O que a camada de IP não consegue ver

Seja preciso sobre os pontos cegos, porque eles definem o restante da stack. O IP não enxerga fraude amigável, em que o titular legítimo do cartão, na sua rede doméstica de sempre, contesta uma compra que ele mesmo fez. Não consegue sinalizar um cartão roubado usado a partir do próprio bairro da vítima. Não consegue distinguir dois clientes atrás de um único endereço CGNAT sem ajuda. Essas lacunas são o motivo pelo qual existem o reconhecimento de dispositivo, a autenticação do emissor e a revisão pós-transação, e o motivo pelo qual a pontuação de risco de IP foi projetada para ser um insumo explicável em uma decisão, e não a decisão em si.

Uma consulta por tentativa de pagamento

Uma consulta por tentativa de pagamento retorna o quadro pré-autorização: connection_type e asn_type separam clientes residenciais e móveis de scripts de datacenter e hospedagem; o bloco de detecção sinaliza saídas de VPN, proxy, Tor e relay com o proxy_type e o anonymity_level por trás de cada flag; o bloco geo fornece o país do lado do IP para as verificações de consistência com BIN e endereço, com um geo_confidence para você saber o quanto pode confiar nele; is_cgnat marca endereços compartilhados de operadora para que você amorteça em vez de recusar; e a pontuação de risco explicável de 0 a 100 chega com um recommended_action (allow, review, step-up ou block) que se encaixa diretamente nas faixas sem atrito, de desafio e de bloqueio do seu roteamento 3-D Secure. Todos os campos estão disponíveis no plano gratuito, com 1.500 consultas por dia, e você pode verificar a pontuação de risco de qualquer IP sem chave de API antes de integrá-la ao seu fluxo de pagamento.

Comece a stack de detecção de fraude em pagamentos pela rede

Este post é o mapa; os guias vizinhos são o terreno. Os números de limiar estão no guia de limiares por ação citado acima, a porta de segurança da conta é tratada em detectar tomada de conta e credential stuffing, o retorno do lado das disputas no guia de chargebacks da lista da stack, e a integração de dez minutos em adicionar detecção de fraude por IP com uma API gratuita. Construa a camada de rede primeiro. É a única camada que fica mais barata quanto mais cedo ela roda.

Perguntas frequentes

O que é detecção de fraude em pagamentos?

Detecção de fraude em pagamentos é o conjunto de verificações que uma empresa executa antes, durante e depois de uma transação para identificar pagamentos não autorizados ou enganosos: uso de cartão roubado, teste de cartão, tomada de conta no checkout e fraude amigável. Sistemas maduros são em camadas, não monolíticos. As verificações de rede e de IP rodam primeiro, os sinais de velocidade e de dispositivo corroboram, a autenticação do emissor, como o 3-D Secure, cuida da faixa de risco médio, e a revisão pós-transação junto com as evidências de chargeback fecham o ciclo.

Quais sinais de IP mais importam no checkout?

Quatro famílias fazem a maior parte do trabalho: tipo de conexão e tipo de ASN (um checkout de consumidor vindo de uma faixa de datacenter ou de hospedagem é um script até prova em contrário), flags de anonimização (VPN, proxy ou Tor na etapa de pagamento), consistência geográfica (país do IP versus país do BIN do cartão versus endereço de entrega) e velocidade indexada pelo IP e pelo seu prefixo IPv6 /64 (muitas tentativas de cartão a partir de uma mesma origem é teste de cartão). Cada uma precisa de contexto, já que NAT de nível de operadora e o uso comum de VPN são normais.

O que é teste de cartão e como impedi-lo?

Teste de cartão (OWASP OAT-001 Carding) são bots executando pequenas autorizações com números de cartão roubados em massa para descobrir quais cartões ainda estão ativos. Cada tentativa custa taxas de autorização para você, e cada sucesso depois vira fraude real em algum lugar. É o ataque a pagamentos mais solucionável pelo IP: os bots rodam a partir de faixas de datacenter e pools de proxies em taxas que nenhum humano alcança, então pontuar o IP e limitar a taxa por endereço e por prefixo /64 antes que a requisição chegue ao seu processador elimina a maior parte dele.

O 3-D Secure substitui a detecção de fraude?

Não. O 3-D Secure é uma camada de autenticação que transfere a responsabilidade pela fraude para o emissor do cartão nas transações autenticadas, e seu fluxo baseado em risco funciona melhor quando recebe sinais ricos. Desafie tudo e você perde conversões; não desafie nada e você fica com a responsabilidade. O padrão prático é usar sua própria pontuação de risco, incluindo inteligência de IP, para decidir quais transações encaminhar para um desafio 3-D Secure, quais aprovar sem atrito e quais bloquear antes mesmo da autorização.

Devo bloquear usuários de VPN no checkout?

Não automaticamente. Cerca de um em cada quatro usuários de internet usa VPN, na maioria das vezes por privacidade legítima, então um bloqueio rígido em qualquer flag de VPN rejeita receita real. Trate uma flag comum de VPN como motivo para adicionar verificação, por exemplo encaminhando o pedido para um desafio 3-D Secure, e reserve os bloqueios rígidos para casos corroborados, como nós de saída Tor ou IPs com histórico conhecido de abuso combinados com outros sinais de risco, como divergência geográfica ou alta velocidade.