Um CAPTCHA mal configurado no checkout derruba conversão exatamente no pico — Black Friday, Dia do Consumidor, campanha de cupom com prazo curto. A forma de evitar isso é simples: validar reCAPTCHA v2, reCAPTCHA v3 e Cloudflare Turnstile em staging, com dados fictícios, antes de qualquer mudança chegar à produção. Este guia mostra como montar esse pipeline de QA com a CaptchaAI, do ambiente isolado ao critério de publicação.
Tudo aqui roda em ambiente próprio, com autorização explícita da equipe: páginas internas, conta de QA, produtos e pagamento fictícios. Não há orientação para automatizar checkout de terceiros, comprar produtos reais ou agir fora do seu próprio ambiente.
Por que testar o checkout antes do pico de tráfego
O checkout costuma ser o ponto mais frágil de uma campanha de alto tráfego. Um widget de CAPTCHA que muda de sitekey, de tipo — de reCAPTCHA v2 para Turnstile, por exemplo — ou de action sem passar por QA derruba pedidos exatamente na janela de maior receita. Testar em staging, com o mesmo widget que vai para produção, é o jeito de pegar essa quebra antes do cliente.
Escopo seguro do teste
Use este guia só para o checkout do seu próprio e-commerce, em staging. A conta é de QA, os produtos e o estoque são fictícios, o token de pagamento é de sandbox e os endpoints são internos. Nenhum pedido real deve sair desse fluxo — o backend precisa impedir qualquer captura financeira de fato.
Monte o ambiente de staging com o mesmo widget de produção
Publique https://staging.example.com/checkout-test com o mesmo widget CAPTCHA planejado para produção, mas ligado a uma base de dados isolada. O runner de QA abre a página, confirma que a sitekey esperada está presente e só então envia a tarefa para a CaptchaAI — assim você testa a integração real, não uma versão simplificada dela.
Use SKUs, carrinho e pagamento fictícios
Defina SKUs como QA-SKU-001, carrinhos de teste e tokens de pagamento de sandbox. O backend precisa recusar qualquer captura financeira real e marcar todo pedido desse fluxo como qa_only, para que ele nunca apareça nos relatórios de venda.
Envie a tarefa para a CaptchaAI a partir do teste
A tarefa deve usar a URL de staging controlada e a sitekey de QA — nunca a sitekey de produção.
import os, time, requests
API_KEY = os.environ['CAPTCHAAI_API_KEY']
SITEKEY = os.environ['QA_CAPTCHA_SITEKEY']
def criar_tarefa_captcha(pageurl):
resposta = requests.post('https://ocr.captchaai.com/in.php', data={
'key': API_KEY,
'method': 'userrecaptcha',
'googlekey': SITEKEY,
'pageurl': pageurl,
'json': 1,
}).json()
return resposta['request']
def aguardar_resultado(task_id):
while True:
time.sleep(5)
resposta = requests.get('https://ocr.captchaai.com/res.php', params={
'key': API_KEY,
'action': 'get',
'id': task_id,
'json': 1,
}).json()
if resposta.get('status') == 1:
return resposta['request']
task_id = criar_tarefa_captcha('https://staging.example.com/checkout-test')
token_qa = aguardar_resultado(task_id)
print({'token_recebido': bool(token_qa)})
O runner cria a tarefa, faz polling em res.php a cada 5 segundos e recebe o token assim que o status muda para 1.
Valide o token no endpoint de QA
Encaminhe o token recebido para https://staging.example.com/qa-checkout. O endpoint valida o CAPTCHA, confirma o carrinho fictício e devolve um status de teste, sem criar pedido público.
Registre logs e métricas para pegar regressão cedo
Grave tempo de criação da tarefa, tempo até a resposta, tipo de CAPTCHA, resultado do endpoint interno, caso de QA, commit testado e ambiente. Se o worker de teste roda perto da produção — por exemplo, numa região como sa-east-1 — a latência de rede fica próxima da real, o que deixa a medição mais confiável. Use mediana, P90 e P99 para detectar regressão, e trate os dados de teste conforme a LGPD: sem CPF real, sem e-mail real, sem qualquer dado que identifique uma pessoa de verdade.
Onde a validação costuma quebrar
- Domínio ou sitekey diferente do esperado — confira se o ambiente de staging não herdou a sitekey de outro projeto.
- Token expirado — o token do reCAPTCHA e do Turnstile vale por um tempo curto; valide-o assim que ele chega, sem fila de espera no backend.
- Relógio do runner fora de sincronia — um timestamp desalinhado derruba a validação mesmo com o token correto.
- Confusão entre
https://staging.example.com/captcha-demoe o checkout de teste real — são páginas diferentes, com sitekeys diferentes.
Checklist antes de publicar a mudança
Antes de levar a mudança testada para produção, confirme que a documentação aponta para o ambiente próprio, que os exemplos usam dados fictícios e que nenhum endpoint de produção foi acionado durante o teste. Os logs devem ter correlação suficiente para auditoria, e a página de staging precisa ter domínio autorizado, sitekey esperada, configuração de backend separada e uma política clara de expiração. Quando o resultado variar, trate os números como amostra interna: repita a medição, anote a janela de execução e compare só cenários equivalentes.
Perguntas frequentes
Preciso de uma sitekey de produção para testar?
Não. Use uma sitekey de QA, ligada ao mesmo domínio de staging. Isso evita qualquer risco de misturar dado de teste com tráfego real.
Quanto tempo leva para validar reCAPTCHA v2, reCAPTCHA v3 ou Turnstile num teste?
Depende do tipo: a CaptchaAI resolve reCAPTCHA v3 em menos de 4 segundos, Cloudflare Turnstile em menos de 10 segundos e reCAPTCHA v2 em menos de 60 segundos, com alta taxa de sucesso nos tipos suportados. Some esse tempo ao timeout do seu teste para não derrubar o caso por engano.
Dá para simular o pico de tráfego de uma campanha sem afetar produção?
Sim. Rode o runner de QA em paralelo, com várias tarefas simultâneas apontando para o mesmo ambiente de staging, e observe P90 e P99 antes de aumentar o volume real. Mesmo o plano BASIC (US$ 15/mês, 5 threads) costuma bastar para esse tipo de teste; suba de plano só quando o volume de staging exigir mais threads simultâneas.
O que fazer se o token expira antes de chegar ao endpoint de QA?
Reduza o tempo entre a resposta da CaptchaAI e o envio para https://staging.example.com/qa-checkout. Se o pipeline de teste tem uma etapa lenta antes da validação, valide o token assim que ele chega e só depois rode o restante da suíte.
Também dá para testar GeeTest v3 nesse pipeline?
Sim. O fluxo é o mesmo: sitekey de QA, ambiente de staging e o método correspondente na chamada à CaptchaAI. A única mudança real é o tipo de CAPTCHA informado na tarefa.
Guias relacionados
- Comece pelo início rápido da CaptchaAI
- Testes de QA autorizados para CAPTCHA
- Teste de endpoint CAPTCHA em formulários próprios
- Quando o navegador falha mas a API funciona
- Como resolver reCAPTCHA v2 pela API
- Como resolver Cloudflare Turnstile pela API
- Como resolver GeeTest v3 pela API
Valide o CAPTCHA do checkout no seu próprio ambiente de staging com a CaptchaAI antes do próximo pico de tráfego.
