A maioria dos guias sobre Compelling Evidence 3.0 para nas regras de qualificacao: combinar dois de quatro elementos de dados em tres transacoes, garantir que um seja IP ou device ID e submeter sob o codigo de motivo 10.4. Se esses criterios forem atendidos, a transferencia de responsabilidade e automatica.
Mas nem toda disputa por fraude se qualifica para CE 3.0. Quando nao se qualifica, voce volta ao representment padrao, onde a evidencia apresentada e de fato avaliada. Este artigo cobre os quatro elementos de dados que a Visa exige para CE 3.0 e percorre seis pontos de evidencia adicionais que importam para as disputas que CE 3.0 nao cobre.
A regra, de forma compacta
CE 3.0 se aplica a disputas Visa de cartao nao presente sob o codigo de motivo 10.4 ("Other Fraud: Card-Absent Environment"). O comerciante deve apresentar duas transacoes anteriores nao disputadas nas mesmas credenciais de pagamento, cada uma com 120 a 365 dias de antiguidade em relacao a data da disputa. Pelo menos dois de quatro elementos de dados principais (User ID, endereco de envio, endereco IP ou device ID) devem corresponder nas tres transacoes, e um dos dois deve ser endereco IP ou device ID.
Fonte: Documento de preparacao de comerciantes Visa Compelling Evidence 3.0.
Os quatro elementos de dados que a Visa exige
A qualificacao CE 3.0 exige que pelo menos dois de quatro elementos de dados correspondam nas tres transacoes (a disputada e as duas anteriores nao disputadas). Um dos dois deve ser endereco IP ou device ID.
- Correspondencia de User ID. Qualquer identificador que o comerciante use para a conta do portador. Deve ser consistente nas tres transacoes.
- Correspondencia de endereco de envio. Endereco de entrega nas tres transacoes. Diferencas menores (numeros de apartamento, pontuacao) podem ser problematicas; a maioria dos adquirentes exige correspondencia exata.
- Correspondencia de endereco IP. IP capturado no momento da compra para as tres transacoes. Correspondencia a nivel de ISP e aceitavel para a maioria dos emissores; endereco exato e mais forte.
- Correspondencia de device ID. Impressao digital do dispositivo capturada no checkout nas tres transacoes. Deve ser produzida pela mesma fonte para ser tratada como deterministica. Um browser fingerprint combina dezenas de sinais nao sensiveis (resolucao de tela, fuso horario, configuracoes de idioma) em um hash estavel que persiste entre sessoes, modo anonimo e armazenamento limpo.
Um quinto campo, o numero de conta principal (PAN), e a base. O mesmo PAN nas tres transacoes e um pre-requisito, nao um dos quatro elementos a comparar. PANs tokenizados contam se a referencia do token for estavel entre sessoes.
Alem do CE 3.0: seis pontos de evidencia para disputas que nao se qualificam
Se a disputa atende aos criterios do CE 3.0, a transferencia de responsabilidade e automatica. Nada alem dos quatro elementos de dados exigidos e necessario para vencer.
Mas nem toda disputa por fraude se qualifica para CE 3.0. O codigo de motivo pode nao ser 10.4, pode nao haver duas transacoes anteriores nao disputadas na janela de 120 a 365 dias, ou os elementos de dados podem nao corresponder com precisao suficiente. Para esses casos, voce volta ao representment padrao, onde o emissor avalia a evidencia e toma uma decisao. Estes seis pontos de evidencia fazem a diferenca nesse processo:
- Consistencia do descriptor first-6. Os seis primeiros caracteres do descriptor de cobranca devem ser identicos para que o adquirente os trate como o mesmo comerciante. A variacao do descriptor entre cobracas iniciais e recorrentes e uma das razoes mais comuns de falha na qualificacao CE 3.0, e tambem enfraquece o representment padrao.
- Registro de autenticacao. Visa Secure ou Visa Data Only associado a transacao. No representment padrao, isso demonstra que o portador se autenticou, o que enfraquece a reclamacao de fraude. Em contexto CE 3.0, pode acionar a autoqualificacao.
- Confirmacao de entrega ou cumprimento. Para bens fisicos, um numero de rastreamento e prova de entrega assinada. Para bens digitais, uma sessao com correspondencia de IP mostrando acesso ao conteudo. Esta e evidencia padrao de representment que contradiz diretamente "nao recebi isso".
- Padrao temporal de transacoes anteriores. Um historico de transacoes que mostra uma relacao plausivel com o cliente, nao duas compras agrupadas artificialmente. No representment padrao, isso estabelece o padrao de uso legitimo do portador.
- Sinais de continuidade de sessao. Evidencia de que a mesma sessao de navegador ou dispositivo foi usada para navegar, adicionar ao carrinho e completar o pagamento. Isso vincula a transacao a uma sessao de usuario real em vez de um unico ponto de dados no checkout. O device fingerprinting projetado para CE 3.0 pode produzir esse tipo de continuidade a nivel de sessao nativamente.
- Perfil de disputas do comerciante. Um comerciante com historico de disputas limpo recebe o beneficio da duvida no representment padrao. Um comerciante com longo historico de casos revertidos enfrenta escrutinio mais severo mesmo com evidencia solida.
De onde vem cada ponto de evidencia
User ID e endereco de envio vem do banco de dados de pedidos. Descriptor de cobranca e autenticacao vem do processador de pagamentos e da configuracao 3DS. Endereco IP e device ID (os dois que determinam se voce se qualifica para CE 3.0) vem da sessao de checkout, e a maioria dos comerciantes nao os captura de forma confiavel.
Elementos exigidos pela Visa:
| Elemento de dados | Fonte | Geralmente capturado no momento do representment? |
|---|---|---|
| PAN (pre-requisito) | DB de pedidos / processador de pagamentos | Sim |
| User ID | DB de pedidos | Sim |
| Endereco de envio | DB de pedidos | Sim |
| Endereco IP | Sessao de checkout | As vezes (inconsistente) |
| Device ID | Sessao de checkout | Raramente (requer instrumentacao) |
Pontos de evidencia adicionais:
| Ponto de evidencia | Fonte | Geralmente capturado no momento do representment? |
|---|---|---|
| Descriptor first-6 | Configuracao do processador de pagamentos | Sim |
| Registro de autenticacao | Fluxo 3DS | Sim onde 3DS ativo |
| Cumprimento / entrega | OMS / transportadora | Sim |
| Padrao temporal de transacoes | DB de pedidos + ferramenta de resposta a disputas | Sim |
| Continuidade de sessao | Sessao de checkout | Raramente (requer instrumentacao) |
| Perfil de disputas | Adquirente | Implicito |
Endereco IP e device ID sao onde a maioria dos casos de representment falha por merito. Sao dados da sessao de checkout, nao do banco de dados de pedidos. Uma ferramenta de chargeback server-side nao consegue reconstrui-los apos o fato. Se a instrumentacao nao estava presente no momento da compra, os dados simplesmente nao existem.
O requisito de evidencia na camada do navegador
Device ID e IP no padrao de qualificacao CE 3.0 significam a mesma assinatura de dispositivo e rede nas transacoes anteriores e na disputada. Essa assinatura e capturada no checkout, no navegador, no momento em que o portador submete o pagamento. Nenhum sistema post-hoc pode produzi-la.
O produto Chargeback Evidence da cside captura os dados da camada do navegador no checkout. A identidade do dispositivo e estavel entre sessoes no mesmo comerciante, o que permite que uma transacao anterior de oito meses atras seja combinada deterministicamente com uma transacao disputada hoje. O IP capturado e o IP que o portador realmente usou na compra, nao um IP inferido posteriormente.
Para o pacote de evidencia como um todo, a captura na camada do navegador preenche os dois campos obrigatorios que ferramentas server-side nao conseguem (endereco IP e device ID) e reforca a confirmacao de entrega ao vincular o acesso de cumprimento ao mesmo dispositivo. O pacote apresentado ao emissor se le como uma cadeia de evidencia completa em vez de uma montagem de documentos.
O que isso significa operacionalmente
Comece auditando se suas disputas podem se qualificar para CE 3.0. Se os quatro elementos de dados exigidos correspondem, a transferencia de responsabilidade e automatica e voce nao precisa construir um caso mais amplo. A correcao de maior impacto e garantir que voce realmente consiga capturar IP e device ID no checkout para que mais disputas se qualifiquem.
Para disputas que ficam fora do CE 3.0, audite os seis pontos de evidencia complementares. As correcoes mais baratas sao alinhamento do descriptor first-6 e cobertura 3DS. A mais impactante e a captura de evidencia na camada do navegador, que fornece dados a nivel de sessao para apoiar o representment padrao.
Uma auditoria de trinta minutos:
- Extraia dez disputas recentes com codigo de motivo 10.4. Para cada uma, verifique se voce tinha os quatro elementos de dados exigidos pela Visa disponiveis. Quantas poderiam ter se qualificado para CE 3.0 mas nao se qualificaram porque IP ou device ID estava faltando?
- Para as que nao se qualificaram, verifique quais dos seis pontos de evidencia complementares voce poderia ter apresentado em um representment padrao. O padrao geralmente e claro: device ID e IP estao ambos ausentes ou de baixa qualidade, e o descriptor first-6 varia entre ciclos de cobranca.
- Compare sua taxa de vitoria em disputas qualificadas para CE 3.0 (que deveria ser proxima de 100%) com sua taxa de representment padrao. A diferenca indica quanto de receita esta em jogo nas disputas que CE 3.0 nao cobre.
O Relatorio Global de Fraude e Pagamentos 2025 do Merchant Risk Council constatou que a maioria dos comerciantes pesquisados ja usa o programa Compelling Evidence. Os comerciantes no topo dessa coorte sao os que instrumentaram a camada do navegador, qualificando mais disputas para CE 3.0 desde o inicio. Os comerciantes na base estao sem IP e device ID, o que significa menos vitorias automaticas e representments padrao mais fracos.
Erros comuns
Os tres erros mais comuns do CE 3.0 sao variacao do descriptor entre ciclos de cobranca, depender de captura de IP server-side (que frequentemente reflete o load balancer em vez do cliente) e tratar device fingerprints como oportunistas. Cada um desses pode impedir que uma disputa se qualifique para CE 3.0 em primeiro lugar, e cada um enfraquece sua posicao no representment padrao tambem.
Variacao do descriptor. Processadores de pagamento as vezes reescrevem descriptors entre transacoes iniciais e recorrentes, ou os variam por moeda. Mesmo uma mudanca de um caractere nos seis primeiros quebra a qualificacao.
Captura de IP server-side. Muitos comerciantes registram IP a partir do servidor que recebe o POST do checkout, que em arquiteturas modernas frequentemente registra um load balancer ou edge CDN em vez do cliente. O IP deve ser capturado client-side na camada do navegador para corresponder de forma confiavel.
Device fingerprints oportunistas. Um device fingerprint capturado por um script de terceiros que carrega no checkout nao e a mesma coisa que um fingerprint deterministico de sessao de checkout. Se o comerciante nao consegue reproduzir a logica de fingerprinting sob demanda, o emissor pode descontar a correspondencia.
Mais leituras na cside
Sobre o autor
Mike Kutlu e Head of GTM na cside, onde trabalha com lideres de pagamentos, risco e financas na instrumentacao de evidencia de chargeback da camada do navegador para representment com Compelling Evidence 3.0. Ele escreve sobre VAMP, friendly fraud e a mecanica da evidencia de disputas para comerciantes enterprise.
