Como recuperar pagamentos falhados de débito direto com o GoCardless

Um débito direto falhado não é um cartão recusado. Não há cartão para atualizar, o banco responde dias depois de ter pedido o dinheiro e o cliente pode por vezes reclamar o dinheiro muito tempo depois de ele ter saído da conta. A recuperação no GoCardless segue regras próprias, e a maioria vem dos esquemas bancários (Bacs, SEPA, ACH e outros) e não do próprio GoCardless.

Este guia explica porque falham os pagamentos GoCardless, como funcionam as novas tentativas, o que fazer quando um mandato é cancelado ou expira e como são tratados os charge-backs (pedidos de indemnização). Baseia-se apenas na documentação do próprio GoCardless: a referência dos eventos de pagamento, a referência dos eventos de mandato, o guia do Success+, os artigos da central de ajuda sobre falhas de pagamento e que pagamentos falhados o Success+ pode tentar de novo, e as descrições nas bibliotecas cliente oficiais da API do GoCardless (todos consultados em novembro de 2026).

Como avança um pagamento por débito direto

Um pagamento GoCardless passa por uma série de estados. A API documenta estes valores para status:

Estado	Significado
pending_submission	Criado, ainda não submetido aos bancos
submitted	Submetido aos bancos
confirmed	Confirmado como cobrado
paid_out	Incluído numa transferência para si
failed	O pagamento não foi processado
charged_back	O pagamento foi alvo de charge-back
cancelled	O pagamento foi cancelado antes da cobrança

Dois detalhes importam para a recuperação:

1. As falhas chegam depois da data de cobrança. A central de ajuda do GoCardless diz que as notificações de falha chegam normalmente um dia útil depois da data de cobrança. Fica a saber um pouco mais tarde do que com os cartões, e os seus emails de recuperação devem começar a partir do evento de falha, não da data de cobrança.
2. Um pagamento confirmado ainda pode falhar. A referência da API nota que os pagamentos podem falhar depois de confirmados se o banco enviar a mensagem de falha tarde. Não trate confirmed como definitivo quando dá ou retira acesso.

Porque falham os pagamentos por débito direto

Cada falha vem com um evento. Nos eventos de pagamento, o GoCardless envia um objeto details com:

• cause: a chave simplificada e previsível do GoCardless para o que aconteceu.
• origin: quem desencadeou o evento, por exemplo bank, gocardless, api ou customer.
• reason_code: quando a origem é o banco, o código específico do esquema que o banco reportou. O GoCardless avisa que pode ser inconsistente entre bancos, por isso construa a sua lógica sobre cause e guarde reason_code para investigar.
• description: um texto legível, que o GoCardless diz poder mudar sem aviso.

As causas listadas na referência dos eventos de pagamento incluem insufficient_funds, refer_to_payer, mandate_cancelled, bank_account_closed, invalid_bank_details, direct_debit_not_enabled, bank_declined_payment, payment_stopped e account_blocked_for_any_financial_transaction. Dividem-se em três grupos:

Grupo	Causas	O que fazer
Dinheiro insuficiente	insufficient_funds, refer_to_payer	Tentar de novo, idealmente depois de o cliente ter provavelmente recebido o salário. O GoCardless descreve refer_to_payer (um código Bacs) como significando quase sempre saldo insuficiente.
Mandato desaparecido	mandate_cancelled	Não tentar de novo. O cliente precisa de um novo mandato.
Problema na conta	bank_account_closed, invalid_bank_details, direct_debit_not_enabled, account_blocked_for_any_financial_transaction	Não tentar de novo. Pedir outros dados bancários ou outro método de pagamento.
Parado pelo cliente ou pelo banco	payment_stopped, bank_declined_payment	Contactar o cliente antes de tentar de novo. Um pagamento parado pode ser sinal de que ele quer sair.

Novas tentativas com o Success+

O produto de novas tentativas do próprio GoCardless é o Success+. Segundo o guia do Success+ e a central de ajuda:

• É ativado no dashboard do GoCardless por um utilizador administrador, com definições por esquema.
• As integrações por API também têm de incluir cada pagamento enviando retry_if_possible: true ao criar pagamentos, subscrições ou planos de prestações. O valor por defeito é false.
• Por defeito, tenta de novo até 3 vezes em 4 semanas. Pode definir a sua própria janela em dias de calendário, e as novas tentativas acontecem em dias úteis dentro dela.
• Só tenta de novo as falhas que considera recuperáveis, sobretudo falhas por falta de saldo. Os mandatos cancelados, as contas fechadas e as recusas diretas do banco não são repetidos. A lista de códigos recuperáveis é por esquema.
• No Bacs, o pagador tem de ser informado da data da nova tentativa antes de o pagamento ser cobrado.
• Cada nova tentativa é uma nova tentativa de pagamento para efeitos de faturação, por isso verifique os preços do GoCardless.

No evento de falha, o campo will_attempt_retry diz-lhe se o Success+ vai tentar de novo. Quando é false, not_retried_reason explica porquê: failure_filter_applied (o GoCardless espera que a nova tentativa falhe) ou other.

A central de ajuda do GoCardless nota também que nem todos os parceiros de software suportam o Success+. Se a sua faturação passa por uma app de um parceiro, verifique lá primeiro.

Novas tentativas manuais através da API

Sem o Success+, ou para um pagamento que ele não vai repetir, pode tentar de novo por si com POST /payments/:id/actions/retry. A API documenta três regras:

1. O mandato subjacente tem de estar ativo.
2. Um pagamento pode ser repetido até 3 vezes.
3. A chamada falha com retry_failed se o pagamento não tiver falhado.

Depois da chamada recebe um evento resubmission_requested, e depois a mesma sequência que um pagamento novo: submitted, seguido de confirmed ou failed. A nova tentativa precisa de uma nova data de cobrança, por isso escolha-a com intenção. Para uma falha insufficient_funds, uma data logo depois de um dia habitual de pagamento de salários no país do cliente é uma escolha razoável. Tentar de novo no dia seguinte normalmente não é.

Avise o cliente antes de tentar de novo

Ao contrário de uma nova tentativa num cartão, uma nova tentativa de débito direto é visível no extrato bancário do cliente, e no Bacs o GoCardless exige um pré-aviso da data da nova tentativa. Uma boa mensagem:

1. Diz que o pagamento não foi processado, com o montante e o plano.
2. Indica a data da próxima tentativa.
3. Oferece uma forma de alterar os dados bancários ou pagar de outra maneira se a conta não vier a ter saldo.
4. É enviada a partir de um endereço que uma pessoa lê.

Mandatos cancelados e expirados

Um pagamento precisa de um mandato ativo. A API documenta estes estados de mandato, entre outros: active, suspended_by_payer, cancelled, expired (expirado por inatividade), failed, consumed e blocked. Acompanhe os eventos de mandato (resource_type: mandates) tão de perto como os eventos de pagamento: um mandato cancelado significa que todos os pagamentos futuros nele vão falhar.

Quando um mandato é cancelado pelo cliente no seu banco, um pagamento associado falha com a causa mandate_cancelled. Não tente de novo; precisa de um novo mandato. Passos:

1. Descubra porquê. Um cliente que cancela o débito direto no banco pode simplesmente ter mudado de banco, ou pode querer deixar de pagar. O email deve perguntar, não presumir.
2. Envie um link para configurar um novo mandato. No GoCardless, um novo mandato é recolhido através de um Billing Request, normalmente com um Billing Request Flow alojado. Envie esse link ao cliente, não um formulário a pedir os dados bancários por email.
3. Recrie o pagamento no novo mandato assim que estiver ativo.

A API do GoCardless tem também uma ação reinstate para mandatos cancelados ou expirados (até 10 vezes por mandato). Volta a submeter o mandato aos bancos e depois recebe submitted, seguido de reinstated ou failed, até dois dias úteis depois. Use-a só quando souber que o mandato ainda deve ser válido. Quando o cliente cancelou de propósito, reativá-lo sem perguntar não é a atitude certa.

Charge-backs (pedidos de indemnização)

O débito direto dá aos clientes direitos de reembolso fortes, e diferem consoante o esquema. A central de ajuda e os guias do GoCardless descrevem-nos:

Esquema	Direito do cliente a reclamar
Bacs (Reino Unido)	Ao abrigo da Direct Debit Guarantee, o GoCardless diz que atualmente não há limite de tempo para os pedidos de indemnização.
SEPA Core	Reembolso sem perguntas no prazo de 8 semanas após o débito; até 13 meses para pagamentos não autorizados.
SEPA B2B	Nenhum reembolso para pagamentos autorizados; reclamações para pagamentos não autorizados até 13 meses.

Um pagamento reclamado passa a charged_back e o montante é-lhe retirado. Ao contrário das disputas de cartão, normalmente não há processo de provas. O GoCardless descreve uma funcionalidade para contestar charge-backs na sua central de ajuda, com condições de plano e de esquema; verifique se se aplica a si.

O que pode controlar é o que acontece antes da reclamação:

• Torne fácil cancelar. Um cliente que não encontra como cancelar vai parar o débito direto no banco ou apresentar uma reclamação. Um botão de cancelar claro do seu lado custa menos.
• Envie pré-avisos fáceis de ler. Um cliente que se esqueceu de uma renovação tem mais probabilidade de reclamar.
• Trate um charge-back como um sinal de cancelamento. Pare os pagamentos futuros nesse mandato até ter falado com o cliente.

Webhooks a escutar

Uma integração mínima de recuperação no GoCardless acompanha estes eventos:

Recurso	Ação	Porquê
payments	failed	Iniciar a recuperação; ler cause, will_attempt_retry
payments	resubmission_requested, submitted, confirmed	Acompanhar uma nova tentativa
payments	charged_back	Pedido de indemnização; pausar e contactar o cliente
mandates	cancelled, expired	Pedir um novo mandato antes do próximo pagamento

Lembre-se de que uma falha pode produzir vários eventos (por exemplo, um mandato cancelado e os seus pagamentos pendentes cancelados), por isso elimine duplicados pelo ID do evento e agrupe por cliente antes de enviar um email a alguém.

Fazer isto com o NoChurn

O NoChurn liga-se à sua conta GoCardless, importa clientes, mandatos, subscrições e pagamentos, e acompanha os webhooks do GoCardless. Quando um pagamento falha, envia emails de recuperação escritos por IA que revê, com um calendário pensado para o débito direto, e quando um mandato é cancelado o email leva o cliente a configurar um novo. A cobrança, as novas tentativas e o Success+ ficam no GoCardless, e os charge-backs aparecem na cronologia do cliente, já que as reclamações de débito direto não têm provas a enviar. O NoChurn acrescenta também fluxos de cancelamento com um cancelamento num clique sempre visível, emails de reconquista aos dias 30, 60 e 90 com base no motivo de cancelamento e uma pontuação de churn. Veja NoChurn + GoCardless.