Saltar para o conteúdo principal
GoCardless · SEPA Core · pagamento falhado

GoCardless insufficient_funds (AM04): a conta do cliente não tinha saldo

É a falha mais comum de uma domiciliação: o banco do cliente devolve o débito porque não havia dinheiro na conta. A GoCardless avisa com um evento de pagamento failed, a causa insufficient_funds e o código SEPA AM04. É uma das falhas que o seu serviço Success+ pode voltar a tentar sem que tenha de fazer nada.

FlexigoTech · Responsável: Víctor Gómez · Atualizado em 6 de novembro de 2026

O essencial

Módulo
GoCardless
Versões
Odoo 17, 18, 19 e 20
Verificado
no código do conector, versão 17.0, 18.0, 19.0 e 20.0 · nas fontes indicadas no fim
Leitura
5 min

O que diz a GoCardless

EventoCausaCódigo SEPA CoreTexto da GoCardless
payments · failedinsufficient_fundsAM04The customer's account had insufficient funds to make this payment.

A documentação do evento failed acrescenta uma peça-chave: a GoCardless volta a tentar o pagamento por conta própria quando o campo will_attempt_retry do evento está a true («GoCardless will automatically retry the payment if event's will_attempt_retry field is true.»). Essa nova tentativa automática é o Success+, e para a usar é preciso tê-lo ativado no Dashboard da GoCardless.

Segundo o guia do Success+, só volta a tentar pagamentos que falham por falta de fundos. No SEPA são dois códigos: AM04 e MS03, e o MS03 só na Áustria, Bélgica, Alemanha, Luxemburgo e Eslováquia. Ainda assim, a GoCardless avisa que os seus critérios podem mudar: o que vale para cada falha é o campo will_attempt_retry.

Cartão da causa insufficient_funds da GoCardless
A causa, o seu código SEPA Core AM04 e o texto com que a GoCardless a documenta.

Porque chega quando a fatura já parecia cobrada

Um débito SEPA não se resolve de imediato: segundo a GoCardless, cobrar um pagamento pode levar até 5 dias úteis. Quase sempre o banco do cliente avisa da falha um dia útil depois da data de débito, antes de o pagamento passar a confirmed. Em poucos casos avisa mais tarde, com o pagamento já marcado como confirmed: é uma falha tardia (late failure), e o guia do Success+ dá como exemplo uma por falta de fundos. Por isso o AM04 pode aparecer quando no Odoo a cobrança já estava confirmada e a fatura conciliada. O conector tem isto em conta: se uma cobrança que o Odoo dava por feita falhar, anula o seu pagamento e a fatura volta a ficar pendente.

O conector da GoCardless para o Odoo só cobra por SEPA Core e em euros, e para um pagamento falhado de SEPA Core a documentação da GoCardless dá um só código com insufficient_funds: AM04. No Odoo verá a causa e não o código, porque o conector guarda a causa do evento e não o código SEPA. O conector anota ainda no seu código que a combinação insufficient_funds com AM04 é a que viu em pagamentos SEPA reais do sandbox da GoCardless.

O que vê no Odoo com o conector

Cada cobrança que o conector envia pede à GoCardless retry_if_possible, a opção do Success+. Quando chega a falha podem acontecer duas coisas, e a transação diz-lhe qual no seu grupo GoCardless: «Causa segundo a GoCardless» e a caixa «O Success+ vai tentar novamente». A transação abre-se a partir da fatura, com o botão «Transação de Pagamento» no topo; o menu de transações só aparece em modo de programador, e no Odoo 20 não existe.

will_attempt_retryEstado«Mensagem» da transaçãoBotão «Tentar cobrar novamente»
true«Pendente»«A GoCardless não conseguiu cobrar este pagamento (insufficient_funds). O Success+ vai tentar novamente de forma automática; não é preciso fazer nada.»Não aparece
false«Erro», e a fatura volta a ficar pendente«A GoCardless não conseguiu cobrar este pagamento (insufficient_funds).» e, se a GoCardless indicar o motivo, «Não será tentado novamente de forma automática (…).»Aparece, se houver tentativas disponíveis e o mandato estiver ativo

Essas mensagens são escritas pelo conector ao aplicar o evento, sem ninguém a intervir. Numa base de dados criada em português aparecem como na tabela; numa base criada em inglês e passada depois para português aparecem em inglês: «GoCardless could not collect this payment (insufficient_funds). Success+ will retry it automatically; there is nothing to do.», «GoCardless could not collect this payment (insufficient_funds).» e «It will not be retried automatically (…).».

A transação fica pendente de propósito quando o Success+ vai tentar novamente: o dinheiro ainda pode chegar, e um estado de erro faria crer que a cobrança se perdeu. Cada vez que a GoCardless volta a apresentar a cobrança envia um evento resubmission_requested, e o conector soma um em «Novas tentativas da GoCardless», quer a nova tentativa seja do Success+ quer a tenha pedido você.

O que fazer

  1. Abra a transação a partir da fatura e veja «Causa segundo a GoCardless» e «O Success+ vai tentar novamente».
  2. Se o Success+ a vai tentar novamente, não faça nada: o botão de tentar novamente nem sequer aparece. A GoCardless pede que não cobre ao cliente por outra via entretanto, porque poderia pagar duas vezes.
  3. Se não a vai tentar novamente, fale primeiro com o cliente para saber quando terá saldo e carregue em «Tentar cobrar novamente» quando ele lhe confirmar. O botão não escolhe a data: a nova data de débito é definida pela GoCardless, e a transação fica em «Nova tentativa pedida. A GoCardless vai confirmar a nova data de débito.».
  4. Mantenha o controlo: a GoCardless admite no máximo 3 novas tentativas por pagamento («Payments can be retried up to 3 times.»), e o conector conta também as do Success+ em «Novas tentativas da GoCardless».

Um AM04 cancela o mandato do cliente?

Não. A causa insufficient_funds não está entre as que levam o conector a arquivar o mandato, que são mandate_cancelled, bank_account_closed, mandate_expired e authorisation_disputed. O cliente continua a ter o seu método de pagamento para a próxima fatura.

Porque é que o Success+ não volta a tentar todas as falhas?

Porque o seu guia o limita aos pagamentos sem fundos: no SEPA, AM04 e, só em cinco países, MS03. Um cliente que recusa o débito ou uma conta encerrada não se resolvem apresentando o débito outra vez. O conector não decide isso: segue o campo will_attempt_retry de cada falha.

Esquema: o que a GoCardless envia com insufficient_funds e o que o Odoo faz com o conector
Esquema feito a partir do código do conector (17.0, 18.0, 19.0 e 20.0) e da documentação da GoCardless.

Com o nosso conector

O conector da GoCardless para o Odoo 17, 18, 19 e 20 traduz o evento em algo que se pode gerir a partir da fatura: deixa a transação pendente enquanto o Success+ trabalha, passa-a a erro e reabre a fatura quando já não houver nova tentativa, e conta as novas tentativas para não lhe oferecer uma que não se aplica. O que não consegue fazer é pôr dinheiro na conta do seu cliente: se o AM04 se repetir, a conversa com ele é que resolve a cobrança.

Continue a ler

GoCardless refer_to_payer: MS02, MS03, RR04 e SL01 numa cobrança SEPArefer_to_payer agrupa no GoCardless os códigos SEPA MS02, MS03, RR04 e SL01. O que significa cada um, porque o mandato continua ativo e como o Odoo o trata.Erro retry_failed da GoCardless ao tentar cobrar novamente a partir do OdooA GoCardless responde retry_failed se o pagamento não falhou ou já não admite novas tentativas. Eis quando surge o botão «Tentar cobrar novamente» no Odoo.GoCardless MD06: o cliente pede ao banco o estorno de uma cobrançaO cliente pede ao banco o estorno de um débito GoCardless: charged_back, refund_requested e MD06. O que acontece no Odoo à fatura e ao mandato.
Verificado no código do conector (versão 17.0, 18.0, 19.0 e 20.0) e nas fontes indicadas

Fontes

  • docs.gocardless.com/docs/api-reference/events/payment
  • docs.gocardless.com/docs/api-reference/payment
  • docs.gocardless.com/docs/optimise/reduced-failed-payments-with-success-plus
  • Código do módulo: flexigo_payment_gocardless: const.py, linha 15 em 17.0 (d203ee6), 18.0 (e2ab18b), 19.0 (ce7f5a3) e 20.0 (688d86b)
  • Código do módulo: flexigo_payment_gocardless: const.py, linha 76 em 17.0 (d203ee6), 18.0 (e2ab18b), 19.0 (ce7f5a3) e 20.0 (688d86b)
  • Código do módulo: flexigo_payment_gocardless: const.py, linha 71 em 17.0 (d203ee6), 18.0 (e2ab18b), 19.0 (ce7f5a3) e 20.0 (688d86b)
  • Código do módulo: flexigo_payment_gocardless: models/payment_transaction.py, linha 260 em 17.0 (d203ee6), linha 260 em 18.0 (e2ab18b), linha 260 em 19.0 (ce7f5a3) e linha 271 em 20.0 (688d86b)
  • Código do módulo: flexigo_payment_gocardless: models/payment_transaction.py, linha 729 em 17.0 (d203ee6), linha 729 em 18.0 (e2ab18b), linha 728 em 19.0 (ce7f5a3) e linha 752 em 20.0 (688d86b)
  • Código do módulo: flexigo_payment_gocardless: models/payment_transaction.py, linha 746 em 17.0 (d203ee6), linha 746 em 18.0 (e2ab18b), linha 745 em 19.0 (ce7f5a3) e linha 769 em 20.0 (688d86b)
  • Código do módulo: flexigo_payment_gocardless: models/payment_transaction.py, linha 732 em 17.0 (d203ee6), linha 732 em 18.0 (e2ab18b), linha 731 em 19.0 (ce7f5a3) e linha 755 em 20.0 (688d86b)
  • Código do módulo: flexigo_payment_gocardless: models/payment_transaction.py, linha 754 em 17.0 (d203ee6), linha 754 em 18.0 (e2ab18b), linha 753 em 19.0 (ce7f5a3) e linha 777 em 20.0 (688d86b)
  • Código do módulo: flexigo_payment_gocardless: models/payment_transaction.py, linha 680 em 17.0 (d203ee6), linha 680 em 18.0 (e2ab18b), linha 679 em 19.0 (ce7f5a3) e linha 703 em 20.0 (688d86b)
  • Código do módulo: flexigo_payment_gocardless: models/payment_transaction.py, linha 430 em 17.0 (d203ee6), linha 430 em 18.0 (e2ab18b), linha 429 em 19.0 (ce7f5a3) e linha 444 em 20.0 (688d86b)
  • Código do módulo: flexigo_payment_gocardless: const.py, linha 122 em 17.0 (d203ee6), 18.0 (e2ab18b), 19.0 (ce7f5a3) e 20.0 (688d86b)
  • Código do módulo: flexigo_payment_gocardless: const.py, linha 119 em 17.0 (d203ee6), 18.0 (e2ab18b), 19.0 (ce7f5a3) e 20.0 (688d86b)
  • Código do módulo: flexigo_payment_gocardless: models/payment_transaction.py, linha 461 em 17.0 (d203ee6), linha 461 em 18.0 (e2ab18b), linha 460 em 19.0 (ce7f5a3) e linha 479 em 20.0 (688d86b)
  • Código do módulo: flexigo_payment_gocardless: models/payment_transaction.py, linha 484 em 17.0 (d203ee6), linha 484 em 18.0 (e2ab18b), linha 483 em 19.0 (ce7f5a3) e linha 502 em 20.0 (688d86b)
  • Código do módulo: flexigo_payment_gocardless: views/payment_transaction_views.xml, linha 13 em 17.0 (d203ee6), 18.0 (e2ab18b), 19.0 (ce7f5a3) e 20.0 (688d86b)
  • Código do módulo: flexigo_payment_gocardless: models/payment_transaction.py, linha 63 em 17.0 (d203ee6), 18.0 (e2ab18b), 19.0 (ce7f5a3) e 20.0 (688d86b)
  • Código do módulo: flexigo_payment_gocardless: models/payment_transaction.py, linha 418 em 17.0 (d203ee6), linha 418 em 18.0 (e2ab18b), linha 417 em 19.0 (ce7f5a3) e linha 432 em 20.0 (688d86b)
  • Código do módulo: flexigo_payment_gocardless: views/payment_transaction_views.xml, linha 22 em 17.0 (d203ee6), 18.0 (e2ab18b), 19.0 (ce7f5a3) e 20.0 (688d86b)
  • Código do módulo: flexigo_payment_gocardless: views/payment_transaction_views.xml, linha 27 em 17.0 (d203ee6), 18.0 (e2ab18b), 19.0 (ce7f5a3) e 20.0 (688d86b)
  • Código do módulo: flexigo_payment_gocardless: views/payment_transaction_views.xml, linha 28 em 17.0 (d203ee6), 18.0 (e2ab18b), 19.0 (ce7f5a3) e 20.0 (688d86b)
  • github.com/odoo/odoo/blob/20.0/addons/payment/views/payment_transaction_views.xml
  • github.com/odoo/odoo/blob/20.0/addons/payment/i18n/pt.po
  • Código do módulo: flexigo_payment_gocardless: i18n/pt.po, linha 462 em 17.0 (d203ee6), linha 462 em 18.0 (e2ab18b), linha 462 em 19.0 (ce7f5a3) e linha 468 em 20.0 (688d86b)
  • Código do módulo: flexigo_payment_gocardless: i18n/pt.po, linha 1164 em 17.0 (d203ee6), linha 1164 em 18.0 (e2ab18b), linha 1164 em 19.0 (ce7f5a3) e linha 1176 em 20.0 (688d86b)
  • Código do módulo: flexigo_payment_gocardless: i18n/pt.po, linha 765 em 17.0 (d203ee6), linha 765 em 18.0 (e2ab18b), linha 765 em 19.0 (ce7f5a3) e linha 777 em 20.0 (688d86b)
  • Código do módulo: flexigo_payment_gocardless: i18n/pt.po, linha 377 em 17.0 (d203ee6), linha 377 em 18.0 (e2ab18b), linha 377 em 19.0 (ce7f5a3) e linha 383 em 20.0 (688d86b)
  • Código do módulo: flexigo_payment_gocardless: i18n/pt.po, linha 1142 em 17.0 (d203ee6), linha 1142 em 18.0 (e2ab18b), linha 1142 em 19.0 (ce7f5a3) e linha 1154 em 20.0 (688d86b)
  • Código do módulo: flexigo_payment_gocardless: i18n/pt.po, linha 429 em 17.0 (d203ee6), linha 429 em 18.0 (e2ab18b), linha 429 em 19.0 (ce7f5a3) e linha 435 em 20.0 (688d86b)
  • Código do módulo: flexigo_payment_gocardless: i18n/pt.po, linha 1091 em 17.0 (d203ee6), linha 1091 em 18.0 (e2ab18b), linha 1091 em 19.0 (ce7f5a3) e linha 1113 em 20.0 (688d86b)
  • Código do módulo: flexigo_payment_gocardless: i18n/pt.po, linha 1097 em 17.0 (d203ee6), linha 1097 em 18.0 (e2ab18b), linha 1097 em 19.0 (ce7f5a3) e linha 1119 em 20.0 (688d86b)
  • Código do módulo: flexigo_payment_gocardless: __manifest__.py, linha 31 em 17.0 (d203ee6), 18.0 (e2ab18b), 19.0 (ce7f5a3) e 20.0 (688d86b)
  • support.gocardless.com/hc/en-gb/articles/360001467265
  • Código do módulo: flexigo_payment_gocardless: const.py, linha 66 em 17.0 (d203ee6), 18.0 (e2ab18b), 19.0 (ce7f5a3) e 20.0 (688d86b)
  • github.com/odoo/odoo/blob/17.0/odoo/http.py
  • github.com/odoo/odoo/blob/20.0/addons/account_payment/views/account_move_views.xml