Suspensão e Recuperação

Quando pagamentos falham ou um cliente solicita cancelamento, o sistema segue um caminho estruturado de escalação. Esta página explica o fluxo de suspensão, períodos de carência, opções de recuperação, cancelamento voluntário e retenção de dados.

A linha do tempo de escalação

Suspensão por falha de pagamento

Quando um pagamento de assinatura falha, a resposta do sistema é governada pela PaymentRecoveryPolicy:

Configuração	Padrão	Comportamento
trigger	retry_exhausted	Suspender após todas as tentativas do Stripe falharem
anticipate_suspension	false	Suspender antecipadamente para clientes com histórico ruim
suspended_to_cancelled_days	30	Dias em estado suspenso antes do cancelamento automático
auto_reactivate_on_payment	true	Reativar automaticamente quando o pagamento for compensado

O que acontece quando um entitlement é suspenso:

• O status do entitlement transiciona de active para suspended.
• Os recursos downstream são pausados, não destruídos:
  • PLG: A licença permanece nos sites ativados, mas atualizações e novas ativações são bloqueadas.
  • ENV: O ambiente continua em execução, mas pode ser marcado como somente-leitura ou degradado dependendo da ação do admin.
  • SVC: Novas solicitações de serviço são bloqueadas; solicitações em andamento continuam.
  • Contratos: Permanecem visíveis, mas novos trabalhos não podem ser iniciados.
• O cliente é notificado em cada etapa da escalação.

Período de carência

O período de carência é a janela entre a suspensão e o cancelamento. Durante este tempo:

1. O cliente ainda pode fazer login no portal e ver seus entitlements (marcados como suspensos).
2. O cliente pode atualizar seu método de pagamento e tentar novamente.
3. O sistema envia lembretes configuráveis (governados pela NotificationPolicy).
4. Se o pagamento for recuperado, o entitlement retorna a active automaticamente (quando auto_reactivate_on_payment está habilitado).

O período de carência padrão é de 30 dias. Isso pode ser customizado por Entitlement Class, organização, produto ou entitlement individual via PaymentRecoveryPolicy.

Cancelamento por falha de pagamento

Se o período de carência expirar sem recuperação do pagamento:

1. O entitlement transiciona de suspended para cancelled.
2. Os recursos downstream são desprovisionados conforme a ProvisioningPolicy (configuração deprovision_on_cancel).
3. O cliente é notificado do cancelamento.
4. O período de retenção de dados inicia.

Cancelamento voluntário

Quando um cliente cancela voluntariamente:

1. O cliente (ou admin em seu nome) inicia o cancelamento.
2. A CancellationPolicy determina o que acontece:

Configuração	Padrão	Comportamento
portal_visibility_days	90	Por quanto tempo o entitlement cancelado permanece visível no portal
expired_to_cancelled_days	30	Período de carência de expirado para cancelado
data_retention_days	365	Dias para reter dados operacionais pós-cancelamento
data_action	export_and_delete	O que fazer com os dados após o período de retenção
offer_data_export	true	Oferecer exportação de dados ao cliente

3. Se o entitlement é baseado em assinatura, a WooCommerce Subscription subjacente é cancelada.
4. O entitlement transiciona para cancelled.
5. Se offer_data_export estiver habilitado, o cliente recebe uma oferta de exportação.

Reativação (reconquista)

Mesmo após o cancelamento, um entitlement pode ser reativado:

1. O admin (ou um fluxo automatizado de reconquista) reativa o entitlement.
2. O entitlement transiciona de cancelled de volta para active.
3. Os recursos downstream são reprovisionados.
4. O cliente recupera o acesso imediatamente.

Isso suporta cenários como um cliente retornando após uma pausa, uma disputa de cobrança resolvida a favor do cliente, ou uma campanha promocional de reconquista direcionada a clientes inativos.

O mesmo código de entitlement é reutilizado -- o histórico do cliente é preservado.

Retenção de dados

Após o cancelamento, o tratamento dos dados segue a CancellationPolicy:

Valor de data_action	O que acontece
export_and_delete	Exportação é oferecida ao cliente, depois dados são purgados
archive	Dados são movidos para armazenamento frio, acessíveis sob demanda
retain	Dados são mantidos indefinidamente

Importante: Dados fiscais (faturas, notas fiscais) seguem requisitos legais de retenção (LGPD/legislação tributária) e não são governados pela CancellationPolicy. Esses registros são retidos pelo período legalmente exigido independentemente da configuração da política.

Linha do tempo de notificações

Ao longo do processo de suspensão e recuperação, o cliente recebe notificações:

Evento	Notificação
Falha de pagamento	"Seu pagamento falhou. Por favor, atualize seu método."
Cada tentativa de cobrança	"Tentamos cobrar seu cartão novamente."
Entitlement suspenso	"Seu acesso foi suspenso."
Durante o período de carência	Lembretes configuráveis (ex.: 15, 7, 1 dia antes do cancelamento)
Entitlement cancelado	"Seu acesso foi cancelado."
Exportação de dados disponível	"Sua exportação de dados está pronta para download."

Os canais e a frequência das notificações são governados pela NotificationPolicy. Veja Policies para configuração.

Páginas relacionadas

• Fluxo de Compra e Renovação -- Renovação e recuperação de pagamento
• Ativação de Entitlement -- O que é provisionado (e desprovisionado)
• Atribuição de Licença -- Comportamento específico de suspensão para PLG
• Policies -- Configuração de políticas para recuperação, cancelamento e notificações