Módulo 5 — Loja VTEX (useveggi.com.br)¶

Frente de antifraude e higiene de base da loja B2C. Ao contrário dos módulos 1 a 4, aqui não há workflow n8n: são um Cloudflare Worker no ar e dois conjuntos de scripts rodados manualmente pelo PowerShell na máquina da operação.

Por que este módulo existe¶

A loja useveggi.com.br sofre card testing desde julho/2026 — bots criam pedidos com cartões roubados só para descobrir quais ainda funcionam. Efeitos colaterais: taxa de recusa muito acima do normal, base da RD Station poluída com e-mails descartáveis e risco de entregabilidade nos disparos de e-mail.

O módulo ataca isso por três frentes independentes — nenhuma depende da outra:

Frente	Serve para	Onde fica
Validador de e-mail	Impedir cadastro novo com e-mail descartável no checkout	Cloudflare Worker + `checkout6-custom.js`
Blocklist de e-mail e CPF	Barrar uma pessoa já identificada, e não uma regra geral	Mesmo Worker + `.bat` na pasta do projeto
Aviso de espera no pagamento	Explicar ao cliente o bloqueio de 120s da VTEX, que é mudo	`checkout6-custom.js`
Higienização da base	Achar lixo na base já exportada da RD Station	`C:\Projetos\higienizacao-base`
Análise VTEX	Investigar o ataque, descobrir domínio novo, gerar relatório	`C:\Projetos\vtex-analise`
Análise profunda	33 campos por pedido — motivo da recusa, CPF, correlação	`C:\Projetos\vtex-analise`

Componentes¶

Componente	Tecnologia	Onde fica
Worker `veggi-validador-email`	Cloudflare Worker (JS, sem dependências)	`veggi-validador-email.veggiageral.workers.dev`
KV `CACHE`	Cloudflare KV	Cache de DNS por domínio (7 dias) + chave `blocklist`
Snippet do checkout	JavaScript	VTEX Admin → Loja → Checkout → Código → `checkout6-custom.js`
Scripts de análise	Python 3 + API VTEX	`C:\Projetos\vtex-analise`
Análise profunda (Node)	Node.js + API VTEX	`C:\Projetos\vtex-analise` (mesma pasta)
Higienizador da base	Python 3 (`detecta-bots.py`)	`C:\Projetos\higienizacao-base`
Núcleo de regras	Node.js (`validador-core.mjs`)	`C:\Projetos\vtex-analise\validador`

Como as três frentes se encaixam¶

                 Loja VTEX useveggi.com.br
                          │
        ┌─────────────────┼─────────────────┐
        │                 │                 │
   checkout            pedidos          base de leads
        │                 │                 │
        ▼                 ▼                 ▼
 Worker validador   API VTEX (OMS +    Exportação RD Station
 (bloqueia na       Pagamentos)              │
  entrada)               │                   ▼
        ▲                ▼            detecta-bots.py
        │          vigia-dominios.py   (lista o que apagar)
        │                │
        └─── domínio novo detectado ───┘
             (blocklist no KV, sem deploy)

O ciclo fechado é este: o vigia de domínios lê os pedidos negados na VTEX, descobre infraestrutura de ataque nova e imprime o comando pronto para acrescentá-la à blocklist do validador — que passa a barrar na entrada. A higienização limpa o que entrou antes de o validador existir.

Para operar no dia a dia

O roteiro clicável, sem PowerShell, está em Passo a Passo da Rotina.

Rotina recomendada¶

Frequência	O que rodar
Semanal	`vigia-dominios.py` — único item que vale colocar na rotina
Mensal / sob demanda	`mapa-mensal.py` para acompanhar a taxa de recusa
A cada exportação nova da RD (ou trimestral)	`detecta-bots.py`
A cada 2–3 meses	Atualizar `descartaveis.txt` com a lista pública

Referência de taxa de recusa

Taxa normal de e-commerce: 10% a 15%. Acima de 50% é ataque em curso.

Pendência conhecida¶

Os 3.796 leads reimportados em 05/03/2026, com dados de 2023 e 2024, nunca foram testados. Metade da base não converte desde 2023. Esse é o risco de entregabilidade real e nenhum validador detecta — só se descobre disparando e-mail em lotes controlados e colhendo os hard bounces. Ver Higienização da base.