O contexto
A FEEB emite o Documento Nacional do Estudante, que dá direito à meia-entrada legal (Lei 12.933/2013 e Decreto 8.537/2015). O documento existe em duas formas: digital, no celular do aluno, e físico, impresso e enviado pelo correio.
O fluxo tem três partes com donos diferentes. O aluno preenche o cadastro, envia foto 3x4 e comprovante de matrícula e paga. Alguém da federação confere se aquele comprovante é real e se a foto serve para impressão. E alguém emite, imprime e despacha o cartão físico.
O problema
Cadastro longo com upload de documento e pagamento é onde o aluno desiste. Um formulário único com quinze campos e dois anexos tem abandono alto, e cada abandono é uma matrícula não convertida.
Do outro lado, a triagem é manual por natureza: alguém precisa olhar o comprovante e decidir. O sistema não pode fingir que isso é automático; ele precisa é tornar essa conferência rápida e permitir agir em lote, porque os pedidos chegam em pico no começo do semestre, não distribuídos ao longo do ano.
E tem o problema da fraude. Carteirinha estudantil é documento falsificado com frequência. Uma imagem bonita no celular não vale nada se o cinema não tem como checar se ela é real.
Por fim, pagamento: PIX confirma por webhook, que pode chegar duas vezes, atrasado ou fora de ordem. Emitir documento duas vezes pelo mesmo pagamento é erro caro.
Decisões técnicas
Solicitação em 6 etapas em vez de formulário único. Dados pessoais, instituição, endereço, upload de foto e comprovante, pagamento, resumo. Etapas custam mais código de estado e navegação. Compram duas coisas: validação no ponto do erro, em vez de quinze mensagens vermelhas de uma vez no fim, e progresso salvo — quem parou na etapa 4 volta para a 4, não para o começo.
Livewire no backoffice, Next.js no app do aluno — duas tecnologias de propósito. A pergunta óbvia é por que não usar a mesma coisa nos dois. Porque os dois lados têm exigências opostas. O app do aluno é público, precisa carregar rápido no celular em rede ruim e ser encontrável — Next.js entrega isso. O backoffice é interno, atrás de login, e o que importa nele é velocidade de construção de telas densas de triagem; escrever isso como SPA significaria uma API para cada tela e um estado de cliente para manter. Livewire renderiza no servidor com interatividade suficiente, e a regra de negócio nunca sai do PHP. O custo é ter duas stacks de frontend no projeto — aceitável porque a fronteira entre elas é nítida, não uma zona cinzenta.
Ações em lote na triagem, não uma a uma. Emitir, enviar e marcar como entregue são operações que a federação faz sobre dezenas de registros de uma vez. Tela de detalhe por aluno funcionaria e transformaria o pico do semestre em trabalho braçal.
QR Code apontando para URL pública de validação, não para dados embutidos. Um QR que carrega os dados do aluno é falsificável: quem gera a imagem controla o conteúdo. Apontando para uma URL do domínio da FEEB, quem valida consulta a fonte — o dado vem do servidor, não do plástico. Por isso a carteirinha é imutável: o que ela exibe é reflexo do registro, não um documento gerado uma vez e esquecido.
Webhook Asaas idempotente com reconciliação assíncrona. O handler é chaveado pelo identificador da cobrança: reprocessar o mesmo evento não emite documento de novo. E não confio só no webhook — existe reconciliação assíncrona, porque webhook perdido acontece e o aluno que pagou não pode ficar preso esperando um evento que não chegou.
Pest desde o início. Fluxo de pagamento e transição de status de emissão são exatamente o tipo de código onde o bug só aparece em produção, com dinheiro real de aluno envolvido.
O que ficou pronto
Plataforma em operação: solicitação em 6 etapas, pagamento PIX, carteirinha digital com QR Code validável publicamente, central de avisos, backoffice de triagem e aprovação, controle de status em lote e gestão de envio físico com calibração de impressão.
Interface do Sistema
