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.
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:
- Uma nova tentativa resulta, ou o cliente atualiza o método de pagamento e paga, e a subscrição volta a Active.
- 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).
- 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_urldá 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
- 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.
- 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.
- 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. - 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.
- 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.
- 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.
- 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. - 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.