Antifraude e-commerce 2026 — 3DS 2.2, chargeback e o programa VAMP Visa

Em abril de 2026, três fatos reorganizaram o stack antifraude do e-commerce brasileiro: Visa baixou o threshold do programa VAMP (Visa Acquirer Monitoring Program) para 1,5% de fraude/chargeback ratio em merchants classificados como "excessive", com fines de US$ 8 a US$ 10 por transação acima do limite; Mastercard manteve o Excessive Fraud Merchant (EFM) program com exceção explícita para merchants que processam mais de 10% do volume via 3DS, criando incentivo direto à autenticação; e PCI DSS 4.0.1 tornou-se enforcement plena, com requisitos 6.4.3 e 11.6.1 obrigatórios para qualquer página que toca dado de cartão. Para o empreendedor brasileiro, isso significa que rodar e-commerce sem 3DS 2.2 e sem motor antifraude pré-autorização deixou de ser opção defensável.

A tese contraintuitiva é esta: o objetivo do antifraude em 2026 não é evitar 100% da fraude — é manter o seu ratio de fraude abaixo do threshold VAMP enquanto preserva conversão. Merchant que zera fraude mas perde 20% de conversão por excesso de bloqueio acabou pior do que merchant com 0,4% de fraude e checkout fluído. A engenharia do antifraude moderna é otimização sob restrição, não eliminação. O liability shift de 3DS é a alavanca crítica — não porque elimina fraude, mas porque transfere o ônus para o emissor sem custar conversão na maioria das transações low-risk.

Quem trata antifraude como custo trata pagamento como commodity. Quem trata antifraude como produto trata pagamento como infraestrutura competitiva. A diferença em margem ao longo de 36 meses é da ordem de 1-2 pontos percentuais sobre faturamento bruto — o suficiente para virar lucro de um e-commerce médio.

Tabela canônica — stack antifraude por gateway em 2026

Fonte: documentação oficial dos provedores acessada em maio de 2026; tabelas comerciais públicas; e relatos de campo. Chargeback rate típico é benchmark observado, varia significativamente por vertical (eletrônicos: pior; SaaS B2B: melhor) e ticket médio. [FALTA EVIDÊNCIA] para números exatos por gateway que não publicam dados agregados.

Como funciona o stack antifraude moderno — quatro engrenagens

A primeira engrenagem é o device fingerprint capturado no checkout antes da submissão do cartão. Bibliotecas JavaScript do gateway (pagar.me-fingerprint.js, stripe.js, adyen.js) coletam centenas de sinais — canvas hash, fontes instaladas, resolução de tela, fuso horário, plugins ativos, fingerprint WebGL, navegador exato, eventos de digitação — e enviam para o gateway junto com o pedido. O motor antifraude correlaciona o fingerprint atual com histórico (já vi esse device? em quantos pedidos? em quantos chargebacks?) e gera score em milissegundos.

A segunda engrenagem é o motor de decisão pré-autorização. Antes de enviar a transação para o emissor (banco do cartão), o gateway aplica regras — combinação de score do modelo de ML, regras manuais configuradas pelo merchant (limites por país, por bin de cartão, por velocidade de compra do mesmo cliente, por valor) e listas (negras, brancas, watchlist). O resultado é uma decisão entre approve (segue para emissor sem 3DS), challenge (segue para 3DS 2.2 com desafio ao cliente), frictionless 3DS (segue para 3DS sem desafio, contando com risk-based authentication do emissor) ou decline (recusa antes mesmo de chegar ao emissor).

A terceira engrenagem é o 3DS 2.2 com liability shift. EMV 3-D Secure 2.2 é o padrão atual (documentação Cielo cobre boa parte do protocolo aplicado ao Brasil). O fluxo padrão tem o gateway iniciando autenticação com o emissor; o emissor responde com frictionless (autentica baseado em risk-based, sem desafio ao cliente) ou challenge (cliente recebe push no app do banco, SMS, OTP, ou biometria). Em transações autenticadas via 3DS 2.2 com ECI: 05 (Visa) ou ECI: 02 (Mastercard), o liability shift transfere o ônus de chargeback fraudulento para o emissor — quem disputa "não reconheço a compra" perde a disputa, e o merchant fica com o dinheiro.

A quarta engrenagem é a observabilidade pós-decisão e o retraining. Mensalmente, o motor antifraude reanalisa decisões versus desfecho real — quantos approve viraram chargeback (falso negativo), quantos decline eram boas vendas perdidas (falso positivo), qual o lift de 3DS vs aprovação direta em conversão. Esses dados retroalimentam o modelo de ML e ajustam regras. Em Pagar.me, parte desse loop é automática (modelo Stone retreina em batch); o merchant pode customizar regras manualmente no painel para ajustar à sua vertical.

Quem deve operar antifraude nativo do gateway versus standalone

Antifraude nativo do gateway (Pagar.me, Stripe Radar, Adyen RevenueProtect, Mercado Pago) faz sentido quando:

1. Volume mensal abaixo de R$ 500 mil — o custo embutido no MDR é menor que o custo de contratar ClearSale ou Konduto separadamente, e a integração é zero (já vem com o gateway).
2. Vertical horizontal (varejo geral, SaaS, serviços) sem padrão de fraude muito específico — modelos genéricos funcionam bem.
3. Time pequeno sem capacidade de analisar e ajustar regras de fraude manualmente — gateway aplica regras default razoáveis.
4. Migração de gateway é caso de uso aceitável — você quer trocar de gateway sem migrar simultaneamente o motor antifraude.

Standalone antifraude (ClearSale, Konduto, Cybersource, Sift, Forter) faz sentido quando:

1. Volume acima de R$ 5 milhões/mês e o lift de modelo custom-treinado para sua vertical justifica o custo unitário por análise.
2. Vertical com padrão de fraude específico — eletrônicos de alto valor, joalheria, criptomoedas, ingressos para evento, viagens — onde modelos genéricos falham em casos importantes.
3. Multi-gateway — você roda Pagar.me, Mercado Pago e Stripe em paralelo e quer motor antifraude unificado decidindo antes do gateway.
4. Equipe de fraude dedicada que consegue iterar regras semanalmente, analisar falsos positivos individualmente e treinar o modelo com feedback de campo.

O erro mais comum é contratar ClearSale ou Konduto quando o volume não justifica e o time não tem competência para iterar. O motor standalone vira commodity de revisão tardia que não evita fraude porque chega depois da decisão crítica. O motor embutido decide pré-autorização, e isso é o que conta.

Developer Experience — como ativar 3DS 2.2 em Pagar.me

A integração 3DS 2.2 em Pagar.me v5 acontece via flag no payload do payment. O fluxo é: (1) merchant envia POST /core/v5/orders com authentication: { type: "threed_secure", threed_secure: { mpi: "pagarme" } } no objeto credit_card; (2) Pagar.me inicia o protocolo com o emissor; (3) se frictionless, o pedido é aprovado direto com eci: 05 ou 02; (4) se challenge, a resposta inclui URL para redirect do cliente ao app do banco ou OTP; (5) após desafio, o cliente é redirecionado para a URL de retorno configurada; (6) pedido é finalizado com liability shift garantido.

POST /core/v5/orders
{
  "items": [
    { "amount": 89990, "description": "Tênis premium", "quantity": 1 }
  ],
  "customer": {
    "name": "Comprador",
    "email": "cliente@exemplo.com",
    "document": "12345678909",
    "type": "individual",
    "phones": { "mobile_phone": { "country_code": "55", "area_code": "11", "number": "999998888" } }
  },
  "payments": [
    {
      "payment_method": "credit_card",
      "credit_card": {
        "operation_type": "auth_and_capture",
        "installments": 3,
        "statement_descriptor": "LOJAEXEMPLO",
        "authentication": {
          "type": "threed_secure",
          "threed_secure": {
            "mpi": "pagarme",
            "success_url": "https://lojaexemplo.com.br/checkout/3ds-callback"
          }
        },
        "card": {
          "number": "4000000000000010",
          "holder_name": "COMPRADOR EXEMPLO",
          "exp_month": 12,
          "exp_year": 2030,
          "cvv": "123",
          "billing_address": {
            "line_1": "Rua Exemplo, 100",
            "zip_code": "01310000",
            "city": "Sao Paulo",
            "state": "SP",
            "country": "BR"
          }
        }
      }
    }
  ]
}

Cinco pontos críticos: (a) billing_address completo melhora score 3DS (emissor usa para risk-based authentication); (b) phones.mobile_phone permite OTP por SMS no fluxo challenge; (c) success_url é onde o cliente volta após challenge; (d) statement_descriptor aparece na fatura do cartão e reduz chargeback "não reconheço" — sempre populado com nome legível do merchant; (e) email e document (CPF) preenchidos batem com cadastro do emissor e contribuem para frictionless.

Compliance, programa VAMP e PCI DSS 4.0.1

O programa VAMP da Visa entrou em vigor em outubro de 2025 com threshold inicial mais permissivo, e em abril de 2026 baixou para 1,5% — significando que merchants com ratio combinado (fraude + chargeback) acima de 1,5% são classificados como "excessive" e sofrem fines de US$ 8-10 por transação até regularização. Mastercard manteve o Excessive Fraud Merchant (EFM) program com exceção crítica: merchants que autenticam mais de 10% do volume via 3DS são exemptos do programa em mercados não-regulados (sentido americano; no Brasil, recomenda-se >25% via 3DS para margem de segurança). A política Stone e do Pagar.me como subadquirente é monitorar ratio por merchant e elevar tickets de fricção em caso de aproximação do threshold.

PCI DSS 4.0.1, vigente desde 31 de março de 2025 com enforcement plena em 2026, adiciona dois requisitos críticos para e-commerce: 6.4.3 (inventário e validação de integridade de todo script de página de pagamento) e 11.6.1 (monitoramento de tampering em página de pagamento). A consequência operacional é que qualquer script third-party (Google Tag Manager, pixels, chatbots) na mesma página onde o cartão é digitado precisa ser inventariado, auditado e monitorado. A solução estrutural é usar iframe ou checkout transparente do gateway (Pagar.me Checkout, Stripe Elements, Adyen Drop-in), que tira o cartão do escopo da sua página e reduz auditoria de SAQ D para SAQ A.

LGPD pós-Lei 15.352/2026 adiciona camada. Antifraude trata dado pessoal (CPF, endereço, dados de cartão tokenizado, device fingerprint) sob base legal "legítimo interesse" combinada com "execução de contrato" — base que precisa estar formalizada em política de privacidade visível no checkout. ANPD aplicou primeira multa relevante em 2024 e em 2025-2026 escalou cadência. Multas chegam a 2% do faturamento limitadas a R$ 50 milhões. Merchant que não tem política de privacidade clara sobre antifraude opera em risco.

Detalhes operacionais em KYC e KYB de merchants, webhook idempotência e segurança em conta PJ.

Próximo passo

Para montar stack antifraude em 2026, o caminho prático em 6 etapas é: (1) ativar 3DS 2.2 no gateway escolhido com fluxo de fallback configurado; (2) ativar antifraude embutido em modo agressivo, depois ajustar; (3) instrumentar device fingerprint no checkout; (4) configurar regras manuais baseadas em vertical (limite por país, por valor, por velocidade); (5) montar dashboard de chargeback ratio mensal e alerta em 1,2% (margem do VAMP); (6) revisar política de privacidade para cobrir antifraude e tratamento de dado pessoal.

Para entender o gateway Pagar.me em detalhe, Pagar.me overview. Para webhook idempotente que captura eventos de chargeback, webhook idempotência. Para KYC e KYB de merchants em marketplace, KYC KYB merchants.

Perguntas frequentes

O que é exatamente o liability shift de 3DS 2.2?

Liability shift é a transferência regulatória do ônus financeiro de chargeback fraudulento do merchant para o emissor (banco do cartão). Quando uma transação é autenticada via 3DS 2.2 com ECI apropriado (05 para Visa, 02 para Mastercard, equivalentes para Amex e Elo), o emissor declara que a autenticação foi realizada — desafio resolvido pelo cliente real, ou risk-based authentication aprovou. Se o portador do cartão disputar a transação como "não reconheço", a disputa é negada e o merchant fica com o dinheiro. Sem 3DS, a disputa é tipicamente aceita e o merchant perde o valor. Em verticais de alto risco (eletrônicos, viagens, ingressos), liability shift é a única defesa robusta contra fraude card-not-present.

Posso ativar 3DS só em transações de alto valor?

Sim, e é a estratégia recomendada para a maioria das verticais. O motor antifraude do Pagar.me, Stripe e Adyen aplica 3DS dinamicamente — frictionless por padrão (quase invisível para o cliente), challenge apenas para transações de alto score de risco. Você pode customizar via regra manual: aplicar 3DS challenge sempre que amount > 50000 (R$ 500), ou para BINs de cartão histórico de fraude, ou para clientes novos em primeira compra. O trade-off é conversão: cada challenge custa 5-12% de abandono dependendo do fluxo. A regra ouro é challengear quando o ganho em liability shift supera a perda em conversão.

Qual a diferença entre antifraude embutido e standalone?

Embutido (Pagar.me, Stripe Radar, Adyen RevenueProtect, Mercado Pago) significa que o motor antifraude opera dentro do gateway, decide pré-autorização e tem acesso nativo aos dados da transação. Custo é embutido no MDR ou cobrado por transação em alguns casos. Standalone (ClearSale, Konduto, Cybersource, Sift) significa um motor separado que recebe os dados via API antes do gateway, decide, e o merchant repassa decisão ao gateway. Custo é por análise, tipicamente R$ 0,30-1,20. Standalone faz sentido para volume alto e modelos custom; embutido faz sentido para PME e startups.

Mercado Pago tem 3DS 2.2?

Sim. Mercado Pago suporta 3DS 2.x em transações de cartão de crédito desde 2023 e ampliou cobertura ao longo de 2024-2025. O fluxo de integração está documentado em mercadopago.com.br/developers. A decisão de aplicar 3DS é tipicamente automática (motor antifraude decide), com possibilidade de forçar via flag. Em comparativo direto com Pagar.me, o flow é equivalente em capabilities; a diferença prática é tooling de monitoramento — Pagar.me historicamente expõe métricas mais granulares no painel para PME que quer entender taxa de aprovação por método.

O que acontece se eu ultrapassar o threshold VAMP?

O acquirer (subadquirente Pagar.me, no caso da Stone) recebe notificação da Visa e começa a aplicar fines de US$ 8-10 por transação acima do limite, repassadas ao merchant. O acquirer também aumenta monitoramento, exige plano de remediação e pode escalonar para suspensão de processamento Visa se a regularização não acontecer em 6-12 meses. O custo agregado de operar acima do threshold por 3 meses pode chegar a centenas de milhares de reais em fines, sem contar perda de relacionamento com o adquirente. A prevenção é o único caminho economicamente racional: monitorar ratio mensalmente e agir antes de chegar a 1,5%.

3DS reduz conversão? Quanto?

Depende do flow do emissor. 3DS 2.2 frictionless é praticamente invisível — o cliente nem percebe que aconteceu (risk-based authentication do emissor aprovou sem desafio), conversão fica praticamente igual à transação não-3DS. 3DS 2.2 challenge custa 5-12% de abandono médio dependendo do canal (push no app é melhor, OTP por SMS é pior) e do segmento. A regra prática em 2026 é configurar antifraude para usar frictionless em 80-90% das transações e challenge apenas em alto risco — neste cenário, o impacto agregado em conversão fica abaixo de 2% enquanto o liability shift cobre 95%+ das tentativas de chargeback fraudulento.

Stone não patrocina este conteúdo. Para Pagar.me em detalhe, pagar.me. Para split de pagamento que opera sobre transações com antifraude, split de pagamento. Para o hub completo, vender e receber 2026.