Como funcionam os pagamentos falhados no Paddle Billing e o que pode acrescentar

Quando uma renovação falha no Paddle Billing, muita coisa acontece sem si: o Paddle é o merchant of record, volta a tentar o pagamento e pode enviar um email ao cliente. É uma vantagem real face a construir você mesmo os emails de recuperação. Também quer dizer que precisa de saber exatamente o que o Paddle faz, para não o duplicar nem deixar lacunas.

Este guia explica como o Paddle Billing trata um pagamento de subscrição falhado, o que o Paddle Retain acrescenta, como os clientes atualizam os dados de pagamento e as partes que pode melhorar você mesmo. Baseia-se na documentação do próprio Paddle: o changelog sobre dunning por omissão, configure Payment Recovery and dunning, Payment Recovery, update payment details e o artigo de ajuda do Paddle sobre a cadência de novas tentativas do Retain (todos consultados em novembro de 2026).

O que acontece quando uma renovação falha

Para uma subscrição cobrada automaticamente, o guia de dunning do Paddle descreve a sequência:

1. O pagamento da transação de renovação falha.
2. O estado da subscrição passa a past_due.
3. O Paddle envia transaction.payment_failed para a tentativa e depois transaction.past_due e subscription.past_due quando a transação e a subscrição ficam em atraso.
4. O Paddle volta a tentar o pagamento.
5. Se uma nova tentativa tiver sucesso, a subscrição volta a active e deixa de estar em atraso.

Novas tentativas por omissão, com ou sem Retain

O changelog de 2025 do Paddle tornou as novas tentativas automáticas após falhas de pagamento disponíveis para todos os utilizadores do Paddle Billing. Os pagamentos falhados nas subscrições cobradas automaticamente são tentados de novo até sete vezes ao longo de 30 dias, mesmo que não tenha ativado o Paddle Retain.

Vale a pena conhecer dois limites:

• Só contas live. O Paddle diz que as novas tentativas automáticas só correm em contas live. Não há novas tentativas em sandbox, por isso não pode testar lá o calendário completo.
• Só cobrança automática. Nas subscrições cobradas manualmente (pagas por fatura), o Paddle Retain não faz nada quando estão em atraso. O Paddle passou essas subscrições para past_due em 2024, mas persegui-las cabe-lhe a si.

O que acontece no fim da janela

Segundo o artigo de ajuda do Paddle sobre a cadência de novas tentativas, é você que define o que acontece a uma subscrição quando termina a janela de recuperação: cancelá-la, pausá-la ou deixá-la em atraso. Por omissão, é cancelada após 30 dias, e a janela pode ser ajustada no dashboard do Paddle.

Escolha de forma deliberada. Cancelar é limpo para os relatórios. Pausar mantém a subscrição para que o cliente possa voltar sem novo checkout. Deixá-la em atraso mantém a porta aberta, mas pode deixar clientes com acesso pelo qual não estão a pagar, a menos que a sua app verifique o estado.

O que o Paddle Retain acrescenta

O Payment Recovery faz parte do Paddle Retain. Para além das novas tentativas por omissão, a documentação do Paddle descreve:

Funcionalidade	O que o Paddle diz que faz
Tactical Retries	Volta a tentar os pagamentos falhados em momentos escolhidos a partir do tipo de método de pagamento, da localização do cliente e de outros dados
Emails de recuperação	Até quatro emails de recuperação de pagamento
Outros canais	Lembretes de pagamento na app e por SMS
Fim do dunning	Pode pausar ou cancelar subscrições automaticamente quando todas as tentativas se esgotam

Por omissão, o dunning do Retain corre durante 30 dias. Verifique no seu dashboard do Paddle se o Payment Recovery está ativado na sua conta antes de assumir que algo disto se aplica.

Se usa o Retain, deixe-o tratar das novas tentativas e dos emails. Correr um segundo calendário de novas tentativas sobre o mesmo cartão acrescenta tentativas sem acrescentar informação, e duas sequências de emails de recuperação na mesma caixa de entrada parecem spam.

Deixar os clientes atualizar os dados de pagamento

A maioria das recusas definitivas só se recupera quando o cliente lhe dá um novo cartão. O guia update payment details do Paddle lista as opções:

1. Customer portal. O portal do Paddle está ativo por omissão e permite aos clientes atualizar o método de pagamento sem ecrãs seus.
2. Sessão do customer portal. Pode criar um deep link autenticado que leva diretamente à página de atualização do método de pagamento de uma subscrição específica, para que o cliente não tenha de iniciar sessão.
3. URL de gestão da subscrição. O Paddle devolve, para cada subscrição, um link update_subscription_payment_method que pode mostrar na sua app.
4. Transação de atualização do método de pagamento. Chame GET /subscriptions/:id/update-payment-method-transaction. Quando a subscrição está past_due, devolve a transação em atraso mais recente. Abra o seu checkout.url ou passe o ID da transação ao Paddle.js. Só funciona quando collection_mode é automatic.

Há um passo de configuração que apanha muita gente: o link de pagamento por omissão tem de estar definido na sua conta Paddle e aprovado antes de os clientes poderem atualizar os dados de pagamento. O Paddle também o usa nos seus emails de recuperação.

Quando uma subscrição em atraso é paga após uma atualização, o Paddle envia subscription.activated e o estado volta a active.

Uma configuração prática

Use ou não o Retain, estes passos fecham as lacunas habituais.

1. Defina o link de pagamento por omissão e confirme que está aprovado. Sem ele, os links de atualização não funcionam.
2. Escolha o resultado no fim da janela (cancelar, pausar ou em atraso) consoante a forma como a sua app gere o acesso.
3. Condicione o acesso ao estado. Trate subscription.past_due, subscription.activated e subscription.canceled na sua app. Decida que acesso mantém um cliente em atraso, e diga-o.
4. Mostre o problema na sua app. Um banner para os clientes em atraso, com o link de gestão da subscrição, chega a quem nunca abre os emails de recuperação.
5. Não envie emails a dobrar. Se o Paddle ou o Retain enviam emails de recuperação, as suas próprias mensagens devem estar na app, ou ser claramente diferentes (por exemplo vindas do responsável de conta, para grandes contas B2B).
6. Persiga você mesmo as faturas manuais. O Retain não atua sobre subscrições cobradas manualmente. Construa uma sequência de lembretes para essas.
7. Registe cada falha. Guarde cada transaction.payment_failed com a subscrição, o montante e o resultado. Ao fim de alguns meses saberá que clientes se recuperam com uma nova tentativa e quais só com um novo cartão.

O que pode acrescentar

O Paddle cobre bem o essencial: novas tentativas, uma página de atualização alojada, emails e um modelo de estados. O que falta é sobretudo contexto.

• Saiba que clientes estão em risco. Uma falha numa conta antiga e ativa é diferente de uma falha numa conta em que ninguém entra há dois meses.
• Relacione as falhas com o que sabe do cliente. O plano, a utilização, o histórico de suporte e o tipo de método de pagamento mudam o que uma boa mensagem de recuperação deve dizer.
• Meça. Conte os recuperados face aos perdidos por mês e por causa. Veja churn involuntário para as definições e modelos de emails de recuperação se escrever os seus próprios textos na app.

Fazer isto com o NoChurn

No Paddle, a cobrança dos pagamentos, as novas tentativas e os emails do próprio Paddle ficam no Paddle enquanto merchant of record. O NoChurn lê as suas subscrições e transações do Paddle, dá a cada cliente um score de churn de 0 a 100 usando os seus dados próprios enviados pela API e acrescenta um fluxo de cancelamento e emails de reconquista aos dias 30, 60 e 90. Onde as definições do Paddle deixam espaço, pode enviar mensagens de recuperação escritas por IA que revê antes do envio. Veja NoChurn + Paddle.