Funcionalidades de retenção do Stripe Billing: o que está incluído e o que não está
Um mapa das ferramentas de retenção do Stripe Billing (novas tentativas, emails, cartões, ofertas no portal, pausa, análises) e das lacunas a preencher.
Por Florian
O Stripe Billing traz mais ferramentas de retenção do que muitas equipas imaginam. Antes de construir ou comprar o que quer que seja, vale a pena saber exatamente o que já está na sua conta, o que faz cada peça e onde para.
Este guia mapeia as funcionalidades incluídas a partir da documentação do Stripe (consultada em novembro de 2026) e depois enumera as lacunas. Já tratámos o calendário das novas tentativas em detalhe em como funcionam as Smart Retries do Stripe, por isso este artigo fica ao nível do conjunto de ferramentas.
As ferramentas incluídas num relance
| Área | O que o Stripe oferece | Onde ler mais |
|---|---|---|
| Novas tentativas | Smart Retries ou um calendário personalizado | Smart Retries |
| Emails ao cliente | Emails de pagamento falhado, de cartão a expirar e de lembrete | Customer emails |
| Workflows | Automatizações sem código (gatilho, filtros, ações) | Automations |
| Atualização de cartões | Card account updater com as redes | Revenue recovery |
| Cancelamento | Página de cancelamento do customer portal, motivos, cupão de retenção | Cancellation page |
| Ofertas direcionadas | Retention rules (private preview) | Retention rules |
| Mudanças de plano | Troca de plano no portal, downgrades no fim do período | Configure the portal |
| Pausa | Pausar uma subscrição ou pausar a cobrança | Pause subscriptions |
| Relatórios | Billing analytics, retention performance, benchmarking | Analytics |
Pagamentos falhados: o que está incluído
Novas tentativas
As Smart Retries escolhem os momentos das novas tentativas com um modelo; o Stripe recomenda 8 tentativas em 2 semanas. Pode mudar para um calendário personalizado. O Stripe não volta a tentar depois de certas hard declines até ser recolhido um novo meio de pagamento. Os detalhes e as definições estão no nosso guia das Smart Retries.
Emails ao cliente
O Stripe pode enviar ao cliente um email depois de cada pagamento falhado, um email um mês antes de um cartão guardado expirar, e lembretes para faturas por pagar e pagamentos à espera de confirmação (por exemplo, um passo de autenticação). Ativam-se nas definições do Billing (customer emails).
Automatizações
As automatizações são workflows sem código construídos a partir de um gatilho (como um pagamento de subscrição falhado, uma fatura em atraso ou um cancelamento), filtros opcionais e ações (como definir uma política de novas tentativas personalizada, marcar uma subscrição como unpaid, marcar uma fatura como uncollectible ou enviar um email à sua equipa) (automations). São úteis para tratar segmentos de forma diferente, por exemplo um período de tolerância mais longo para grandes contas.
Card account updater
O Stripe trabalha com as redes de cartões para atualizar os dados dos cartões guardados quando um cliente recebe um novo número de cartão. Isto evita discretamente uma parte das falhas que de outro modo aconteceriam na expiração. Não ajuda quando a conta bancária por trás do cartão está vazia ou quando o cliente cancelou o cartão de propósito. Veja network tokens e card account updater.
Cancelamentos: o que está incluído
A página de cancelamento do portal
O customer portal pode mostrar uma página de cancelamento com uma lista fixa de motivos (demasiado caro, faltam funcionalidades, mudou para uma alternativa, já não precisa, e outros, mais texto livre). A resposta fica guardada na subscrição em cancellation_details.feedback e é visível no Dashboard, no Sigma e no webhook customer.subscription.updated (cancellation page).
Cupão de retenção e retention rules
Pode associar um cupão de retenção ao passo de cancelamento do portal. Está desativado por defeito. As retention rules, em private preview no momento em que escrevemos, permitem direcionar ofertas por condições como o motivo do cancelamento, a antiguidade e o gasto; ativá-las desativa o cupão de retenção único (retention rules).
Troca de plano e downgrades
Se ativar as atualizações de subscrição no portal, os clientes podem mudar de plano sozinhos. Uma opção “manage downgrades” pode agendar um downgrade para o fim do período de faturação em vez de o aplicar de imediato; o Stripe implementa isto com uma subscription schedule, e só funciona entre preços do mesmo produto (configure the portal).
Pausa
O Stripe documenta dois mecanismos. Uma pausa completa suspende o serviço e a faturação. Pausar a cobrança (pause_collection) mantém a subscrição no seu estado atual e trata as faturas criadas durante a pausa mantendo-as como rascunhos, marcando-as como uncollectible ou anulando-as (pause subscriptions). O nosso guia da pausa no Stripe compara-os.
Relatórios: o que está incluído
O Billing analytics dá-lhe o MRR, uma evolução do MRR (novo, reativação, expansão, contração, churn, ajuste cambial), a receita perdida, o churn de subscritores e uma vista de retenção por coorte. Vale a pena conhecer algumas definições antes de comparar os números do Stripe com os seus:
- A taxa de churn de subscritores é medida numa janela móvel de 30 dias, e o seu denominador inclui os subscritores ativos no início mais os novos subscritores durante a janela.
- A receita perdida inclui tanto o churn voluntário como o churn por pagamentos falhados.
- Pode configurar se os descontos são excluídos do MRR e se um cancelamento conta como churn de imediato ou no fim do período.
A retention performance só reporta os cancelamentos feitos através do portal, e só conta uma retenção se o cliente se mantiver subscrito pelo menos 7 dias depois de aceitar uma oferta. Os cancelamentos feitos através da sua equipa de suporte ou da sua própria app não estão incluídos.
O que não está incluído
É aqui que escreve código, aceita a limitação ou usa uma ferramenta à parte. Enumeramos o que não conseguimos encontrar na documentação do Stripe Billing; se o Stripe acrescentar algo, a sua documentação prevalece.
Mensagens de recuperação ajustadas à recusa
O email de pagamento falhado do Stripe sai depois de cada tentativa falhada. Não encontrámos nenhuma opção documentada para variar a mensagem consoante o motivo da recusa, e no entanto uma recusa por saldo insuficiente e um cartão expirado pedem palavras diferentes: uma pede ao cliente que espere ou mude de cartão, a outra que introduza um cartão novo. Se quer uma mensagem por motivo de recusa ou por segmento, envia-a você mesmo a partir dos eventos de webhook invoice.payment_failed.
Uma oferta por motivo de cancelamento, sem a preview
Sem as retention rules, o portal tem um único cupão para todos. “Não o uso o suficiente” resolve-se normalmente melhor com uma pausa; “demasiado caro” com um downgrade. Ajustar as ofertas aos motivos é o centro de um bom fluxo de cancelamento.
Um fluxo de cancelamento na sua própria app
O portal é uma página alojada pelo Stripe. Se os clientes cancelam dentro da sua app web, de uma app desktop ou de uma app móvel, é você que constrói os ecrãs e chama a API Subscriptions, incluindo os motivos, a lógica das ofertas e o botão “cancel now”.
Reconquista depois do fim da subscrição
Depois de uma subscrição ser cancelada, não encontrámos nenhuma sequência incluída que escreva ao antigo cliente a intervalos definidos consoante o motivo da saída. Mantém o objeto Customer e o motivo, mas enviar o que quer que seja fica a seu cargo. Veja como reconquistar subscritores cancelados no Stripe.
Score de risco com os seus próprios dados
O Stripe vê os pagamentos. Não vê a utilização do seu produto, os seus tickets de suporte nem os atributos que recolhe na inscrição, por isso não lhe pode dizer quais dos seus clientes parecem prestes a cancelar, nem que atributos andam a par do churn. Essa análise precisa dos seus dados cruzados com os dados de faturação; o nosso guia para prever o churn com dados de clientes mostra o método.
Uma vista única entre fontes
Se parte da sua receita vem da App Store, do Google Play ou de outra ferramenta de faturação, as análises do Stripe só mostram a parte do Stripe.
As ferramentas incluídas chegam?
Para muitos produtos em fase inicial, sim. Uma configuração mínima razoável:
- Smart Retries ativas, com uma ação de fim de tentativas escolhida de propósito.
- Emails de pagamento falhado e de cartão a expirar ativos.
- Página de cancelamento do portal ativa, com recolha de motivos.
- Downgrades agendados para o fim do período se tiver mais do que um plano.
- Um olhar mensal sobre a receita perdida, dividida entre churn voluntário e pagamentos falhados.
Provavelmente precisa de mais quando os cancelamentos acontecem dentro da sua própria app, quando quer ofertas diferentes por motivo, quando os pagamentos falhados são uma grande parte do churn, ou quando quer agir junto dos clientes antes de chegarem ao botão de cancelar.
Fazer isto com o NoChurn
O NoChurn conecta-se ao Stripe com um clique e acrescenta o que a lista acima deixa de fora. Para os pagamentos falhados, faz novas tentativas inteligentes ajustadas ao motivo da recusa e ao dia de salário, envia emails de recuperação escritos pela IA que pode rever e inclui um link para uma página alojada de atualização do cartão. Para os cancelamentos, gere fluxos de cancelamento com motivos e uma oferta por motivo (desconto, pausa ou mudança de plano), com um cancelamento num clique sempre visível, como modal alojado ou através de uma API headless na sua própria app. Depois de um cancelamento, envia emails de reconquista aos 30, 60 e 90 dias consoante o motivo. Dá também a cada cliente um score de churn de 0 a 100 na inscrição e em cada alteração, e aceita os seus próprios dados pela API para mostrar os fatores de churn (correlação, não causalidade).
Todas as funcionalidades estão em todos os planos (o seu próprio domínio de email desde $9), com preço apenas pelo MRR, e nunca como uma parte da receita recuperada. Veja preços.