RECUPERAÇÃOMAXIO

Como reduzir o churn involuntário no Maxio

Como o Maxio (antigo Chargify) trata os pagamentos falhados: calendários de dunning, novas tentativas, past due e unpaid, Billing Portal e webhooks.

Publicado a 7 min de leitura

O churn involuntário é a parte do churn que ninguém escolheu: uma renovação falha, ninguém corrige o método de pagamento e a subscrição termina. O Maxio Advanced Billing (antigo Chargify) dá-lhe de forma nativa a maioria das ferramentas para o evitar: um calendário de dunning configurável, novas tentativas e emails por passo, uma ação final, um Billing Portal onde os clientes atualizam o cartão e webhooks para cada passo. Este guia explica como essas peças se comportam e como configurá-las bem.

Todo o comportamento do Maxio descrito aqui vem da documentação do próprio Maxio: Understanding how dunning works, Configure credit card dunning, Configure ACH dunning, Configure direct debit dunning, Update subscription payment method, Dunning email parameters e Webhook events (todos consultados em novembro de 2026).

O que acontece quando uma renovação falha no Maxio

Quando o período de uma subscrição termina, o Maxio tenta cobrar o método de pagamento registado. Se o processador recusar, a subscrição passa a Past Due e o Maxio começa a seguir o seu calendário de dunning. A partir daí, há três resultados possíveis:

  1. Uma nova tentativa resulta, ou o cliente atualiza o método de pagamento e paga, e a subscrição volta a Active.
  2. O calendário esgota-se e aplica-se a ação final: a subscrição é Canceled (deixa de acumular cobranças) ou marcada Unpaid (continua a acumular cobranças).
  3. Intervém manualmente, por exemplo registando um pagamento.

Uma subscrição Unpaid pode voltar a Active: a documentação do Maxio descreve o uso de Retry/Reactivate para cobrar o pagamento, ou Reset to $0 para perdoar o saldo.

Alguns casos comportam-se de forma diferente, segundo a visão geral do dunning:

  • As subscrições pré-pagas não são marcadas como past due. Ficam ativas enquanto o saldo durar e depois são suspensas.
  • As subscrições com prazo cujo prazo termina durante o dunning expiram em vez de ficarem past due, e não são canceladas mais tarde se o dunning se esgotar.
  • As subscrições com pagamento manual (faturadas) recebem emails de lembrete, mas o dunning não volta a tentar as faturas em aberto.
  • As recusas de alto risco ou por fraude desativam o perfil de pagamento em vez de continuar as novas tentativas.

O calendário de dunning

O dunning está em Config, depois Retries & Dunning. O Maxio organiza-o em definições de email, o calendário de novas tentativas e de dunning, e o passo final. Os emails de dunning configuram-se aqui, separados dos outros emails do seu site.

Limites e regras por método de pagamento

Método de pagamento Regra da documentação do Maxio
Cartão de crédito Até 365 dias e/ou 30 passos por calendário
ACH 2 novas tentativas mais 1 ação final, segundo as regras da rede ACH
Débito direto Pelo menos 5 dias entre novas tentativas; a ação final não pode tentar de novo
Pagamento manual Apenas emails de lembrete, sem novas tentativas

Pode definir estratégias para todo o site por método de pagamento, e estratégias por produto ou família de produtos ao lado delas, para que um plano empresarial anual não tenha de partilhar o calendário com um plano mensal em self-service.

Passos: nova tentativa, email, ou ambos

Cada passo do calendário tem um número de dia e dois interruptores:

  • Retry Payment: tentar a cobrança nesse dia. Pode desativá-lo para enviar um email sem nova tentativa, exceto no passo do Dia 1, que tenta sempre.
  • Send Email: os modelos predefinidos começam com os emails desativados, por isso precisa de ativar cada email que quer e editar o assunto e o corpo.

Como o Maxio acompanha o passo atual

O Maxio calcula o passo atual de uma subscrição a partir do tempo que está em past due e do seu calendário atual, em vez de guardar o passo. A consequência prática, indicada na documentação: editar o calendário pode mudar o passo em que uma subscrição em past due parece estar. Faça as alterações ao calendário de forma deliberada, e conte que as subscrições já em dunning sigam o novo calendário.

Note também: se uma subscrição chega à sua data normal de renovação enquanto está em dunning e não há nenhum passo de dunning nesse dia, a renovação corre na mesma. Se falhar, a subscrição fica em dunning e continua com o passo seguinte.

Levar o cliente a atualizar o método de pagamento

A maior parte da receita recuperada de recusas definitivas e de cartões expirados vem de o cliente introduzir novos dados. O Maxio oferece várias formas de o levar lá, segundo a sua documentação sobre atualizar o método de pagamento e os parâmetros dos emails de dunning:

  • Nos emails de dunning: uma variável update_url dá o URL que o cliente pode usar para atualizar o método de pagamento. Se usa o Billing Portal, os modelos podem antes remeter para a página de gestão do portal.
  • A partir da página da subscrição: o separador Payment Details tem uma ação para enviar ao cliente, por email, um link para a sua página de self-service, e pode também copiar o URL da página de self-service para o enviar você mesmo.
  • No Billing Portal: os clientes iniciam sessão, selecionam a subscrição, escolhem atualizar o método de pagamento, escolhem um método guardado ou acrescentam um novo, e guardam. O portal tem também um padrão de URL direto para a página de atualização do método de pagamento de uma dada subscrição.

Dois limites a conhecer:

  • Enquanto um pagamento está pendente (por exemplo um débito direto ainda não liquidado), o método de pagamento não pode ser alterado, nem mesmo na página de self-service.
  • Os emails de dunning só são enviados enquanto uma subscrição está past due; não são processados para subscrições expiradas ou canceladas. Tudo o que quiser enviar depois da ação final precisa de outro canal.

Webhooks a ligar à sua app

A referência dos eventos de webhooks do Maxio lista os eventos de que precisa para refletir o estado do dunning no seu produto:

Evento O que lhe diz O que fazer
payment_failure Uma tentativa de pagamento falhou, incluindo as novas tentativas Mostrar um banner na app, registar a tentativa
payment_success Um pagamento resultou, incluindo as novas tentativas Retirar o banner
dunning_step_reached A subscrição chegou a um passo de dunning (o payload inclui o passo atual e o seguinte) Programar os seus próprios lembretes ou avisos na app
subscription_state_change O estado da subscrição mudou Voltar a ler o estado, depois dar ou retirar o acesso

O Maxio nota que um pagamento que regulariza uma conta em past due gera payment_success e subscription_state_change, mas não renewal_success. Se a sua app só ouve os eventos de renovação, vai falhar as recuperações. O Maxio tenta entregar cada webhook até seis vezes (guia de webhooks), por isso faça com que os seus handlers sejam idempotentes.

Um plano de configuração

  1. Ajuste o calendário ao período de faturação. Nos planos mensais, termine o dunning antes da renovação seguinte para não acumular períodos por pagar. Os planos anuais podem permitir-se uma janela mais longa.
  2. Concentre as novas tentativas e os emails no início. Tente de novo no dia 1, depois de poucos em poucos dias nas primeiras duas semanas, enquanto o cliente ainda se lembra de usar o produto.
  3. Ative os emails. Começam desativados. Escreva um primeiro email curto com o link update_url, dois ou três lembretes e um aviso final que indique a data em que o acesso termina.
  4. Separe as estratégias por produto quando os públicos são diferentes. Os clientes empresariais precisam muitas vezes de uma janela mais longa e de um contacto humano, não de mais emails automáticos.
  5. Escolha a ação final de propósito. Cancel para de acumular cobranças; Unpaid continua a acumulá-las, o que só faz sentido se tenciona cobrar o saldo.
  6. Respeite as regras do ACH e do débito direto. Não desenhe um calendário ao estilo dos cartões para pagamentos bancários; o Maxio impõe os limites de qualquer forma.
  7. Reflita o estado com webhooks, com base em subscription_state_change, e mostre um banner dentro do seu produto enquanto a subscrição está past due.
  8. Reveja todos os meses as subscrições canceladas por falta de pagamento e procure padrões: um produto, um gateway, um tipo de cartão.

Fazer isto com a NoChurn

O dunning do Maxio mantém-se: as novas tentativas, a faturação, os impostos e a cobrança em si ficam no Maxio e no seu gateway. A NoChurn liga-se com uma chave de API do Maxio, importa clientes e subscrições, acompanha os webhooks do Maxio e acrescenta emails de recuperação escritos por IA que revê antes de saírem, com um link para atualizar o perfil de pagamento. Além do dunning, acrescenta fluxos de cancelamento com motivos, ofertas (um cupão ou uma mudança de produto na subscrição Maxio) e um cancelamento num clique sempre visível, emails de reconquista aos dias 30, 60 e 90 com base no motivo do cancelamento, e um churn score de 0 a 100. As disputas vêm do gateway por trás do Maxio; com o Stripe ou o Braintree, a NoChurn reúne as provas e redige uma resposta para rever. Veja NoChurn + Maxio.

PROMPT

Read https://www.nochurn.sh/llms.txt,
then follow https://www.nochurn.sh/docs/quickstart/
to add NoChurn to this app. Use a test key
(nc_test_…) until I say we go live.

Pare de perder receita.

  • Grátis até $300 de MRR
  • Sem cartão
  • Pronto em 10 minutos
  • Nunca uma comissão sobre o que recuperamos