Card testing: o que realmente acontece no seu checkout antes de chegar a primeira contestação
Um pico de recusas que ainda não é uma contestação
Numa manhã, o seu painel de pagamentos mostra algo estranho: dezenas de novos cadastros na última hora, cada um adicionando um cartão e tentando uma cobrança pequena, a maioria recusada. Ninguém ligou para reclamar. Nenhuma contestação chegou. Se verificar na semana seguinte, pode ainda não haver nenhuma. É tentador ler isso como nada, um problema de bots para a caixa de suporte em vez de um problema de pagamentos para a sua conta de comerciante. Essa leitura está errada, e quando produzir uma contestação que você possa apontar, o dano que realmente importa já terá ocorrido em outro lugar.
O que você está vendo é card testing: alguém passa um lote de números de cartão roubados ou adivinhados pelo seu checkout, ou pelo seu formulário de "adicionar cartão", para descobrir quais ainda funcionam. O seu site não é o alvo. É a ferramenta. O fraudador não quer nada do que você vende; quer que o seu formulário de pagamento lhe diga, de graça, qual dos números de uma lista que comprou é um cartão vivo e qual é plástico morto.
Isso importa especialmente para quem administra um diretório de anúncios adultos, porque os conselhos escritos para comerciantes online geralmente assumem um varejista comum com um processador comum. A sua conta quase certamente passa por um gateway de alto risco, com seus próprios termos de reserva e sua própria tolerância, mais estreita, exatamente para o tipo de pico de recusas que um ataque de testing produz. O mecanismo é o mesmo em todo lugar; o que ele custa, não é.
Este texto trata desse mecanismo: como o testing funciona, o que realmente custa antes de existir uma única contestação, por que uma conta de alto risco absorve o mesmo ataque pior do que uma conta padrão, e o que mudar no seu checkout esta semana em vez de depois do próximo ataque.
Nada disso exige que você se torne um analista antifraude. Exige saber o que o pico no seu painel realmente é, para parar de tratá-lo como ruído de fundo.
O que o card testing realmente é, e por que um checkout como o seu é conveniente
Um fraudador que compra ou coleta um lote de números de cartão tem um problema antes mesmo de ter uma oportunidade: a maioria desses números já está morta, cancelada ou denunciada. Testá-los um por um com uma compra real seria lento e queimaria comerciantes legítimos rapidamente, porque uma compra recusada é o tipo de coisa que um titular nota e um banco sinaliza. Então o fraudador procura uma forma mais barata e mais silenciosa de fazer a mesma pergunta: este cartão ainda está vivo.
A forma silenciosa é vincular um cartão a uma conta, ou executar uma verificação de autorização, em vez de concluir uma compra. A própria documentação da Stripe diz que os fraudadores preferem esse caminho porque as verificações envolvidas normalmente não aparecem na fatura do titular, então o titular real não tem um motivo evidente para notar e denunciar nada. Quando esse caminho não está disponível, uma compra pequena, um dólar ou dois, é o recurso alternativo, escolhido porque ainda é pequena o suficiente para passar despercebida numa fatura cheia de cobranças reais.
De qualquer forma, o pedido precisa chegar a algum lugar, e um script não se importa com o que esse lugar vende. Importa-se se o formulário é fácil de alcançar e se algo se interpõe entre um número de cartão enviado e uma resposta. Um fluxo de cadastro que deixa um visitante criar uma conta e vincular um cartão sem uma barreira de login, um CAPTCHA, ou um limite de quantas tentativas um visitante pode fazer, é exatamente esse tipo de formulário, seja qual for o negócio por trás dele.
O guia da J.P. Morgan para comerciantes sobre esses ataques torna explícito o padrão de escolha do alvo: os fraudadores procuram comerciantes não equipados para detectar ou se defender do ataque, usando-os muitas vezes como o que o guia chama de mula, um alvo intermediário usado apenas para descobrir se uma conta ainda está ativa. Um operador de anúncios pequeno ou médio com um checkout mínimo, frequentemente num gateway de alto risco mais barato que não inclui o CAPTCHA e as defesas de aprendizado de máquina que uma plataforma como a Stripe oferece por padrão, se encaixa nessa descrição mais do que um grande varejista, não pelo que o site trata, mas pelo que pode se dar ao luxo de construir.
O resultado é uma forma de fraude que não tem nada a ver com os seus anúncios, a sua moderação, ou a honestidade dos seus anunciantes, e tudo a ver com o quão exposto está o seu fluxo de entrada de cartão a um script que não tem outro lugar mais produtivo para ir.
O que isso custa antes de alguém contestar qualquer coisa
O instinto de esperar por uma contestação antes de tratar isso como um problema é compreensível, e é o instinto errado. O guia da J.P. Morgan diz isso claramente: não confie no processo de contestação para identificar um ataque de card testing, porque a janela entre uma transação e uma disputa é longa o suficiente para que um site seja atingido repetidamente antes que alguém perceba que há um problema. Quando a primeira contestação chega, o ataque que a causou pode já ter terminado, e um segundo pode já estar em andamento.
O custo que chega primeiro não é uma contestação, é uma taxa. Cada pedido de autorização que o seu gateway envia às redes de cartões em seu nome, aprovado ou recusado, é uma transação que o seu adquirente processa e normalmente cobra. Um script de testing que dispara centenas de tentativas numa hora não custa em vendas perdidas; custa em tráfego de autorização que você paga independentemente do resultado, além de qualquer taxa fixa ou percentual que o seu processador já cobra por ser uma conta de alto risco.
O segundo custo é reputacional num sentido muito literal e mecânico: a Stripe descreve um pico de recusas como algo que pode, por si só, prejudicar como os emissores de cartões e as redes leem o seu negócio, fazendo com que cada uma das suas transações pareça mais arriscada mesmo depois que o ataque termina, o que pode significar que cartões de clientes legítimos comecem a ser recusados também. As orientações da Checkout.com dizem o mesmo do lado do adquirente: uma alta taxa de recusas sinaliza risco para quem decide quão de perto observar a sua conta, independentemente de essas recusas chegarem a se tornar uma contestação.
O terceiro custo é o que eventualmente aparece de fato como uma contestação. Uma parte de um ataque de testing tem sucesso, porque alguns dos números são cartões vivos vinculados a pessoas reais. Essas pequenas cobranças bem-sucedidas são exatamente as que um titular eventualmente nota numa fatura e denuncia como fraude, transformando-se nas contestações que você esperava como primeiro sinal. Para ver como essas disputas pesam sobre a sua conta uma vez que chegam, veja o que realmente decide a taxa de contestações de um diretório de anúncios: o ataque de testing é muitas vezes o primeiro ato silencioso de um problema que você só encontra mais tarde nessa forma.
Por que uma conta de alto risco absorve pior o mesmo ataque
Os programas em nível de rede que observam as taxas de disputas e fraude não são a primeira linha de defesa na qual o seu processador se apoia. Abaixo deles está o limite interno do seu próprio adquirente, mais estreito, aquele que ele mesmo define precisamente porque responde à rede se toda a sua carteira de comerciantes se aproximar demais da linha. Quando uma conta cruzaria oficialmente um limite publicado por uma rede de cartões, o adquirente geralmente já agiu sobre o seu próprio número, mais baixo e privado, muitas vezes com um aumento de reserva ou uma revisão manual em vez de um aviso formal nomeando o programa.
Para uma conta de comerciante de alto risco, esse limite privado e antecipado já é aquele sob o qual você vive todos os dias; é por isso que a conta carrega preços de alto risco e um termo de reserva que uma conta de comerciante comum não tem. Um fim de semana de recusas por card testing não precisa tocar nenhum número que uma rede de cartões jamais publique para produzir uma resposta: precisa apenas mover o número que o seu próprio adquirente já observa mais de perto do que observa uma conta comum, o que é por definição uma barra mais baixa de superar.
A própria reserva agrava o problema em vez de apenas refleti-lo. Um processador que reage a um pico de recusas retendo uma parcela maior da receita, ou retendo-a por mais tempo, está retirando capital de giro de um negócio que já paga mais do que um comerciante comum para processar o mesmo volume. Esse é dinheiro que você não pode gastar nas ferramentas antifraude que teriam impedido o próximo ataque, exatamente a armadilha em que um operador de alto risco magro e com pouca liquidez mais facilmente cai.
Nada disso significa que a sua conta seja fragilizada pelo que você vende. Significa que o adquirente já estava observando os seus números mais de perto antes mesmo de a primeira transação de teste atingir o seu checkout, e um ataque de testing é uma das formas mais rápidas de mover um número que ele está observando.
O que verificar e mudar esta semana
Comece por descobrir se você perceberia. Extraia a sua taxa de recusas do último mês e procure um padrão que a J.P. Morgan sinaliza diretamente: um grupo de contas novas, criadas numa janela curta, cada uma adicionando um cartão ou tentando uma cobrança de baixo valor que é recusada, muitas vezes a partir de uma faixa estreita de endereços IP ou dispositivos. Se o seu painel não torna esse padrão visível num piscar de olhos, essa já é a constatação: você atualmente depende de uma contestação, semanas depois, para lhe dizer algo que o seu registro de recusas já sabe hoje.
Reembolse imediatamente, não espere. Se alguma das transações de teste teve sucesso, reembolsá-la assim que você identificar o padrão, em vez de esperar para ver se o titular percebe, é a coisa mais barata que você pode fazer, e é também o primeiro passo na lista de verificação oficial da Stripe contra o card testing. Um reembolso que você mesmo inicia conta de forma muito diferente de uma disputa aberta pelo titular: a cobrança nunca se torna uma contestação, então nunca chega a pesar em como as disputas realmente se resolvem na sua taxa.
Ative os controles que já existem. A verificação de endereço e a correspondência do CVV são funções padrão em praticamente qualquer gateway, e muitas vezes são deixadas numa configuração permissiva porque apertá-las pode recusar alguns clientes legítimos junto com os bots. Para um negócio que já absorve preços de alto risco, essa troca geralmente vale a pena ser feita de forma deliberada em vez de deixada numa configuração padrão que ninguém realmente escolheu.
Coloque fricção especificamente na criação de contas e na entrada de cartão, não apenas no checkout. O verdadeiro alvo de um script de testing é o seu fluxo de cadastro e adição de cartão, não a sua página de compra, então um CAPTCHA e um limite rígido de quantas contas ou cartões um endereço IP pode criar por dia devem ficar ali primeiro. Pergunte diretamente ao seu gateway quais ferramentas de velocidade e limite de frequência o seu plano específico inclui, porque os fornecedores de alto risco variam enormemente nisso, e os mais baratos muitas vezes vendem a conta sem as defesas que um gateway comum inclui por padrão.
Por fim, pare de dizer aos clientes recusados por que foram recusados. Expor um motivo específico, um CVV errado, um endereço que não corresponde, dá a um script de testing exatamente a peça que falta de um registro de cartão roubado para refinar a próxima tentativa. Uma mensagem de recusa genérica não custa nada a um cliente real, que pode ligar para o suporte de qualquer forma, e custa ao fraudador a única informação que torna a sua próxima tentativa mais precisa do que a última.
