v2.41.1 — Transferência interna recusada não volta mais como pendente

Recusa do liquidante agora responde 422. POST /v1/accounts/{accountId}/transfers/internal (e as variantes /by-document e /by-bank-account) devolvia 202 com status: "PENDING" quando o liquidante recusava a operação — a transferência estava definitivamente encerrada, mas a resposta pedia para esperar. Agora a recusa sai como 422 com status: "FAILED", errorCode e errorReason, como o contrato já documentava. O 202 PENDING ficou reservado ao caso indeterminado (a operação ainda em curso quando a janela síncrona expira).
insufficient_funds no lugar de partner_rejected quando o motivo é saldo. O liquidante recusa transferência interna por falta de saldo com uma mensagem genérica (“o liquidante recusou a operação”). Passamos a conferir o saldo disponível na hora da recusa: quando ele não cobre o valor pedido, a resposta vem como insufficient_funds. Sem essa evidência a recusa continua partner_rejected, com o motivo do liquidante no bloco partner.
workflowId correto na transferência interna. Repetir o POST com a mesma Idempotency-Key devolvia um workflowId com prefixo de PIX out. Agora vem o id real da operação (internal-out-…).
TED não fica mais eternamente em PROCESSING. O desfecho do liquidante chegava, mas era entregue ao processo errado e se perdia — e o registro da TED nunca era atualizado. Resultado: GET /transfers/ted/{tedId} e o extrato mostravam “processando” mesmo em TED já liquidada ou recusada, e uma recusa só virava ted.out.failed 48h depois, com o motivo genérico de timeout no lugar da recusa real. Agora o desfecho é aplicado assim que chega, e as TEDs que estavam presas foram conciliadas com o estado real.
TED: bankCode só aceita o Compe de 3 dígitos. Mandar o ISPB (8 dígitos) nesse campo agora é recusado na hora com 400 invalid_bank_code. Antes a requisição era aceita com 202, seguia para o liquidante sem banco de destino e a TED ficava presa em PROCESSING — sem liquidar e sem falhar. O ISPB continua válido no PIX por dados bancários (bankIspb).

Transferência interna não tem webhook de falha

O webhook transfer.internal.out só é entregue quando a transferência é efetivada. Para uma recusa, o desfecho está na resposta da própria chamada — por isso o 422 acima importa. Não espere webhook para fechar uma transferência interna recusada.

v2.42.0 — Suspensão temporária de acesso por pendência

Dois códigos novos: tenant_suspended e tenant_disabled. Quando há uma pendência em aberto, o acesso do tenant pode ser suspenso temporariamente. Com o tenant suspenso, as consultas (GET) continuam funcionando — saldo, extrato e status de operações — e as escritas respondem 403 tenant_suspended. Com o tenant desativado, todas as rotas respondem 403 tenant_disabled.
A credencial não é revogada. O mesmo client_id/client_secret continua obtendo token normalmente; a recusa acontece na chamada à API. Regularizada a pendência, o acesso volta na chamada seguinte — sem credencial nova, sem token novo.
Dinheiro recebido continua entrando. PIX recebido segue sendo creditado e os webhooks desses eventos continuam sendo entregues. A suspensão bloqueia iniciar novas operações, não receber.

Detalhes no Guia de Autenticação.