Reembolsos e Cancelamentos

Reembolsos e cancelamentos afetam diretamente o status dos entitlements e os recursos downstream. Esta página explica cada cenário e como as políticas de Refund e Cancellation governam o comportamento.

Fluxo de reembolso e cancelamento

Reembolso total

Quando um pedido WooCommerce é totalmente reembolsado:

1. Todos os entitlements vinculados a esse pedido são movidos para o status Cancelled.
2. Recursos downstream são desativados:
   • PLG: Chaves de licença revogadas, acesso a download removido
   • ENV: Acesso ao ambiente suspenso, marcado para descomissionamento
   • SVC: Contrato de serviço encerrado, créditos restantes perdidos (conforme credits_on_refund: forfeit)
3. O dashboard da organização reflete a mudança imediatamente.
4. Uma notificação é enviada à organização confirmando o cancelamento.

A Refund Policy controla se isso acontece automaticamente ou requer aprovação do admin:

Configuração	Padrão	Descrição
refund_window_days	30	Quantos dias após a compra o reembolso é permitido
auto_refund	false	Se reembolsos são processados automaticamente (dentro do auto_refund_max)
auto_refund_max	100.00	Valor máximo para processamento automático de reembolso
cancel_entitlement	true	Se o entitlement é automaticamente cancelado após reembolso total
credits_on_refund	forfeit	O que acontece com os créditos: forfeit, retain ou proportional
approval_required	admin	Quem deve aprovar: admin ou none

Janelas de reembolso por classe

Diferentes Entitlement Classes possuem diferentes janelas de reembolso padrão:

Classe	Janela de reembolso padrão	Justificativa
PLG	30 dias	Período padrão de reembolso de software
ENV	30 dias	Período padrão de reembolso
SVC	0 dias	Contratos de serviço não são reembolsáveis por padrão
ORD	30 dias	Período padrão de reembolso
EDU	7 dias	Serviço já consumido (treinamento entregue)
AFL	30 dias	Período padrão de reembolso

Estes são padrões de nível de classe que podem ser sobrescritos por organização, produto ou entitlement individual.

Reembolso parcial

Reembolsos parciais não alteram automaticamente o status do entitlement. O entitlement permanece ativo. O admin pode:

• Revisar o reembolso parcial e decidir se ajusta o entitlement
• Fazer downgrade do tier do entitlement se o reembolso reflete acesso reduzido
• Deixar o entitlement inalterado se o reembolso foi por outro motivo (frete, correção de imposto, cortesia)

O comportamento de reembolso parcial pode ser personalizado através da Policy Engine em versões futuras.

Cancelamento voluntário (pelo cliente)

Quando um cliente cancela uma assinatura pelo portal:

1. O status da assinatura WooCommerce muda para Pending Cancellation.
2. O entitlement permanece Active até o fim do período de cobrança atual.
3. No fim do período, o entitlement transiciona para Expired.
4. O portal_visibility_days da Cancellation Policy (padrão: 90 dias) controla por quanto tempo o entitlement expirado permanece visível no portal do cliente.
5. Após expired_to_cancelled_days (padrão: 30 dias), o entitlement é automaticamente cancelado.
6. Se offer_data_export está habilitado (padrão: true), é oferecida ao cliente uma exportação de dados antes do cancelamento final.
7. Após data_retention_days (padrão: 365 dias), dados operacionais são purgados. Dados fiscais são retidos conforme requisitos legais.

O cliente pode reativar ("win-back") durante o período expirado iniciando uma nova assinatura, que reutiliza o mesmo código de entitlement.

Cancelamento pelo admin

Um admin pode cancelar um entitlement a qualquer momento pelo painel admin do WordPress. Isso:

1. Move imediatamente o entitlement para o status Cancelled.
2. Desativa todos os recursos downstream.
3. Cancela a assinatura WooCommerce associada (se aplicável).
4. Envia uma notificação à organização.

O cancelamento pelo admin ignora o período de carência e a linha do tempo de retenção.

Tratamento de chargeback / disputa

Quando o Stripe reporta um chargeback ou disputa de pagamento:

1. O entitlement vinculado ao pagamento disputado é movido para Suspended.
2. O admin é notificado da disputa.
3. O admin pode fornecer evidências ao Stripe para contestar o chargeback.
4. Se a disputa for ganha: O entitlement retorna para Active.
5. Se a disputa for perdida: O entitlement é movido para Cancelled e o reembolso é processado.

O tratamento de chargeback é semi-automatizado — o sistema suspende o entitlement imediatamente, mas depende do admin para gerenciar o processo de disputa no Stripe.

Retenção de dados após cancelamento

Tipo de dado	Período de retenção
Operacional	365 dias após cancelamento (configurável)
Fiscal (faturas, notas fiscais)	Mínimo legal (não configurável)
Registro do entitlement	Retido indefinidamente (trilha de auditoria)
Recursos downstream (ambientes, arquivos)	Purgados após período de retenção de dados

Páginas relacionadas

• Pedidos e Entitlements -- pipeline pedido-para-entitlement
• Renovações -- mecânica de renovações
• Mapeamento de Status de Pagamento -- mapeamento completo de status
• Impostos e Faturas -- implicações de reembolsos nas faturas