Garanta que Só Clientes Pagantes Usem os Recursos Pagos

Seu app pode esconder um botão, mostrar um selo Pro ou trocar uma página paga por uma mensagem de assinatura. Essas mudanças na tela são úteis, mas não são a proteção final. Os arquivos que desenham a tela são enviados ao aparelho do visitante. Um programa chamado navegador abre esses arquivos e mostra o app. Como a pessoa controla o próprio aparelho, as informações guardadas nele não devem decidir se o app cria um relatório pago, abre um curso, envia um arquivo para clientes ou realiza outra ação paga.

A resposta final, sim ou não, precisa vir de uma parte protegida do app que visitantes não conseguem editar diretamente. Os desenvolvedores chamam essa parte de servidor. Quando uma pessoa conectada pede um resultado pago, o servidor deve identificar a conta, consultar a situação atual do pagamento e decidir se aquela ação específica pode continuar. O nome técnico dessa decisão é autorização. Isso significa conferir o que uma conta conhecida pode fazer, e não apenas observar se um botão com aparência de pago está visível.

Escolha um registro ligado a cada conta de cliente que responda a uma pergunta simples: esta conta pode usar os recursos pagos agora? Ele também pode guardar o plano, a data até a qual o pagamento vale, a quantidade de usos restante ou um período de tolerância após uma cobrança recusada. Mantenha essas informações na parte protegida do app. Faça com que elas sejam a resposta principal usada por todos os recursos pagos, evitando que páginas diferentes adotem regras contraditórias.

Não deixe um campo como isPro, paid, premium ou planName no aparelho do visitante tomar a decisão final. A tela pode receber uma cópia das informações do pagamento para mostrar o plano correto ou uma mensagem de assinatura, mas essa cópia serve apenas para exibição. Os desenvolvedores chamam as informações mantidas na parte protegida do app de estado no servidor. Esse nome técnico significa que o registro confiável é guardado e conferido longe dos arquivos que o visitante pode alterar. A tela pode sugerir o que deveria acontecer; o registro protegido decide o que realmente acontece.

Uma pessoa pode deixar uma página aberta por horas, usar vários aparelhos, trocar de plano, cancelar, receber um estorno ou ter a renovação recusada. Se o app conferir somente quando ela entra na conta, uma página antiga poderá continuar agindo como se o acesso ainda estivesse ativo. A parte protegida do app deve consultar novamente o registro atual do cliente imediatamente antes de criar ou mostrar cada resultado pago.

Isso não significa que todas as telas precisam ficar lentas. A tela pode lembrar os detalhes do plano para responder rapidamente e explicar como assinar. Ela só não pode tomar a decisão final. Os desenvolvedores chamam o direito atual de usar um recurso de entitlement. Em português, o nome técnico pode ser entendido como direito de uso. Conferir esse direito significa confirmar a permissão no momento da ação. Por exemplo, a conferência pode confirmar se a conta pode abrir uma aula exclusiva, criar mais um relatório naquele mês ou baixar um arquivo enquanto o período pago continua válido.

A empresa que processa seus pagamentos normalmente envia um aviso ao app quando algo importante muda. O app deve receber esse aviso, relacioná-lo ao cliente correto e atualizar o registro protegido da conta. Defina o resultado esperado para uma nova compra, início de período de teste, renovação aprovada, renovação recusada, cancelamento ao fim do período pago, cancelamento imediato, estorno e contestação. Guarde informações suficientes para explicar quando e por que a situação mudou, sem armazenar mais dados do cliente do que o necessário.

Os desenvolvedores chamam um aviso automático enviado de um serviço para outro de webhook. Antes de mudar o acesso, o app deve confirmar que o aviso realmente veio da empresa de pagamentos e que ainda não foi aplicado. Mantenha a chave de pagamento, a senha ou o código de acesso usado nessa confirmação no ambiente protegido do servidor. Nunca coloque esses itens em arquivos enviados aos visitantes. Planeje também avisos atrasados ou fora de ordem: compare datas ou períodos de cobrança para impedir que uma falha antiga substitua incorretamente um pagamento mais recente.

Crie contas seguras de teste para um cliente ativo, uma pessoa sem pagamento, alguém em período de teste, um cliente cancelado que ainda possui dias pagos, um cliente com acesso vencido e um cliente que recebeu estorno. Use cada conta para experimentar todas as páginas e ações pagas da sua lista. Confira o resultado final, não apenas a aparência da tela. Se o botão para baixar um arquivo estiver escondido, confirme que nenhum arquivo é enviado. Se o botão de relatório estiver desativado, confirme que nenhum relatório é criado e nenhum uso é descontado.

Mantenha um registro curto dos testes e repita tudo quando mudar a entrada na conta, os preços, os planos, o processamento de pagamentos, os dados dos clientes ou algum recurso pago. Depois que o app estiver público, o VibeCodeWall pode conferi-lo por fora e acompanhar mudanças importantes ao longo do tempo. Ele não precisa acessar código que não seja público. Essa visão externa ajuda a perceber o que os visitantes conseguem alcançar, enquanto os testes com contas confirmam se a decisão protegida sobre pagamento continua funcionando. Use as duas verificações porque elas respondem a perguntas diferentes.