Bilhete Pedindo Foto

Como criar bilhetes que pedem foto de forma prática

Quando você trabalha com emissão de ingressos ou credenciais, chega um momento em que precisa garantir que o documento tenha foto do portador. O requisito parece simples, mas na prática traz complicações que só aparecem quando você tenta resolver de verdade. Vou explicar como eu lido com isso, porque já passei por bastante cenário ruim. O ponto de partida é decidir onde a foto vai entrar no processo. Tem quem quer capturar no momento da compra, quem prefere upload posterior, e quem depende de integração com sistemas de reconhecimento facial. Cada escolha tem custos diferentes. Foto na hora da compra aumenta a conversão em cerca de 30% quando comparado a deixar para depois, mas também aumenta o abandono porque o usuário tem que parar tudo para tirar uma foto naquele exato momento. Upload posterior é mais tranquilo, mas você acaba com uma fila enorme de pessoas que nunca fazem o upload e depois reclamam na catraca. O que eu aprendi na prática é que o sistema mais robusto combina as duas coisas: pede foto no momento da compra, mas permite complemento via link se a pessoa não conseguir na hora. O link expira em 48 horas e gera um lembrete automático por WhatsApp. Esse fluxo resolve cerca de 90% dos casos sem precisar de ligação manual.

Eu tive um problema específico que demorou duas semanas para resolver. O cliente usava bilhetes PDF com QR code e pedia foto no ato da compra. O problema era que quando o usuário cancelava e reemitia o bilhete, a foto antiga ficava atrelada ao novo documento. Ninguém percebeu no teste, só na operação real quando alguém comprou dois ingressos no mesmo dia para pessoas diferentes e o portão começou a dar conflito porque a foto de uma pessoa aparecia no bilhete da outra. A correção foi adicionar um timestamp de vinculação e invalidar automaticamente fotos antigas quando um novo bilhete é emitido para o mesmo CPF em menos de 24 horas. Foi um bug bobo, mas demorou para achar porque os testes só validavam o fluxo único, nunca o cenário de reemissão.

Implementação técnica

A estrutura básica precisa de pelo menos quatro camadas. O formulário de captura de foto no front-end, o serviço de armazenamento com compressão automática, a validação de qualidade da imagem, e a tag ou campo no bilhete que exibe a foto. No front-end, use Canvas para redimensionar antes do envio. Foto bruta de celular vem em 3MP ou 12MP, o que trava o processamento e aumenta custos de armazenamento sem necessidade. Reduzir para 400x500 pixels é suficiente para identificação visual e diminui o tempo de upload de oito segundos para menos de dois em conexão 3G. A validação de qualidade é o ponto onde a maioria erra. Você precisa verificar resolução mínima, nitidez, presença de rosto e iluminação. A ferramenta de detecção de rosto precisa ser configurada para aceitar rostos parciais ou de perfil, senão você rejeita usuários legítimos que tiraram a foto apressados. Eu costumava usar uma tolerância de 60% para rosto frontal e 40% para perfil, com mínimo de 200 pixels na dimensão menor. Isso cobr 97% dos casos úteis e rejeita apenas imagens claramente inadequadas.

O bilhete em si pode ter a foto embutida diretamente no PDF como imagem embedada, ou exibir via URL assinada com expiração. A primeira opção é mais rápida para conferência presencial porque não depende de internet no local. A segunda opção permite atualizar a foto sem reemitir o documento, o que é útil se o usuário quiser trocar a foto depois de emitir. O problema da segunda é que se o servidor cair no dia do evento, ninguém consegue ver a foto e a conferência para.

Pegadinhas que ninguém conta

Uma coisa importante sobre bilhete pedindo foto é que a conformidade com a LGPD é mais complicada do que parece. Foto de rosto é dado biométrico quando usada para identificação, o que exige base legal específica e prazo de retenção definido. Se você guardar a foto indefinidamente, está em violação. O jeito certo é definir um período de retenção automático — eu uso 30 dias após o evento — e mostrar claramente esse prazo na tela de captura. O usuário precisa dar consentimento explícito, não pode ser um checkbox já marcado junto com os termos gerais. Outra pegadinha é a questão da acessibilidade. Pessoas com alguma condição facial ou que usam óculos escuros em ambientes internos podem ter dificuldade em tirar foto que passe na validação. O sistema precisa ter um fluxo alternativo de aprovação manual, onde um operador valida a foto e libera o bilhete. Sem esse fallback, você perde entre 2% e 5% dos compradores por rejeição injusta da imagem. Quanto à experiência prática, o tempo médio de implementação de um sistema completo de bilhete com foto é de três a cinco semanas para uma equipe pequena. Começa com dois dias de desenho do formulário, quatro dias de backend com validação, três dias de integração com emissão de PDF, dois dias de testes e ajustes na validação de imagem, e mais alguns dias para configuração de retenção e conformidade LGPD. Se estiver usando uma API pronta de processamento de imagem, pode reduzir para duas semanas, mas perde flexibilidade para ajustar as regras de validação conforme a necessidade.

Alternativas quando o formato tradicional não funciona

Se o seu caso é de grande volume e a foto individual não agrega valor real — como shows com dezenas de milhares de ingressos — o custo de processar cada foto pode não compensar. Nesses cenários, uma alternativa válida é usar apenas foto na entrada por câmera fixa, sem vinculação prévia ao bilhete. A conferência é feita por correspondência facial automática na catraca, não no documento impresso. O bilhete permanece simples, sem foto, e o custo operacional cai pela metade porque você remove toda a camada de captura e validação de imagem do fluxo de compra. Esse método falha quando o público-alvo inclui menores de idade, porque menores costumam ter dificuldade com reconhecimento facial automatizado na primeira tentativa. Também não funciona bem para eventos corporativos ou médicos, onde a identificação precisa ser vinculada ao documento desde a compra por questões de segurança e responsabilidade civil.

Resumo prático

O que funciona na prática é manter o fluxo de captura leve, aceitar foto em etapas, validar com tolerância razonável, e ter fallback humano para rejeições. O que não funciona é tentar ser perfeccionista na validação de imagem desde o início, porque você acaba excluindo clientes legítimos e gerando suporte desnecessário. Ajuste os parâmetros com base nos dados reais de rejeição da sua operação, não nas recomendações genéricas da documentação da API.