Uma configuração do navegador nunca deve liberar recursos pagos

Você pede à ferramenta de IA que abra um painel premium depois da compra. Ela salva no aparelho do visitante um rótulo como “pro”, esconde o botão de upgrade e mostra as ferramentas pagas. O seu teste funciona e o recurso parece pronto. Para o negócio, porém, a pergunta importante não é se a página parece bloqueada. É se o app recusa um relatório, download, tarefa de IA ou resultado exclusivo quando a pessoa não pagou.

O programa usado para abrir o app é o navegador. Como ele funciona no aparelho do visitante, essa pessoa pode alterar informações guardadas ali. Ela também pode pedir um resultado sem clicar no botão criado por você. Por isso, um rótulo no navegador pode ajustar a tela, mas não pode dar a decisão final. Se o app confiar nesse rótulo, uma conta sem pagamento ou com assinatura cancelada poderá receber algo que você pretendia vender.

O app também tem uma parte que funciona em um computador controlado por você e que o visitante não pode alterar livremente. O nome técnico dessa parte é servidor. A regra segura é simples: o navegador pode pedir o resultado pago, mas o servidor decide se deve entregá-lo. O nome técnico dessa decisão é autorização no servidor. Isso significa conferir a identidade do cliente logado e o direito atual dele de usar aquele recurso antes de entregar o resultado.

Uma decisão confiável precisa de duas respostas: quem está pedindo e pelo que essa pessoa pagou? O login fornece a primeira. Para a segunda, use um cadastro organizado de pagamentos, guardado na parte do app que você controla. O nome técnico desse armazenamento organizado é banco de dados. O cadastro deve relacionar a conta no seu app ao cliente e à assinatura correspondentes na empresa de pagamentos.

Não deixe a página de compra simplesmente declarar “pagamento concluído” e marcar a própria conta como paga. A empresa de pagamentos deve enviar uma mensagem assinada diretamente ao servidor. Antes de atualizar o cadastro, o servidor confirma que a mensagem veio realmente dessa empresa. O nome técnico desse tipo de mensagem de pagamento é webhook. Ela pode informar que uma assinatura começou, renovou, falhou, foi cancelada ou recebeu reembolso.

O cadastro confiável deve indicar o que o cliente pode usar agora e quando essa permissão termina. O nome técnico é entitlement; em português, direito de uso. Defina a regra comercial para cada situação. Uma assinatura ativa pode permitir uso; um cancelamento pode manter o acesso até o fim do período já pago; um reembolso pode encerrar o acesso conforme a sua política; e uma falha de pagamento pode iniciar um prazo ou impedir o uso. A chave de assinatura das mensagens, a chave de pagamento, a senha do banco de dados e qualquer código de acesso a informações de clientes devem ficar somente no servidor.

A compra acontece uma vez, mas o acesso pode durar meses. Nesse período, um pagamento pode falhar, uma assinatura pode terminar ou um reembolso pode acontecer. Mesmo assim, um rótulo antigo no navegador ainda pode dizer “pro”. Por isso, levar o cliente para uma página premium depois da compra melhora a experiência, mas não protege sozinho o recurso.

Coloque a decisão na operação do servidor que cria um relatório, entrega um arquivo premium, lê informações exclusivas, executa uma tarefa paga de IA ou muda uma configuração paga. O nome técnico de um ponto definido onde o navegador pede uma tarefa ao servidor é endpoint. Em cada endpoint pago, primeiro identifique o cliente logado, depois leia o direito de uso confiável, aplique a regra registrada e somente então inicie o trabalho valioso.

Conferir antes também protege o orçamento do app. Um pedido sem pagamento não deve iniciar uma geração por IA, criar um arquivo grande ou consumir outro serviço pago antes de ser recusado. Mostre uma mensagem simples, como “Este recurso exige um plano ativo”. Teste em um ambiente separado, com clientes e pagamentos de teste. Não altere assinaturas reais para observar o resultado. Inclua contas pagas, não pagas, canceladas, vencidas e reembolsadas. Confirme que os casos negados não recebem o resultado nem geram trabalho cobrado.

A empresa de pagamentos pode enviar a mesma mensagem verificada mais de uma vez quando há atraso ou nova tentativa de entrega. O app deve reconhecer mensagens repetidas e evitar liberar, ampliar ou remover o acesso duas vezes por engano. Guarde um pequeno histórico com o tipo da mensagem, o horário, o cliente relacionado e o resultado. O nome técnico desse histórico é registro de auditoria. Se uma mensagem não puder ser ligada a um único cliente, coloque-a em uma lista de revisão em vez de liberar acesso automaticamente.

Repita os testes de permissão e recusa depois de mudanças no login, na compra, no tratamento dos pagamentos ou em qualquer recurso pago. As checagens públicas gratuitas do VibeCodeWall podem examinar o que o app público expõe, mas não enxergam código privado nem provam que as regras de pagamento funcionam. Elas complementam a revisão e os testes separados das operações do servidor que entregam resultados pagos.

Para usar o monitoramento contínuo Pro, é preciso ativá-lo e informar um inventário correto das tecnologias e versões usadas pelo app público. O monitoramento usa esse inventário; portanto, itens ausentes limitam a cobertura. Uma falha recém-publicada pode mudar o risco de uma tecnologia inventariada mesmo quando você não atualizou o app. O monitoramento pode ajudar a indicar essa mudança pública, mas não corrige o app automaticamente nem garante prevenção. O próximo passo útil continua sendo concreto: rastrear um recurso pago, adicionar sua decisão confiável no servidor em um ambiente de teste e verificar tanto a jornada permitida quanto a recusada.