Não deixe o navegador decidir quem pagou
Uma página pode parecer bloqueada e ainda confiar em uma configuração que o visitante consegue mudar. Use um registro protegido para decidir quem recebe os recursos pagos.
antes de começar
Esconder um botão não protege um recurso pago. O app deve confirmar o pagamento da conta antes de entregar o resultado.
O que a decisão sobre pagamento significa
em palavras simples
A página pode mostrar informações de pagamento, mas não deve dar a palavra final sobre os recursos pagos.
Quando alguém visita seu app, o navegador recebe arquivos que montam a página no aparelho dessa pessoa. Esses arquivos podem esconder um botão, mostrar um aviso para assinar ou lembrar que uma compra parece ter terminado. Porém, algo guardado somente no navegador do visitante não serve como comprovante. Uma pessoa curiosa pode alterar uma configuração salva, reutilizar uma página antiga ou chegar a uma ação paga por outro caminho. Por isso, trate a página como uma tela de apresentação, não como dona da resposta real sobre o pagamento.
A resposta confiável deve ficar em uma parte protegida do app que os visitantes não conseguem baixar nem alterar. Os desenvolvedores chamam essa parte de servidor. Antes de enviar um relatório pago, abrir uma aula, criar uma reserva ou executar outra tarefa paga, o servidor deve consultar a conta e decidir se o registro atual permite aquela ação. Quando os arquivos do navegador dão a decisão final, o nome técnico é autorização no cliente. A tela pode até parecer correta, mas o resultado por trás dela continua sem proteção confiável.
- ▸Considere botões escondidos e mensagens de assinatura apenas como orientações para a pessoa.
- ▸Proteja o resultado em si, incluindo arquivos, informações e ações que custam dinheiro para oferecer.
risco comum
Uma pessoa sem assinatura muda uma configuração salva no navegador de não paga para paga. A página mostra um relatório exclusivo porque ninguém confere o registro real da conta.
o que fazer agora
Anote todos os resultados pagos do app, incluindo páginas, downloads, relatórios, aulas, reservas, itens gerados e ações que continuam após o fechamento da página.
peça isto à sua IA
Revise meu app inteiro em busca de recursos pagos. Liste todos os lugares onde arquivos do navegador, informações da página, dados salvos no navegador ou um botão escondido decidem se a pessoa pagou. Em cada lugar, leve a decisão final para o código protegido no servidor, que deve consultar a conta e o registro de pagamento atual antes de entregar informações ou concluir tarefas pagas. Não altere o visual nem os preços pretendidos. Mostre os arquivos modificados e explique cada decisão em linguagem simples.
Por que um único registro confiável importa
em palavras simples
Cada conta precisa de um registro protegido que indique claramente quais recursos pagos estão disponíveis agora.
Sem uma resposta confiável, partes diferentes do app podem discordar. A página principal pode dizer que a assinatura está ativa enquanto a área de download usa uma lista antiga. Uma pessoa que cancelou pode perder um recurso, mas continuar usando outro por uma página salva. Um cliente que pagou também pode ficar bloqueado porque uma tela não recebeu a informação mais recente. Isso acontece com mais facilidade quando cliques, mensagens após a compra e configurações espalhadas guardam versões diferentes da situação de pagamento.
Crie um registro protegido ligado à conta do cliente. Ele pode indicar situações como ativa, em teste, sem pagamento, atrasada, reembolsada ou cancelada, além da data final quando necessário. O nome técnico das permissões de produtos ou recursos nesse registro é entitlement. Associe o registro a um identificador estável da conta, não apenas ao nome exibido ou ao endereço de e-mail, pois eles podem mudar. Defina antes o significado de cada situação, inclusive um possível período de tolerância após uma renovação recusada, para que todos os recursos sigam a mesma regra escrita.
- ▸Use um registro da conta como resposta principal sobre o uso dos recursos pagos.
- ▸Defina o que contas ativas, em teste, atrasadas, reembolsadas e canceladas podem fazer.
risco comum
A compra marca uma página como paga, mas o cancelamento muda outro registro. O cliente perde o painel, enquanto uma página antiga de download ainda considera a conta ativa.
o que fazer agora
Monte uma tabela simples com as situações da conta e os recursos permitidos em cada uma. Inclua quando o uso começa, quando termina e se existe tolerância para atraso.
peça isto à sua IA
Crie um único registro protegido de permissão de pagamento para cada conta. Inclua as situações ativa, em teste, sem pagamento, atrasada, reembolsada e cancelada, além da data de término quando for necessária. Ligue o registro ao identificador estável usado pelo app. Substitua indicadores de pagamento espalhados por esse registro como fonte única de decisão. Preserve minha política atual, liste escolhas que ainda não estejam claras e faça as alterações de dados com segurança, sem guardar número nem código de segurança do cartão.
Uma forma comum de deixar recursos pagos abertos
em palavras simples
Conferir apenas o menu não basta, pois a pessoa pode chegar ao mesmo resultado pago por outro caminho.
Um erro comum é conferir o pagamento somente quando a pessoa abre uma página. O app esconde o botão de exportação das contas sem pagamento, então tudo parece protegido durante uma visita normal. Mas o trabalho que cria o arquivo pode aceitar uma solicitação sem consultar o registro atual. Uma pessoa usando um favorito antigo, uma aba que continuou aberta ou outra tela consegue chegar ao resultado valioso sem passar pelo menu onde estava a conferência.
Coloque a decisão junto de cada operação valiosa. Imediatamente antes de enviar um arquivo, mostrar informações de clientes, criar um item pago, iniciar um processamento pago ou mudar algo reservado a assinantes, o servidor deve identificar a conta conectada e ler seu entitlement atual. Os desenvolvedores chamam isso de autorização no servidor: a parte protegida decide se aquela conta pode realizar aquela ação específica. Se a resposta for não, mostre uma mensagem tranquila sobre pagamento ou situação da conta e não entregue nem mesmo uma parte do resultado pago.
- ▸Confira novamente quando cada resultado pago for solicitado, mesmo que a página já tenha conferido antes.
- ▸Inclua tarefas iniciadas por botões, páginas salvas, trabalhos automáticos e ações demoradas.
risco comum
O app esconde o botão de exportação de quem não paga, mas a operação separada que cria o arquivo nunca confere a assinatura e ainda produz o relatório.
o que fazer agora
Teste cada recurso pago pela navegação normal, por uma página salva, por uma aba antiga e por qualquer outro lugar capaz de iniciar o mesmo trabalho.
peça isto à sua IA
Siga todos os caminhos capazes de enviar um arquivo pago, mostrar informações pagas de clientes, criar um item pago, iniciar um processamento pago ou mudar dados exclusivos de assinantes. Adicione uma conferência de autorização no servidor junto de cada operação. Ela deve identificar a conta conectada, ler o entitlement atual, permitir somente as situações previstas na minha política e responder com uma mensagem clara sem entregar parte do conteúdo pago. Inclua testes com solicitações diretas e sessões antigas.
O que mudar agora
em palavras simples
As confirmações da empresa de pagamento devem atualizar o registro confiável sempre que a situação do cliente mudar.
A página mostrada depois da compra não deve ser a única responsável por liberar o uso pago. O cliente pode fechá-la, perder a conexão ou concluir o pagamento em outro aparelho. Renovações, cobranças recusadas, reembolsos e cancelamentos também acontecem depois, quando nenhuma página de compra está aberta. A empresa de pagamento pode enviar ao app uma mensagem protegida sobre cada acontecimento. Antes de mudar o registro do cliente, o app deve confirmar que a mensagem realmente veio dessa empresa.
Os desenvolvedores chamam essa mensagem recebida de webhook. O app deve usar o método de verificação documentado pela empresa de pagamento, relacionar o acontecimento ao identificador estável da conta correta e atualizar o entitlement. Se a mesma mensagem confirmada chegar novamente, o resultado deve continuar correto, sem criar permissões duplicadas. Guarde um histórico limitado com identificador do acontecimento, identificador da conta, tipo, horário e resultado, mas não armazene número nem código de segurança do cartão. Mantenha as chaves de pagamento no servidor, onde visitantes não podem baixá-las nem alterá-las.
- ▸Trate compras, renovações, falhas, reembolsos, contestações e cancelamentos conforme sua política escrita.
- ▸Aceite repetições confirmadas com segurança e mantenha um pequeno histórico para atendimento e correções.
risco comum
O cliente conclui o pagamento, mas fecha a confirmação. O uso nunca é liberado porque a página, e não a mensagem confirmada da empresa de pagamento, deveria atualizar a conta.
o que fazer agora
Abra as configurações da empresa de pagamento e confirme que todos os acontecimentos importantes são enviados à parte protegida do app e registrados com sucesso.
peça isto à sua IA
Implemente o recebimento verificado de mensagens da minha empresa de pagamento pelo método oficial dela. Trate compra confirmada, início de teste, renovação, falha de pagamento, reembolso, contestação e cancelamento. Relacione cada acontecimento a uma conta estável, atualize seu entitlement conforme minha política e faça repetições produzirem o mesmo resultado. Guarde somente um histórico pequeno, nunca salve número nem código de segurança do cartão, mantenha as chaves no servidor e crie testes para mensagens válidas, inválidas, repetidas e fora de ordem.
Como confirmar que a correção continua funcionando
em palavras simples
Teste várias situações de conta agora e repita as conferências sempre que o pagamento ou um recurso pago mudar.
Crie contas seguras de teste para um cliente ativo, uma pessoa em período de teste, uma pessoa sem pagamento, uma conta atrasada e uma conta cancelada. Antes de começar, anote o que cada uma deveria receber. Depois, teste a navegação normal, páginas salvas, visitas diretas, downloads, abas antigas e tarefas que demoram para terminar. Confira os dois lados da regra: quem pode usar deve receber tudo o que comprou, enquanto as demais contas devem ver uma mensagem clara sem receber informações ou trabalhos pagos.
Repita essas conferências após mudanças na compra, na entrada da conta, nos preços, nos registros ou nos recursos pagos. Observe também acontecimentos inesperados de pagamento e conferências recusadas, evitando que erros comuns deixem pessoas com o resultado errado sem ninguém perceber. O VibeCodeWall confere o app público por fora e acompanha mudanças importantes ao longo do tempo. Ele não precisa ver código particular para ajudar a apontar comportamentos públicos que merecem revisão. Essa visão externa complementa os testes de conta, mas não substitui a decisão protegida dentro do app.
- ▸Registre o tipo de conta, o recurso, o resultado esperado e o resultado obtido em cada teste.
- ▸Repita as conferências após mudanças importantes e investigue qualquer diferença inesperada.
risco comum
Um cliente cancelado não entra pela página principal, mas ainda cria relatórios pagos usando um favorito salvo antes do cancelamento.
o que fazer agora
Execute hoje o teste completo das contas. Guarde os resultados, defina uma pessoa responsável pelas falhas e repita tudo após a próxima mudança em pagamentos, entrada na conta ou recursos pagos.
peça isto à sua IA
Crie e execute um plano de testes automatizados para todos os recursos pagos do meu app. Use contas ativa, em teste, sem pagamento, atrasada, reembolsada e cancelada. Teste navegação normal, visitas diretas, páginas salvas, downloads, sessões antigas, solicitações repetidas e trabalhos demorados. Registre o resultado esperado e o obtido em cada caso. Confirme que contas permitidas recebem o resultado completo e que contas bloqueadas não recebem informações nem trabalhos pagos. Entregue também uma lista manual curta para eu repetir após mudanças futuras.
Checklist rápido
- 01Liste todas as páginas, aulas, reservas, informações, arquivos e ações que exigem pagamento.
- 02Descubra onde o app decide hoje se a pessoa pagou.
- 03Mantenha um único registro confiável de pagamento para cada conta.
- 04Faça a parte protegida do app decidir se cada resultado pago será entregue.
- 05Atualize o registro após compras, renovações, falhas, reembolsos e cancelamentos confirmados.
- 06Guarde as chaves de pagamento onde visitantes não possam baixá-las nem alterá-las.
- 07Teste contas pagas, em período de teste, sem pagamento, atrasadas e canceladas.
- 08Confira o app público por fora após mudanças importantes e continue acompanhando-o ao longo do tempo.
FAQ
Basta esconder um botão pago?
Não. Isso melhora a experiência da página, mas a parte protegida do app ainda precisa conferir o registro atual da conta antes de entregar o resultado.
Onde devo guardar as chaves de pagamento?
Guarde-as nas configurações protegidas do servidor, que visitantes não conseguem baixar nem alterar. Nunca coloque nos arquivos enviados ao navegador uma chave capaz de cobrar valores ou ler informações de pagamento.
O que deve acontecer após uma falha de pagamento?
Siga a política informada aos clientes, como um período de tolerância ou uso reduzido. Atualize o registro confiável da conta para que todos os recursos apliquem a mesma regra.
Preciso conferir o pagamento em todas as páginas?
A conferência essencial deve acontecer onde o resultado pago é entregue ou o trabalho pago começa. A página também pode mostrar a situação atual, mas essa exibição não dá a decisão final.