Antes de liberar qualquer mudança no fluxo de fila ou checkout de uma plataforma de ingressos, você precisa confirmar que o CAPTCHA continua sendo resolvido do jeito esperado — sem esperar o dia da venda real para descobrir um erro. A forma segura de fazer isso é reproduzir o fluxo inteiro (fila, assentos, pagamento e envio do token) em staging, com evento fictício e dados de teste, e usar a CaptchaAI para validar cada etapa antes de aprovar a mudança.
Este guia cobre apenas ambiente próprio, QA, staging ou pré-produção com autorização explícita da sua equipe. Os exemplos usam páginas internas, dados fictícios e endpoints de validação controlados por você — não há aqui orientação para automatizar serviços de terceiros, compra real, venda pública ou qualquer controle de acesso fora do seu ambiente.
Por que isolar esse teste em staging
Use apenas a própria plataforma, em staging, com evento fictício, mapa de assentos de teste, ingresso fictício e token de pagamento simulado. Isso garante que qualquer falha do CAPTCHA apareça primeiro no ambiente de QA — não durante uma venda real — e permite rodar a suíte quantas vezes for preciso sem gerar ingresso válido nem afetar cliente real.
Como simular a fila de ingressos para QA
Crie https://staging.example.com/ticketing/queue-test para reproduzir posição na fila, liberação de vaga e expiração de sessão. O runner de QA deve validar o estado da fila — incluindo o momento em que o token do CAPTCHA expira — sem nunca entrar em uma venda pública.
Vale separar o teste em dois momentos, porque cada um tem uma janela de tempo diferente para o CAPTCHA:
Entrada na fila
O token do CAPTCHA de entrada pode ser resolvido pouco antes da simulação começar, já que a fila em staging não tem a pressão de estoque limitado que existe em produção. Use essa etapa para confirmar que o backend aceita o token corretamente e libera a posição simulada.
Checkout simulado
Depois que o runner recebe a liberação da fila, o CAPTCHA do checkout precisa ser resolvido em tempo real, porque o token expira em segundos. É aqui que problemas de timeout aparecem primeiro — e é exatamente esse comportamento que a suíte de QA deve capturar antes de ir para produção.
Evento, assentos e pagamento fictícios
Use https://staging.example.com/ticketing/fake-event, um mapa de assentos artificial e um token de pagamento de sandbox. Cada reserva de teste deve expirar automaticamente e nunca emitir um ingresso válido. Se a sua plataforma de pagamento tiver um modo sandbox dedicado — a maioria tem —, prefira sempre esse modo ao de produção: mesmo em staging, um erro de configuração não deve conseguir gerar uma cobrança real.
Enviando a tarefa à CaptchaAI a partir do staging
O envio da tarefa deve partir do próprio ambiente de teste e usar a URL https://staging.example.com/ticketing/checkout-test como pageurl — assim, o token retornado corresponde exatamente à página que o runner de QA está validando.
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/ticketing/checkout-test')
token_qa = aguardar_resultado(task_id)
print({'token_recebido': bool(token_qa)})
Validando o resultado no backend de QA
O backend recebe o token, valida o CAPTCHA, confirma o assento fictício reservado e devolve um status pass/fail para a suíte de QA consumir. Trate esse status como a fonte da verdade do teste — não apenas o código HTTP da resposta, que pode voltar 200 mesmo quando o CAPTCHA falhou silenciosamente.
Logging e decisão pass/fail
Registre a posição simulada na fila, o caso de QA, o tempo de resolução do CAPTCHA, o resultado do backend, o motivo de falha (quando houver) e a correlação com o trace do checkout. Mesmo usando apenas dados fictícios, documente como esses logs são retidos e por quanto tempo — é uma boa prática se alinhar com os princípios da LGPD sempre que o pipeline de QA grava algum identificador que, em tese, poderia ser confundido com dado real.
Resolvendo problemas comuns
Se a fila expirar antes do runner concluir o teste, aumente o TTL do ambiente de staging. Se a sitekey usada no teste divergir da configurada pelo frontend, sincronize as duas. Se o backend rejeitar o token, verifique domínio e action esperados pelo reCAPTCHA v3 antes de suspeitar da CaptchaAI. Se o tempo de resolução variar bastante entre execuções, meça o RTT do worker de QA até o endpoint — times rodando longe do endpoint, como em sa-east-1 da AWS para equipes no Brasil, tendem a ver mais variação do que times mais próximos.
Critérios para liberar a mudança em produção
Antes de aprovar a mudança testada, confirme que a documentação aponta para o ambiente próprio, que os exemplos usam dados fictícios, que nenhum endpoint de produção é acionado pelo teste e que os logs têm correlação suficiente para auditoria. A página de staging deve ter domínio autorizado, a sitekey esperada, configuração de backend separada da produção e uma política clara de expiração. Quando o resultado variar entre execuções, trate os números como amostra interna: repita a medição, anote a janela de execução e compare apenas cenários equivalentes — nunca uma execução isolada contra outra.
Perguntas frequentes
Preciso de um evento real para testar o CAPTCHA do checkout?
Não. Use sempre um evento fictício, criado especificamente para QA, com assentos de teste e pagamento simulado. Isso evita qualquer risco de gerar ingresso válido ou cobrança real durante o teste.
Como simulo a expiração do token na fila?
Configure o TTL do ambiente de staging para um valor menor que o padrão de produção e registre o horário exato em que o token deixa de ser aceito pelo backend. Repita o teste em janelas diferentes para confirmar que o comportamento é consistente.
É seguro rodar essa suíte de QA contra o ambiente de produção?
Não. Toda a suíte descrita aqui deve rodar exclusivamente em staging ou pré-produção, com autorização explícita da equipe responsável. Rodar contra produção arrisca gerar ingresso, cobrança ou impacto para cliente real.
Que tipos de CAPTCHA costumam aparecer nesse tipo de fluxo?
Na maioria dos casos, reCAPTCHA v2, reCAPTCHA v3 e Cloudflare Turnstile — todos com suporte GA na CaptchaAI. Se a sua plataforma usar outro tipo, confirme o status na referência de tipos suportados antes de desenhar o teste.
Como decido se o resultado de um teste é pass ou fail?
Use o status devolvido pelo backend de QA, não só o código HTTP. Um pass exige token aceito, assento fictício confirmado e log correlacionado ao trace do checkout; qualquer divergência nesses pontos é fail.
Guias relacionados seguros
- Início rápido da CaptchaAI
- Como estruturar testes de QA autorizados de CAPTCHA
- Testando endpoints de CAPTCHA em formulários próprios
- O que fazer quando o navegador falha e a API resolve o CAPTCHA
- Como resolver reCAPTCHA v2 com a API
- Como resolver Cloudflare Turnstile com a API
- Como resolver GeeTest v3 com a API
Valide, no seu próprio ambiente, a integração de CAPTCHA da plataforma de ingressos com a CaptchaAI.
