Há uma coisa que aprendi a ver nos painéis de lojas online e que quase nunca aparece nos relatórios de marketing: encomendas que existem, mas não são vendas. Pequenos valores, nomes estranhos, emails que parecem gerados por computador, e um número de recusas do gateway de pagamento que na semana anterior era zero. Não é tráfego. Não é uma campanha mal segmentada. É alguém a usar o seu checkout como máquina de validação de cartões roubados.

O card testing é a forma mais barata de abuso a lojas online: o atacante compra uma lista de cartões no mercado negro — milhares, na maioria já mortos — e não sabe quais estão vivos. A solução é experimentá-las. E a forma mais rápida de experimentar um cartão é fazê-lo passar por um checkout verdadeiro, porque o gateway responde em segundos com um «aprovado» ou «recusado». O seu site passa a ser, sem saber, o serviço de validação de outra pessoa.

O ataque não é uma invasão. É uma experiência de compra

O que torna o problema difícil de aceitar: não há ficheiros alterados, nem portas abertas, nem nada de errado com o site. O atacante usa o formulário tal como foi desenhado. Preenche o checkout, submete o pagamento, recebe a resposta, escolhe o cartão seguinte. Se a encomenda passar, ele nem sequer quer o produto — muitas vezes o envio é para um endereço qualquer ou para um ponto de recolha. O objetivo era o teste, não a compra.

Numa loja pequena, cinquenta tentativas passam despercebidas. Numa loja com campanhas ativas em novembro, cinco mil em duas horas parecem «tráfego da Black Friday». É aí que o ataque se esconde: no meio do pico que todos esperavam.

Os sinais que aparecem antes da fatura

• Taxa de recusas a disparar. Se 20% das tentativas de pagamento falham durante uma hora, e o normal é 3%, não é o mercado. É volume artificial.
• Encomendas de valor mínimo. Muitos pedidos do produto mais barato, repetidos em minutos.
• Emails e nomes sem nexo. Padrões aleatórios, domínios descartáveis, nomes de uma palavra.
• Origem concentrada. Muitos pedidos de poucos endereços IP, quase sempre em datacenters (AWS, Hetzner, DigitalOcean) e não em redes móveis portuguesas.
• Velocidade impossível. Um humano demora 40 segundos a preencher um checkout. Um script demora 400 milissegundos. Vários pedidos no mesmo segundo é a assinatura mais óbvia.
• Falhas no 3-D Secure. Se ativou autenticação forte e vê tentativas a morrer nesse passo, alguém está a usar cartões que não são seus.

Porque é que novembro e dezembro são a época alta disto

Há duas razões, e nenhuma tem que ver com o seu negócio. A primeira é que as listas de cartões circulam mais nesta altura: há mais cartões ativos, mais gente a comprar, mais dados capturados em esquemas de phishing sazonais. A segunda é que os atacantes sabem que as lojas estão ocupadas a olhar para as vendas. Uma equipa que está a acompanhar o ROAS às 23h não está a olhar para o rácio de recusas do gateway. O ruído de fundo é maior, a atenção é menor — é a combinação perfeita.

E há um terceiro fator, o mais desconfortável: muitas lojas apertam a segurança em janeiro, depois do susto. Deviam apertá-la antes de precisarem dela.

O custo real não é o dos produtos. É o da conta de gateway

A primeira reação de um cliente é «essas encomendas não são pagas, logo não perco dinheiro». Errado, por três motivos que se somam.

• Taxas por transação recusada. Muitos contratos cobram por tentativa, não por venda. Mil recusas podem ser uma fatura real no fim do mês.
• Chargebacks. Quando os verdadeiros donos dos cartões contestam os débitos, cada contestação tem uma taxa fixa — e, acima de um certo limiar, o processador começa a olhar para si como cliente de risco.
• O risco de perder o direito de aceitar cartões. Um rácio de chargebacks acima de 1% pode levar o processador a retê-lo os fundos ou a encerrar a conta. Sem conta de gateway, uma loja online não vende.

É por isso que este não é um problema «de IT». É um problema de tesouraria com uma causa técnica.

Travar o ataque em duas semanas

A duas semanas da Black Friday, não vale a pena reescrever a loja. Vale a pena fechar as portas que estão a ser usadas. Por ordem de impacto:

• Limite de ritmo no checkout e nos endpoints de pagamento. No nginx, um limit_req por IP nas rotas ?wc-ajax= e nas chamadas à API da loja resolve a maior parte. Cinco pedidos por minuto por IP é generoso para um humano e impiedoso para um script.
• Bloqueie datacenters, não países. Bloquear Portugal inteiro é absurdo; bloquear ASNs de cloud no checkout apanha a maioria dos bots sem tocar em clientes reais. Se vende só em Portugal, uma regra geográfica no checkout é ainda mais eficaz.
• Autenticação forte no pagamento. O 3-D Secure obrigatório (SCA) transfere a validação para o banco emissor. Reduz conversão em alguns casos — mas uma conversão perdida custa menos do que um processo de chargebacks.
• CAPTCHA invisível no checkout e no login. Não o pesado, que se vê. O que corre em segundo plano e só pede prova quando desconfia.
• Proteja o wp-login.php e o xmlrpc.php. O credential stuffing anda de mãos dadas com o card testing: entram por uma conta, testam cartões noutra. Estes são os mesmos princípios que descrevi em segurança para lá do HTTPS, agora aplicados ao momento em que há dinheiro em jogo.

Se ainda não tem nada disto, comece pelo limite de ritmo. É a medida com melhor rácio entre esforço e resultado, e faz-se numa tarde.

Monitorizar vendas, não só o uptime

Um site pode estar de pé e o negócio estar a ser atacado. Isto é a mesma lição que tirei da forma como montamos monitorização de servidores: um HTTP 200 não diz que o negócio funciona. Acrescente duas métricas ao painel e ponha um alerta em cima de cada uma:

• Rácio de recusas de pagamento por hora. Alerta se passar o dobro da média das últimas duas semanas.
• Encomendas por hora, comparadas com o mesmo dia da semana anterior. Um pico não é só bom sinal; um pico com valor médio baixo é sinal de abuso.

Com estes dois números, descobre o problema em vinte minutos — não na fatura do mês seguinte.

Se já está a acontecer

Não desligue o checkout — isso dá a vitória a quem ataca e tira-lhe as vendas boas. Identifique o padrão no access log (IP, user agent, intervalo entre pedidos), bloqueie-o temporariamente, avise o gateway — têm interesse em ajudar antes de os chargebacks chegarem —, anule as encomendas fraudulentas sem capturar fundos e só depois afine as regras permanentes. Nada disto exige guardar dados de cartão — e não guarde. Tokens do gateway, sim; números de cartão no WordPress, nunca.

Em resumo

• O card testing usa o seu checkout como veículo, não como alvo — por isso não aparece em nenhum antivírus.
• O sinal está na taxa de recusas e no valor médio das encomendas, não no uptime.
• Novembro esconde o ataque no ruído do pico; a defesa tem de estar montada antes.
• Limite de ritmo, bloqueio de datacenters no checkout e SCA resolvem a maioria dos casos em dias, não em meses.
• O custo real mede-se em chargebacks e no risco de perder a conta de gateway — não no stock.

A Black Friday dura um fim de semana. As regras que a protegem deviam valer o ano inteiro. Se quer saber como está o seu checkout hoje — e não a 27 de novembro —, é uma conversa de meia hora.