O que fazer quando um mandato GoCardless é cancelado

No GoCardless, cada pagamento depende de um mandato: a autorização do cliente para debitar a sua conta. Quando o mandato é cancelado, mais nada funciona. Os pagamentos pendentes param, as subscrições associadas terminam e nenhuma nova tentativa ajuda. É o evento mais importante a tratar bem num negócio de débito direto, e também aquele em que um email automático do tipo “atualize os seus dados” tem mais probabilidade de estar errado.

Este guia explica porque terminam os mandatos, o que acontece às subscrições e pagamentos neles, como ler a causa e como obter um novo mandato quando o cliente quer continuar a pagar. Baseia-se apenas na documentação do GoCardless: a referência dos eventos de mandato, a referência dos eventos de subscrição, o guia para developers Responding to mandate events e o artigo da central de ajuda sobre os estados do mandato (todos consultados em novembro de 2026). O site de documentação do GoCardless não estava acessível a partir do nosso ambiente de pesquisa, por isso verificámos também as descrições dos campos e endpoints nas bibliotecas cliente oficiais da API do GoCardless (por exemplo a gocardless-pro-ruby), que são geradas a partir do mesmo esquema da API. Para o lado dos pagamentos na recuperação, veja como recuperar pagamentos falhados de débito direto com o GoCardless.

Estados do mandato

O GoCardless documenta estes estados do mandato:

Estado	Significado
pending_customer_approval	Ainda não assinado por um segundo signatário
pending_submission	Ainda não submetido ao banco do cliente
submitted	Submetido, ainda não processado
active	Configurado pelo banco do cliente; podem ser cobrados pagamentos
suspended_by_payer	Suspenso pelo pagador
failed	Não pôde ser criado
cancelled	Cancelado
expired	Expirado por inatividade
consumed	Usado e não reutilizável (só para esquemas autorizados por pagamento)
blocked	Bloqueado; não podem ser criados pagamentos

Só os mandatos active podem ser cobrados, e uma nova tentativa manual de pagamento exige um mandato ativo. Cada mandato tem também uma next_possible_charge_date, que importa quando configura um mandato de substituição e quer saber quando pode cobrar.

Porque é que um mandato é cancelado

O evento cancelled vem com details.cause, details.origin e, quando a origem é o banco, details.reason_code. Use cause para a sua lógica. O GoCardless avisa que reason_code é específico do esquema e pode ser inconsistente entre bancos.

O guia para developers do GoCardless lista várias causas para um mandato cancelado, incluindo:

• bank_account_closed: a conta bancária do cliente foi fechada.
• invalid_bank_details: os dados bancários não são válidos.
• mandate_cancelled: o mandato foi cancelado.

Sobre a última, as páginas do GoCardless não são coerentes entre si. A referência da API dos eventos de mandato descreve mandate_cancelled como um mandato cancelado pelo cliente ou pelo seu banco, enquanto o guia para developers, mais antigo, o usa para cancelamentos feitos através do dashboard ou da API e descreve de outra forma um cancelamento feito pelo cliente do lado do banco. Não confie apenas em cause para distinguir “o cliente cancelou no banco” de “fomos nós que cancelámos”: leia também origin (bank, api, gocardless, customer, etc.). Uma origem api significa que foi o seu próprio sistema, ou uma app que ligou, que o fez.

Um mandato expirado é diferente: o GoCardless faz expirar os mandatos por inatividade. Ninguém decidiu parar; o mandato simplesmente não foi usado.

O que acontece aos pagamentos e às subscrições

Um mandato cancelado leva coisas consigo:

• Pagamentos pendentes. A referência da API do GoCardless para o endpoint de cancelamento diz que cancelar um mandato cancela todos os pagamentos associados que possam ser cancelados. Um pagamento já submetido aos bancos ainda pode ser cobrado ou falhar por si.
• Subscrições. A referência dos eventos de subscrição do GoCardless mostra subscrições canceladas porque o seu mandato foi cancelado, com causas como mandate_cancelled, bank_account_closed e invalid_bank_details.
• Pagamentos posteriores. Um pagamento num mandato cancelado falha com a causa mandate_cancelled. Não é possível tentá-lo de novo: as novas tentativas exigem um mandato ativo.

Assim, um cancelamento produz vários eventos: o mandato, a subscrição e possivelmente pagamentos. Agrupe-os por cliente antes de enviar qualquer email, ou o cliente pode receber três mensagens sobre a mesma coisa.

Decidir o que significa o cancelamento

Antes de escrever ao cliente, classifique o cancelamento num de três casos:

Caso	Sinais	Resposta certa
O cliente mudou ou fechou a conta	bank_account_closed, ou um cancelamento seguido do cliente a dizer que mudou de banco	Pedir novos dados bancários através de um novo mandato
O cliente quer deixar de pagar	Cancelado no banco, muitas vezes perto de uma renovação; sem resposta	Tratá-lo como um cancelamento: confirmar, perguntar porquê, terminar o acesso de forma limpa
Foi o seu lado que o cancelou	origin é api ou o dashboard	Verificar os seus próprios registos antes de dizer qualquer coisa ao cliente

O guia para developers do GoCardless é claro num ponto: só cancele um mandato por si se o cliente o tiver pedido explicitamente.

Configurar um novo mandato

Quando o cliente quer continuar:

1. Envie um email, uma vez, de forma simples. Diga que o débito direto foi cancelado, que já não podem ser cobrados pagamentos nele e que pode configurar um novo num minuto se quiser continuar. O guia do GoCardless recomenda avisar o cliente e incentivá-lo a configurar um novo mandato se necessário.
2. Aponte para um fluxo alojado. No GoCardless, os novos mandatos são recolhidos com um Billing Request e o respetivo Billing Request Flow alojado. Envie esse link; nunca peça dados bancários por email.
3. Espere pelo estado active. Um novo mandato passa por pending_submission e submitted antes de active. Se falhar (por exemplo porque a nova conta não suporta débito direto), recebe um evento failed; peça ao cliente que tente outra conta.
4. Recrie o que se perdeu. Crie uma nova subscrição no novo mandato, e um pagamento para qualquer montante ainda em dívida, na next_possible_charge_date do mandato ou depois.
5. Diga ao cliente o que vai ser cobrado e quando, antes de acontecer.

E reativar?

A API do GoCardless tem uma ação reinstate para mandatos cancelados ou expirados. Volta a submeter o mandato aos bancos; recebe depois resubmission_requested, submitted, e reinstated ou failed até dois dias úteis depois, e um mandato pode ser submetido de novo até 10 vezes. Use-a só quando souber que o mandato ainda deve ser válido, por exemplo depois de um erro do seu lado. Quando o cliente cancelou no banco, reativá-lo sem o seu acordo vai contra a decisão dele e tem grande probabilidade de levar a uma falha ou a uma reclamação.

Mandatos expirados

Um mandato expirado é o mais fácil de recuperar, porque ninguém se opôs. Se planeia cobrar um cliente cujo mandato esteve inativo (um plano anual, ou um cliente que pausou), verifique o estado do mandato antes da data de cobrança. Se tiver expirado, peça ao cliente que configure um novo mandato com antecedência, em vez de o descobrir através de um pagamento falhado.

Uma lista de verificação

• O seu processador de webhooks trata os eventos de mandato, e não apenas os eventos de pagamento.
• Os eventos são agrupados por cliente antes de sair qualquer email.
• cause e origin são ambos guardados e lidos.
• Os cancelamentos feitos pelo seu próprio sistema são reconhecidos e não são comunicados aos clientes como “o seu banco cancelou”.
• O email do novo mandato aponta para um Billing Request Flow alojado.
• As subscrições só são recriadas depois de o novo mandato estar ativo.
• Os mandatos são verificados antes de cobranças pouco frequentes.

Fazer isto com o NoChurn

O GoCardless mantém os mandatos, a cobrança e os dados bancários. O NoChurn importa clientes, mandatos, subscrições e pagamentos, acompanha os webhooks do GoCardless e lê o estado do mandato (ativo, cancelado, expirado). Quando um mandato é cancelado, o email de recuperação escrito por IA do NoChurn, que revê, leva o cliente a configurar um novo; quando o cliente quer antes parar, o fluxo de cancelamento com um cancelamento num clique sempre visível e os emails de reconquista aos dias 30, 60 e 90 assumem o resto. Veja NoChurn + GoCardless.