Como funcionam as Smart Retries do Stripe, e quando personalizar o calendário
Como as Smart Retries do Stripe escolhem os momentos, as definições que controla, as recusas nunca repetidas e quando é melhor um calendário próprio.
Por Florian
Quando um pagamento de subscrição falha no Stripe Billing, o Stripe pode voltar a tentar a cobrança automaticamente. As Smart Retries são a definição que decide quando. É a opção recomendada pelo Stripe, e muitas equipas ativam-na e nunca mais olham para ela.
Na maioria dos casos, não há problema. Mas ajuda saber o que as Smart Retries fazem realmente, o que não conseguem fazer, e as poucas situações em que deve mudar os valores por defeito. Este artigo baseia-se no que diz a documentação do Stripe e indica onde o Stripe não publica detalhes.
O que são as Smart Retries
As Smart Retries são a lógica automática do Stripe para voltar a tentar pagamentos de faturas falhados. Em vez de tentar em dias fixos (por exemplo 3, 5 e 7 dias depois da falha), o Stripe usa um modelo para escolher quando corre cada nova tentativa. A documentação do Stripe descreve o modelo como usando sinais dinâmicos e dependentes do tempo para escolher os melhores momentos.
O que o Stripe não publica é a lista exata de sinais, os seus pesos, nem os intervalos que escolherá para um dado pagamento. Trate as Smart Retries como uma caixa negra com alguns botões à volta.
Onde se aplicam
As Smart Retries aplicam-se às faturas que o Stripe cobra automaticamente, o que cobre a maioria das renovações de subscrições. As faturas que envia para pagamento manual (em que o cliente paga ele próprio a fatura) seguem antes as regras de cobrança automática, que é uma configuração diferente.
O Stripe documenta também as Smart Retries para pagamentos off-session fora do Billing. Consulte essa página para ver a disponibilidade na sua conta, que pode ser limitada.
As definições que controla
No Dashboard do Stripe, as definições de novas tentativas estão na secção de revenue recovery das definições do Billing. Os controlos são:
| Definição | Opções | Recomendação do Stripe |
|---|---|---|
| Política de novas tentativas | Smart Retries ou um calendário personalizado | Smart Retries |
| Número de tentativas (Smart Retries) | Configurável | 8 tentativas |
| Janela de tentativas (Smart Retries) | 1 semana, 2 semanas, 3 semanas, 1 mês ou 2 meses | 2 semanas |
| Calendário personalizado | Até 3 tentativas, cada uma um número definido de dias depois da anterior | n/a |
| Depois de falhar a última tentativa | Cancelar a subscrição, marcá-la como unpaid ou deixá-la past due | À sua escolha |
O valor por defeito “8 tentativas em 2 semanas” vem da página de Smart Retries do Stripe. Os rótulos no seu Dashboard podem variar ligeiramente com o tempo, por isso consulte a página diretamente.
O que significam as opções de fim de tentativas
- Cancelar a subscrição. A subscrição termina. O cliente tem de começar uma nova para voltar.
- Marcar a subscrição como unpaid. A subscrição mantém-se, mas o Stripe deixa de tentar cobrar as novas faturas até a situação ser resolvida. Útil se quer manter a conta e restaurar o acesso assim que o cliente pagar.
- Deixar a subscrição past due. A subscrição continua a funcionar e a gerar faturas. É a opção mais tolerante, e pode acumular faturas por pagar se não agir.
À parte, decide o que acontece à própria fatura por pagar (por exemplo, deixá-la em aberto ou marcá-la como uncollectible). Faça as duas escolhas de propósito; mudam a forma como os seus números de MRR e de churn aparecem.
O que as Smart Retries não fazem
Não voltam a tentar as hard declines sozinhas
Algumas recusas significam que o cartão simplesmente não pode voltar a ser cobrado. A documentação do Stripe enumera os hard decline codes para os quais não pode voltar a tentar automaticamente:
incorrect_numberlost_cardpickup_cardstolen_cardrevocation_of_authorizationrevocation_of_all_authorizationsauthentication_requiredhighest_risk_leveltransaction_not_allowed
Para estes, o Stripe continua a agendar novas tentativas e o attempt_count da fatura continua a subir, mas a cobrança só é efetivamente feita quando for associado um novo meio de pagamento. Por outras palavras, o calendário de novas tentativas está à espera do cliente. Se ninguém pedir um cartão novo ao cliente, nada acontece.
Não falam com o cliente
As novas tentativas são silenciosas. Não dizem ao cliente que algo está mal. O Stripe pode enviar emails ao cliente separados quando os pagamentos com cartão falham, e um link para confirmar os pagamentos quando o banco exige autenticação. Essas definições são independentes das Smart Retries, por isso verifique que estão ativas.
Não conhecem os seus clientes
O modelo trabalha com sinais de pagamento. Não sabe que os seus clientes são sobretudo professores pagos no último dia útil do mês, que um cliente acabou de escrever ao suporte a dizer que mudou de banco, ou que a equipa financeira de um cliente B2B só paga às terças-feiras. Esse contexto está nos seus sistemas, não nos do Stripe.
Como ver o que as Smart Retries estão a fazer
Pode acompanhar as novas tentativas em dois sítios:
- No Dashboard, abra a fatura. A cronologia mostra cada tentativa e o seu decline code, e a próxima tentativa agendada.
- Pela API e pelos webhooks. O objeto Invoice tem os campos
attempt_countenext_payment_attempt. Ouçainvoice.payment_failedpara reagir a cada falha, einvoice.paidpara parar qualquer seguimento quando o pagamento é bem-sucedido.
Um registo simples de cada falha (decline code, número da tentativa, montante, data, se foi paga mais tarde) chega para medir o desempenho das novas tentativas no seu caso. Veja a secção de medição do guia completo dos pagamentos falhados para as fórmulas.
Quando personalizar o calendário das novas tentativas
As Smart Retries são uma boa opção por defeito. Eis os casos em que vale a pena reconsiderar.
1. Os seus clientes recebem em datas previsíveis
Se a maioria dos seus clientes são consumidores do mesmo país, muitas soft declines serão insufficient_funds perto do fim do mês. Uma nova tentativa logo depois dos dias de salário habituais (por exemplo o dia 1, o dia 15 ou o último dia útil, consoante o país) pode resultar melhor do que um modelo treinado com toda a gente. Não pode informar as Smart Retries sobre os dias de salário, por isso isto implica um calendário personalizado ou uma lógica de novas tentativas fora do Stripe.
2. O seu ciclo de faturação é curto
Nos planos semanais, uma janela de novas tentativas de 2 semanas significa que a fatura seguinte é criada antes de a anterior ficar resolvida. Encurte a janela, ou use um calendário personalizado com menos tentativas, mais próximas.
3. Vende a empresas
As falhas B2B têm mais a ver com um cartão que foi substituído, um limite de despesas ou um processo financeiro, e menos com o momento. Menos tentativas e um contacto mais cedo com a pessoa certa (muitas vezes não o utilizador que se inscreveu) tendem a contar mais do que um calendário de tentativas preciso.
4. Precisa de uma cronologia previsível
Um calendário personalizado facilita alinhar os emails com as novas tentativas (“vamos tentar de novo na quinta-feira”) e explicar o processo ao suporte. As Smart Retries são, por natureza, menos previsíveis.
5. Quer um período de tolerância mais longo para clientes valiosos
As definições de novas tentativas do Stripe aplicam-se a toda a conta. Se quer uma janela mais longa para clientes anuais ou antigos, precisa de lógica própria, como pausar o fluxo por defeito para esses clientes e tratá-los à parte.
Smart Retries vs um calendário personalizado
| Smart Retries | Calendário personalizado | |
|---|---|---|
| Momentos | Escolhidos pelo modelo do Stripe | Dias fixos que define |
| Número de tentativas | Configurável (8 recomendadas) | Até 3 |
| Janela | De 1 semana a 2 meses | Soma dos seus intervalos |
| Usa os dados dos seus clientes | Não | Não, mas escolhe as datas a pensar neles |
| Previsível para emails e suporte | Menos | Sim |
| Esforço | Nenhum | Baixo |
Se construir a sua própria lógica de novas tentativas (por exemplo, tentativas ajustadas à hora local e ao dia de salário do cliente), em geral desativa as novas tentativas automáticas do Stripe para essas faturas, para que as duas não entrem em conflito. Teste isto com cuidado primeiro em modo de teste.
Uma configuração prática para a maioria das equipas SaaS
- Mantenha as Smart Retries ativas, com as 8 tentativas em 2 semanas recomendadas para os planos mensais.
- Defina de propósito a ação de fim de tentativas. “Marcar como unpaid” é um bom meio-termo se quer manter a conta e restaurar o acesso com o pagamento.
- Ative pelo menos os emails de pagamento falhado do Stripe, ou melhor, faça a sua própria sequência de recuperação aos dias 0, 3, 7 e 14.
- Trate as hard declines de forma diferente: peça um cartão novo de imediato.
- Ative os emails de autenticação se vende na Europa.
- Registe cada falha e meça a recuperação por coorte.
- Reveja as definições quando tiver alguns meses de dados. Se a maioria das suas falhas forem
insufficient_fundsno fim do mês, teste um calendário alinhado com os dias de salário.
Como o NoChurn ajuda
O NoChurn funciona ao lado do Stripe. Pode manter as Smart Retries do Stripe, ou deixar o NoChurn voltar a tentar os pagamentos falhados em momentos baseados nos prováveis dias de salário e na hora local do cliente. Em qualquer dos casos, envia emails de recuperação escritos pela IA (dias 0, 3, 7 e 14 por defeito) no idioma do cliente, revistos antes do envio, com um link para uma página alojada de atualização do cartão. Os dados do cartão ficam no Stripe; o NoChurn nunca vê números de cartão.
Conecta-se ao Stripe com um clique. O preço depende apenas do MRR, com todas as funcionalidades em todos os planos (o seu próprio domínio de email desde $9) e nenhuma parte da receita recuperada. Veja pagamentos falhados e preços.