Todo plano recorrente no Zenamu mantém um registro interno completo de cada evento importante: do momento em que é criado, passando por cada renovação, pausa e cancelamento, até quaisquer reembolsos. Esse registro é o seu histórico completo e a sua rede de segurança para resolver disputas e cuidar da contabilidade. Este artigo explica onde encontrar a atividade de um plano e como interpretar cada tipo de evento.

Onde encontrar a atividade de um plano

Abra os detalhes do plano de um cliente na administração e você verá:

O status atual do plano (ativo, pausado, aguardando pagamento, cancelado e assim por diante), a próxima data de renovação e — se algo falhou — detalhes sobre o período de carência e o pagamento com falha.
A seção Pedidos: uma lista dos documentos emitidos para este plano (data de criação, data de pagamento, status do pagamento, valor, descrição e um link para os detalhes do documento). Esta é a sua principal fonte de informação sobre os pagamentos bem-sucedidos individuais, e também serve de base para a sua contabilidade.

No perfil dele (em Meus planos → detalhes), o cliente vê o mesmo status e a mesma lista de pedidos dele.

Importante: O Zenamu ainda não tem uma tela dedicada de "Histórico de renovações" que detalhe eventos individuais como pausas, mudanças de variante ou correções. Esses eventos ficam armazenados em um registro interno no banco de dados e espelhados no seu Stripe Dashboard (em Subscriptions, Invoices e Events). No app, você tem três lugares para trabalhar diretamente: o status atual do plano, a lista de documentos (Pedidos) e a atividade do cliente, onde os principais eventos são descritos em linguagem simples (renovado, pagamento falhou, pausado ou pausado automaticamente, retomado, cancelado pelo cliente, cancelado do lado do Stripe ou no fim do período). Para a sequência detalhada de cada evento individual, procure no Stripe. Abaixo, descrevemos os tipos de eventos que o sistema registra, para que façam sentido quando você for procurá-los.

Os tipos de eventos que o sistema registra

Todo evento interno tem um tipo, uma data e, muitas vezes, alguns detalhes extras (um valor, um motivo, o ID do registro relacionado no Stripe).

Plano criado (primeira compra)

A primeira compra bem-sucedida de um plano aparece como o plano sendo criado (status ativo, ou brevemente aguardando pagamento) e como o primeiro documento na seção Pedidos. A partir dele, você vê a data, a variante que o cliente escolheu e o primeiro valor cobrado.

Renovação bem-sucedida

O sistema registra cada cobrança recorrente bem-sucedida. Uma renovação inclui:

A data e a hora da renovação.
O valor cobrado.
O período de cobrança que o pagamento cobre (você pode rastrear isso na fatura no Stripe).
O documento emitido (um recibo ou uma fatura), que você encontra na seção Pedidos.

Se o cliente usa um saldo de crédito (que pode vir, por exemplo, de um reembolso anterior emitido como crédito em vez de para o cartão) e ele cobre o pagamento inteiro do período, a renovação ainda passa — o Zenamu a registra internamente e o plano continua — mas nenhum documento contábil é criado para ela. Nada foi cobrado no cartão, então não há nada a documentar. Você não encontrará um documento desse período na seção Pedidos nem na exportação para o seu contador. O crédito do cliente é reduzido pelo preço do período.

Renovação com falha

O sistema registra cada tentativa do Stripe de cobrar um pagamento que não foi bem-sucedida (as tentativas automáticas do Stripe, uma tentativa manual e assim por diante).

A data e a hora da tentativa.
O motivo da falha (o código do banco — saldo insuficiente, recusado, cartão expirado, verificação necessária e assim por diante).

Uma única renovação com falha pode gerar vários registros (o Stripe faz várias tentativas durante o período de carência). O melhor lugar para rastrear essas tentativas e os códigos delas é na fatura no seu Stripe Dashboard.

O início do período de carência é um evento interno separado; além disso, a data em que o período de carência termina (normalmente 7 dias após a falha) aparece direto na administração, como parte do aviso de pagamento com falha no plano.

Plano pausado

Isto é registrado sempre que um plano é pausado. Você consegue ver que um plano está pausado direto pelo status dele na administração. Há dois casos:

Pausa automática (porque o plano do estúdio foi rebaixado). Uma observação explicativa descrevendo esse motivo é salva com o registro.
Pausa manual (pela administração). Esta é salva sem observação — nenhum motivo é registrado.

A atividade do cliente também distingue se o plano foi pausado (manualmente) ou foi pausado automaticamente. Essa diferença é importante, porque determina se o plano renova automaticamente quando você depois voltar ao plano Ultimate (só os planos pausados automaticamente renovam).

Plano retomado

Isto é registrado quando um plano pausado é reativado. O motivo distingue se foi:

"Retomado automaticamente: o estúdio voltou ao Ultimate" — automaticamente, depois que o estúdio voltou ao plano Ultimate.
Uma retomada manual, pela administração ou pelo perfil do cliente.

Mudança de variante

Criada quando um cliente é mudado de uma variante para outra. Na atividade do cliente, o app rotula este evento como Variante alterada.

A data.
Variante antiga → nova variante.
O tipo de mudança — um aumento de preço, uma redução de preço agendada, uma mudança de intervalo de cobrança ou o mesmo preço (a variante foi renomeada e assim por diante).
Dependendo do cenário: para um aumento de preço, aparece uma fatura imediata pela diferença proporcional dos dias restantes (a próxima data de renovação permanece a mesma); para uma redução de preço agendada, nenhum documento é criado no dia em que você muda — a administração mostra um banner "Mudança agendada a partir de {{data}}" no plano, e a mudança só se aplica na próxima renovação; para uma mudança de intervalo de cobrança, o ciclo reinicia e uma única fatura líquida é criada (o novo preço menos um crédito proporcional pela parte não usada do período anterior).

Você consegue ver quem fez a mudança pela atividade do cliente na administração. Ela distingue se o cliente mudou a variante pelo perfil ou se o estúdio fez isso pela administração (para ações do estúdio, o nome do membro da equipe também é salvo).

Mudança de variante agendada cancelada

Quando um cliente (ou o estúdio em nome dele) cancela uma mudança de variante agendada anteriormente (sempre Cenário B — uma redução de preço), o banner de mudança agendada desaparece da administração e o sistema faz uma observação interna do cancelamento. Não há consequências financeiras; o plano simplesmente reverte à variante original, sem rastro.

Situações raras em torno de uma mudança de variante agendada

De vez em quando, um cliente agenda uma redução de preço, mas algo incomum acontece entre o agendamento e o dia da renovação — por exemplo, o estúdio arquiva a variante de destino nesse meio-tempo, ou exclui o grupo. O Zenamu lida com essas situações automaticamente e faz uma observação interna delas.

O que pode acontecer e o que o Zenamu faz:

O que aconteceu	O que o Zenamu faz
O estúdio arquivou a variante de destino antes da renovação	A mudança não é aplicada. O preço reverte à variante original, e o cliente continua como se nunca tivesse agendado a redução.
O estúdio excluiu a variante de destino por completo	Mesmo comportamento do arquivamento.
O estúdio arquivou ou excluiu o grupo inteiro	Mesmo comportamento; o cliente permanece na variante original.
A reversão do preço não dá certo tecnicamente (ex.: uma instabilidade breve do Stripe)	O Zenamu faz uma observação da situação. Você verá um status de aviso no plano, na administração. Nesse caso raro, você pode conferir o preço atual da assinatura do cliente no seu Stripe Dashboard e ajustá-lo manualmente se for preciso.

Essas situações são muito raras (normalmente menos de 1% das mudanças agendadas). Na grande maioria dos casos, a mudança passa exatamente como o cliente pretendeu no dia em que a agendou.

Preço atualizado

O sistema registra quando o estúdio aplicou uma mudança de preço em massa a este cliente. O registro carrega:

A data.
O preço antigo e o novo.
Uma observação de que o novo preço só se aplica na próxima renovação regular.

Plano cancelado

Isto é registrado em qualquer cancelamento — manual (o cliente pelo perfil, o estúdio pela administração, ou pelo portal do cliente Stripe) e automático (pelo Zenamu, depois que o período de carência de 7 dias expira). Você consegue ver que um plano está cancelado direto pelo status dele na administração (ou um banner "Cancelamento no fim do período" com uma data). Além disso, o registro interno carrega:

A data do cancelamento.
O método de cancelamento: no fim do período atual, ou imediatamente.
O motivo do cancelamento (por exemplo, um cancelamento manual no fim do período, um cancelamento imediato ou um cancelamento automático depois que o período de carência expirou). Essa descrição é só para orientação: ela é armazenada internamente em inglês e não é o texto exato que você veria no app.

Você consegue ver quem fez o cancelamento. Tanto pelo registro interno quanto pela atividade do cliente na administração, você consegue saber se o cliente, o estúdio ou o sistema cancelou o plano depois que o período de carência expirou. Para ações tomadas pelo estúdio, o nome do membro da equipe também é salvo. O que o registro não inclui é um link para qualquer reembolso. Você o encontra no seu Stripe Dashboard, em Refunds.

Confirmação de pagamento necessária e reembolsos — esses aparecem de forma diferente

Confirmação de pagamento necessária (3D Secure) em uma renovação é registrada como um evento interno, mas o status do plano permanece Ativo. Quando uma verificação extra é necessária em uma renovação, o Zenamu não o muda para Aguardando pagamento (esse status é reservado para uma primeira compra inacabada; veja o artigo "Status dos planos"). O resultado então aparece como uma renovação com falha (se o cliente não conclui a verificação e o Stripe para de tentar) ou como uma renovação bem-sucedida (se ele a conclui a tempo).

Os reembolsos não são registrados como uma atividade separada do plano. Um reembolso total leva ao cancelamento automático do plano; um reembolso parcial não muda o status do plano. Você encontra o status do próprio reembolso no documento (a seção Pedidos) ou no seu Stripe Dashboard.

Correção de uma verificação interna (eventos raros)

Este tipo de registro anota uma situação em que uma verificação interna no Zenamu encontrou uma divergência entre o próprio estado e o estado no Stripe e a corrigiu ou anotou para resolver depois. Os tipos específicos são:

Pedido de compra pendente — o cliente comprou, o Stripe confirmou, mas o Zenamu não conseguiu criar o pedido interno. O sistema sinaliza o registro para se atualizar depois.
Pedido de renovação pendente — o mesmo, para uma renovação.
Reembolso pendente após uma corrida — o Zenamu cancelou um plano bem no momento em que o Stripe cobrava um pagamento em paralelo. O reembolso automático não aconteceu na hora, mas está anotado para ser resolvido depois.
Mudança de variante pendente — uma mudança de variante não terminou de forma limpa em algum momento.
Mensagem para um plano que não existe mais — o Stripe enviou uma mensagem sobre um plano que não existe mais no Zenamu (o cliente foi excluído).

Esses são, mais ou menos, os cinco mais comuns; o Zenamu usa vários outros marcadores específicos para corridas raras (quando duas coisas acontecem no mesmo instante). Essas correções rodam em segundo plano; uma correção individual normalmente está tudo bem por si só — o problema é o mesmo marcador se repetindo no mesmo plano. Se você estiver lidando com uma situação dessas, entre em contato com o suporte.

Essas correções são informativas e aparecem no sentido de que o status do plano no Zenamu acaba batendo com o Stripe:

Uma correção isolada está tudo bem. Pequenas divergências entre o Stripe e o Zenamu acontecem de vez em quando.
Uma divergência repetida para o mesmo cliente ou estúdio pode apontar para um problema mais profundo. No seu Stripe Dashboard, verifique se a sua conta está restrita (em Account requirements) e se todas as assinaturas recentes desse cliente batem com o que você vê no Zenamu. Se a divergência persistir, você pode ressincronizar manualmente no Stripe (cancelar e criar uma nova assinatura).

Atualizações de status em tempo real

Na administração, o status do plano e a lista de pedidos são atualizados automaticamente, em tempo real. Isso significa que:

Quando o Stripe envia uma mensagem ao Zenamu (um pagamento bem-sucedido, uma falha, um cancelamento), o Zenamu muda o status do plano em poucos segundos e acrescenta qualquer documento novo.
O estúdio vê a mudança sem precisar atualizar a página.

Um cliente, no perfil dele, vê o status atual só depois de atualizar a página. A interface do cliente, em geral, não usa atualizações em tempo real. Se um cliente entrar em contato com o estúdio perguntando por que não vê um pagamento novo, sugira que ele atualize a página. Em algumas situações (logo após um pagamento), o navegador do cliente verifica o status brevemente em segundo plano, mas, como regra: atualizar a página = status atual.

Na maioria dos casos, os dois lados verão as mudanças em poucos segundos a um minuto do evento de fato do lado do Stripe.

Como usar a atividade de um plano na prática

A combinação do status do plano + a lista de pedidos no Zenamu e o seu Stripe Dashboard é útil em várias situações:

Explicar um pagamento específico a um cliente

Quando um cliente escreve "Por que fui cobrado em R$ 300 em 14 de abril?", abra a seção Pedidos no plano dele e você verá:

A data e o status do pagamento.
O valor.
Um link para os detalhes do documento (o recibo). Você pode rastrear o período de cobrança que o pagamento cobre na fatura no Stripe.

Você pode então responder ao cliente com os detalhes exatos.

Entender por que um plano foi cancelado

Você consegue saber que um plano terminou automaticamente após pagamentos com falha pelo status atual dele (cancelado / não pago) e pela falta do pagamento bem-sucedido em Pedidos. Para a linha do tempo das tentativas individuais e a data em que o período de carência terminou (normalmente 7 dias), olhe a assinatura e as faturas correspondentes no seu Stripe Dashboard. O cliente então sabe que teve um período de carência de 7 dias que não usou.

Reembolsar um cliente por um período não usado

Na lista de pedidos, você consegue ver a data do último pagamento bem-sucedido; você consegue ver por quanto tempo o plano é válido pelo status do plano (a próxima data de renovação). Calcule o valor proporcional dos dias não usados e emita o reembolso no seu Stripe Dashboard.

Rastrear cobranças duplicadas

Se um cliente afirma que o Stripe o cobrou duas vezes, abra a seção Pedidos (e, por segurança, as faturas no Stripe também). Você verá ou só um pagamento (e o cliente está enganado) ou dois, caso em que você pode reembolsar um deles.

Documentação para contabilidade

A lista de pedidos bate com o seu Stripe Dashboard, uma a uma. Se o seu contador precisar de comprovante de um pagamento específico, abra os detalhes do documento (e no Stripe você encontra os dados completos de cobrança, vencimento e fiscais).

Perguntas frequentes

Um cliente me diz que não vê o último pagamento dele no perfil. Algumas possibilidades:

Um crédito cobriu o pagamento inteiro (nenhum dinheiro circulou = nenhum documento, veja acima).
O perfil do cliente não atualiza em tempo real — peça que ele tente atualizar a página.
A mensagem do Stripe atrasou; espere um minuto e atualize a página.

Posso exportar a atividade de um plano? Para contabilidade, use a exportação de documentos padrão na administração (ISDOC ou Pohoda XML). Ela contém todas as faturas e cancelamentos que o seu contador precisa. Você não encontrará uma sequência detalhada de eventos individuais (renovações bem-sucedidas e com falha, pausas, mudanças de variante) como um relatório separado no app; esses dados ficam no banco de dados e no seu Stripe Dashboard. Na maioria dos casos, o seu contador não precisa deles — ele trabalha com os documentos.

Posso excluir um registro de evento? Não. Os registros contábeis e históricos não são excluídos nem reescritos depois; só novos são acrescentados ao lado deles. O motivo: o histórico precisa permanecer completo, tanto para fins contábeis quanto para a resolução de disputas.

E se eu vir algo que não espero no Stripe ou no status do plano (por exemplo, o resultado de uma correção de uma verificação interna)? Pode ser uma situação em que uma verificação interna no Zenamu encontrou uma divergência entre o próprio estado e o estado no Stripe e a corrigiu. Se for isolada, está tudo bem (de vez em quando uma mensagem do Stripe se perde, e a rede de segurança interna conserta). Se a divergência persistir para o mesmo cliente, confira o status da assinatura dele no seu Stripe Dashboard e compare com o que você vê no Zenamu. Se realmente não bater, entre em contato com o suporte, ou ressincronize manualmente no Stripe (cancele e crie uma nova assinatura).

Histórico de renovações e atividade do plano