O encerramento de uma conta SaaS com período de carência não é uma única operação adiada. É um fluxo de ciclo de vida que precisa coordenar acesso, faturamento, tarefas automáticas, integrações e dados. Se a aplicação apenas armazena uma data de encerramento e a verifica no login, outros processos podem continuar operando como se a organização estivesse ativa.
O projeto deve explicitar o significado de cada etapa, quem pode realizar uma transição e quais efeitos são reversíveis. Assim, cancelar a solicitação não equivale a reconstruir a conta do zero, e chegar à data limite não depende de um usuário fazer login novamente.
Separar solicitação, suspensão e encerramento definitivo
A solicitação expressa uma intenção: uma pessoa autorizada pede o encerramento da conta. A suspensão determina o que a organização pode fazer enquanto essa solicitação é processada. O encerramento definitivo executa as ações finais, que podem incluir revogar credenciais, interromper processos e aplicar a política de dados. São momentos distintos e convém modelá-los separadamente.
Uma decisão importante de produto é quando as restrições de acesso começam. Se o acesso for mantido até o vencimento, isso precisa ser comunicado com clareza, e o uso durante esse período deve ser controlado. Se o acesso for restringido imediatamente, o período de carência serve para recuperar a conta, não para continuar usando o serviço normalmente. Não há uma opção universal: isso depende do modelo comercial, dos riscos e das obrigações do produto.
Também é preciso definir as consequências para o faturamento e as assinaturas. O encerramento da conta não cancela necessariamente uma assinatura externa, assim como o cancelamento de um pagamento não deve eliminar uma organização. Esclareça qual é a fonte da verdade para cada decisão e evite inferir o estado operacional a partir de um evento isolado do provedor de pagamentos.
Definir estados e transições permitidas
Um modelo explícito facilita a aplicação das mesmas regras pela interface, pela API e pelos trabalhos em segundo plano. Um fluxo simples pode usar estados como active, deletion_requested, suspended e closed. Se a suspensão ocorrer ao mesmo tempo que a solicitação, talvez baste um único estado de solicitação e atributos que descrevam suas restrições. Evite adicionar estados que não representem uma diferença operacional real.
Documente as transições válidas. Por exemplo, uma organização ativa pode solicitar o encerramento; uma solicitação vigente pode ser cancelada; e uma solicitação cujo prazo venceu pode avançar para o encerramento final. Em geral, uma organização encerrada não deve ser reaberta pela mesma ação de cancelamento: sua recuperação, se oferecida, exige um procedimento distinto e limites bem definidos.
- Registre quem iniciou a solicitação, quando, por qual canal e quando termina o período.
- Verifique as permissões e o estado atual no servidor, não apenas na interface.
- Rejeite ou trate explicitamente transições repetidas e solicitações concorrentes.
- Armazene as mudanças de estado atomicamente e publique os efeitos colaterais por meio de um padrão confiável, como o padrão de outbox transacional (caixa de saída transacional).
Em uma aplicação PHP, centralize as regras de transição em um serviço de domínio ou camada equivalente. Os controladores não devem alterar vários campos diretamente e presumir que todos os consumidores entenderão a nova semântica. O banco de dados deve manter informações suficientes para que um processo pendente determine qual ação corresponde, sem depender do estado de uma solicitação web anterior.
Limitar acessos e conter processos pendentes
Defina as permissões por papel durante o período de carência. Um administrador poderia ter permissão para cancelar o encerramento e consultar as informações necessárias para exportá-las, enquanto os membros da organização poderiam ficar bloqueados. Se o acesso somente para leitura for permitido, especifique quais recursos ele abrange e se APIs, downloads e funções administrativas continuarão disponíveis. O mesmo controle deve ser aplicado na interface, na API e nos trabalhos automatizados.
Bloquear o login não é suficiente. Tokens de acesso, chaves de API, sessões ativas e credenciais de integrações podem continuar funcionando. Decida quais revogar, quais pausar e quais manter temporariamente. Se as credenciais forem revogadas, registre esse efeito para que a reativação não dependa de segredos que já não existem; pode ser necessário exigir que sejam gerados novamente.
Revise filas e tarefas agendadas: envios, sincronizações, relatórios, webhooks e trabalhos de faturamento, por exemplo. Cada processo deve verificar o estado atual da organização imediatamente antes de executar uma operação com efeitos externos. Trabalhos já enfileirados podem ser cancelados, ficar em espera ou terminar, de acordo com uma política explícita. Não presuma que mudar o estado da conta remova automaticamente mensagens de uma fila distribuída.
O cancelamento de uma tarefa também precisa ser idempotente. Um trabalho repetido após uma falha de rede não deve duplicar uma notificação nem uma operação de encerramento. Use identificadores de evento, chaves de idempotência ou restrições de unicidade adequadas e registre os resultados para distinguir uma tentativa de repetição segura de uma nova ação.
Tornar seguros o cancelamento do encerramento e a reativação
Durante o período de carência, cancelar a solicitação deve ser uma transição definida, não uma rotina que “desfaz tudo” sem verificar o que aconteceu. A operação deve validar se o prazo continua vigente, atualizar o estado uma única vez e restaurar somente as permissões que foram suspensas e que ainda são válidas.
Para evitar duplicações, não recrie indiscriminadamente assinaturas, webhooks, tarefas agendadas, espaços de trabalho nem credenciais. Mantenha identificadores estáveis e marque o estado de cada efeito colateral. Se um componente externo já tiver sido encerrado, a aplicação deve poder reconciliá-lo: confirmar se ainda existe, recriá-lo de forma controlada ou informar que é necessária uma ação manual.
Uma reativação idempotente produz o mesmo estado final mesmo que seja solicitada mais de uma vez. Isso pode ser apoiado por transações para as mudanças locais, operações de atualização em vez de inserções cegas e uma estratégia de tentativas de repetição (retries) para os sistemas externos. Se a operação falhar no meio, registre quais etapas foram concluídas e permita retomá-la sem repetir as que já tiveram sucesso.
Tratar dados, rastreabilidade e encerramento final
O encerramento operacional e a exclusão de dados são decisões diferentes. Defina o que acontece com os dados da organização, os backups, os registros de auditoria e as informações mantidas por obrigações legais ou contratuais. Os prazos e motivos aplicáveis dependem do contexto e da jurisdição; devem ser analisados pelas pessoas responsáveis por privacidade e compliance. Comunique ao cliente o que será excluído, o que será mantido e por quanto tempo, de acordo com a política aplicável.
Quando o período de carência vencer, um processo agendado deve localizar as solicitações pendentes e verificar novamente o estado e a data limite antes de encerrar a conta. Se ocorrer uma falha parcial, o sistema precisa registrar a etapa que falhou e permitir retomá-la. Uma flag closed não comprova, por si só, que as credenciais foram revogadas ou as integrações interrompidas.
Mantenha a rastreabilidade das solicitações, dos cancelamentos, das mudanças de permissões, das execuções finais e dos erros. Restrinja o acesso a esses registros e evite incluir segredos ou dados pessoais desnecessários. Os alertas devem sinalizar casos que ultrapassem o tempo esperado, como organizações com prazo vencido que ainda estão ativas ou encerramentos bloqueados por erros repetidos.
Checklist para testar o fluxo
- Uma pessoa sem permissões não pode solicitar nem cancelar o encerramento.
- Solicitar o encerramento duas vezes não gera datas, eventos ou encerramentos duplicados.
- Os papéis têm exatamente as capacidades previstas durante o período de carência.
- Sessões, tokens, APIs, filas e integrações respeitam o estado da organização.
- Cancelar antes do vencimento restaura o acesso previsto sem duplicar processos nem recursos.
- Uma solicitação vencida não é cancelada por uma solicitação tardia nem encerrada duas vezes.
- Falhas parciais e tentativas de repetição permitem concluir o encerramento sem repetir efeitos externos.
- As regras de retenção e exclusão de dados são verificadas separadamente do bloqueio operacional.
Teste também mudanças simultâneas, atrasos nas filas e erros de provedores externos. A indicação de que o projeto é consistente não é apenas a tela mostrar “conta encerrada”, mas também permissões, processos, credenciais e dados refletirem a mesma decisão, e o sistema conseguir explicar como chegou a esse estado.
