Retentativas Intradia e Extradia

Visão Geral

Quando um pagamento Pix Automático falha na liquidação, o Open Finance Brasil define um mecanismo estruturado de retentativas que garante novas oportunidades de liquidação — tanto no mesmo dia (intradia) quanto em dias subsequentes (extradia). A ITP é responsável por orquestrar essas tentativas através do endpoint de retry.

Fluxo Intradia

A tentativa intradia ocorre no mesmo dia em que o pagamento foi programado, em duas janelas obrigatórias:

Janela	Horário	Responsável
1ª tentativa	0h às 8h	Detentora submete ao SPI
2ª tentativa	18h às 21h	ITP envia novo pagamento + Detentora submete ao SPI

Regras da 2ª Tentativa Intradia

Ocorre somente se a 1ª tentativa falhou
Quando o erro exige novo endToEndId (ver Tabela de Erros), a ITP deve enviar um novo pagamento via endpoint de retry até as 12h (meio-dia) do mesmo dia
Quando o erro não exige novo endToEndId, a detentora gerencia a retentativa automaticamente
O novo pagamento fica em SCHD aguardando a janela das 18h às 21h

sequenceDiagram
    participant ITP
    participant Detentora
    participant SPI

    Note over Detentora,SPI: 1ª Tentativa (0h–8h)
    Detentora->>SPI: Tenta liquidar pagamento original
    SPI-->>Detentora: RJCT (ex: SALDO_INSUFICIENTE)
    Detentora->>ITP: Webhook: status RJCT

    Note over ITP: ITP analisa o erro
    ITP->>Detentora: POST /retry (novo endToEndId, mesma date) até 12h
    Detentora-->>ITP: { recurringPaymentId: novo, status: SCHD }

    Note over Detentora,SPI: 2ª Tentativa (18h–21h)
    Detentora->>SPI: Tenta liquidar com novo e2eID
    SPI-->>Detentora: ACSC
    Detentora->>ITP: Webhook: status ACSC

Fluxo Extradia

O fluxo extradia aplica-se quando o pagamento não foi liquidado após todas as tentativas intradia.

Regras

Máximo de 3 tentativas extradia em dias diferentes
Cada tentativa extradia exige nova chamada ao endpoint de retry
O payload só pode alterar: endToEndId, originalRecurringPaymentId e date
Envio deve ser feito até as 23h59 do dia anterior à nova data de liquidação
O recebedor pode consolidar valores em atraso na próxima cobrança (respeitando os limites do consentimento)

Prazos máximos por periodicidade

Periodicidade	Prazo máximo extradia
`SEMANAL`	5 dias corridos após a data original
Demais (`DIARIO`, `MENSAL`, `SEMESTRAL`, `ANUAL`)	7 dias corridos após a data original
Qualquer	Até o dia imediatamente anterior ao início do novo ciclo

Exemplo de Cenário Extradia

Data	Evento
16/09	Pagamento original — 1ª tentativa (0h–8h): RJCT
16/09	2ª tentativa intradia (18h–21h): RJCT
17/09	ITP envia retry com `date: 18/09` via endpoint (até 23h59)
18/09	1ª tentativa extradia — 1ª janela (0h–8h): RJCT
18/09	2ª tentativa extradia — 2ª janela (18h–21h): RJCT
19/09	ITP envia retry com `date: 20/09` via endpoint
20/09	2ª tentativa extradia: ACSC ✅

Endpoint de Retentativa

`POST /automatic-payments/v2/pix/recurring-payments/:originalRecurringPaymentId/retry`

Autenticação: Bearer Token (application_token)

Path Parameters

Parâmetro	Tipo	Obrigatório	Descrição
`originalRecurringPaymentId`	string	✅	ID do pagamento original que falhou (`recurringPaymentId`)

Request

POST {{base_url}}/automatic-payments/v2/pix/recurring-payments/{{originalRecurringPaymentId}}/retry
Authorization: Bearer {{application_token}}
Content-Type: application/json

{
  "data": {
    "endToEndId": "E13935893202606250431HnY18krNL6Q",
    "date": "2026-06-25",
    "originalRecurringPaymentId": "pmt-rec-abc123def456"
  }
}

Campo	Tipo	Obrigatório	Descrição
`data.endToEndId`	string	✅	Novo `endToEndId` único (obrigatório quando o erro exige reenvio)
`data.date`	string	✅	Nova data de liquidação para a retentativa
`data.originalRecurringPaymentId`	string	✅	ID do pagamento original que originou a retentativa

Response

{
  "data": {
    "recurringPaymentId": "pmt-rec-xyz789ghi012",
    "originalRecurringPaymentId": "pmt-rec-abc123def456",
    "endToEndId": "E13935893202606250431HnY18krNL6Q",
    "status": "SCHD",
    "date": "2026-06-25",
    "createdAt": "2026-06-25T10:00:00Z"
  }
}

Tabela de Erros e Regras de Retentativa

Código de Erro	Contabiliza tentativa?	Permite nova tentativa intradia?	Exige reenvio de `endToEndId`?
`NAO_INFORMADO`	✅ Sim	✅ Sim	✅ Sim
`PAGAMENTO_RECUSADO_SPI`	✅ Sim	✅ Sim	✅ Sim
`FALHA_INFRAESTRUTURA_SPI`	✅ Sim	✅ Sim	✅ Sim
`FALHA_INFRAESTRUTURA_ICP`	✅ Sim	✅ Sim	✅ Sim
`FALHA_INFRAESTRUTURA_PSP_RECEBEDOR`	✅ Sim	✅ Sim	✅ Sim
`SALDO_INSUFICIENTE`	✅ Sim	✅ Sim	❌ Não
`VALOR_ACIMA_LIMITE`	✅ Sim	✅ Sim	❌ Não
`PAGAMENTO_RECUSADO_DETENTORA`	✅ Sim	✅ Sim	❌ Não
`FALHA_INFRAESTRUTURA_DETENTORA`	✅ Sim	❌ Não	❌ Não
`LIMITE_VALOR_TRANSACAO_CONSENTIMENTO_EXCEDIDO` ²	✅ Sim	❌ Não	❌ Não
`DETALHE_TENTATIVA_INVALIDO`	❌ Não	✅ Sim	❌ Não
`VALOR_INVALIDO`	❌ Não	❌ Não	❌ Não
`PAGAMENTO_DIVERGENTE_CONSENTIMENTO`	❌ Não	❌ Não	❌ Não
`CONSENTIMENTO_INVALIDO`	N/A	❌ Não	❌ Não
`TITULARIDADE_INCONSISTENTE`	N/A	❌ Não	❌ Não
`LIMITE_PERIODO_VALOR_EXCEDIDO` ¹	N/A	❌ Não	❌ Não
`LIMITE_PERIODO_QUANTIDADE_EXCEDIDO` ¹	N/A	❌ Não	❌ Não
`LIMITE_VALOR_TOTAL_CONSENTIMENTO_EXCEDIDO` ¹	N/A	❌ Não	❌ Não
`LIMITE_TENTATIVAS_EXCEDIDO` ²	N/A	❌ Não	❌ Não
`CONSENTIMENTO_REVOGADO` ²	N/A	❌ Não	❌ Não
`FORA_PRAZO_PERMITIDO`	N/A	❌ Não	❌ Não
`PERMISSAO_INSUFICIENTE`	N/A	❌ Não	❌ Não

¹ Erro exclusivo do produto Transferências Inteligentes (Sweeping Accounts)
² Erro ocorre apenas no momento do agendamento, não da liquidação

Como interpretar a tabela

Contabiliza tentativa? — Se NÃO, é uma falha de validação prévia que não consome uma tentativa formal. O payload pode ser corrigido e reenviado.

Permite nova tentativa intradia? — Se SIM, a detentora deve realizar uma nova tentativa no mesmo dia (conforme IN BCB 513, Art. 7, §1°). Se NÃO, uma nova tentativa no mesmo dia resultaria no mesmo erro.

Exige reenvio de endToEndId? — Se SIM, o pagamento anterior foi invalidado no SPI e a ITP deve gerar um novo endToEndId e chamar o endpoint de retry. Se NÃO, o mesmo endToEndId pode ser reutilizado (ou a detentora gerencia automaticamente).

Pontos de Atenção

⚠️
isRetryAccepted: false desabilita tudo: Se o consentimento foi criado com isRetryAccepted: false, nenhuma retentativa será realizada — nem intradia, nem extradia. Certifique-se de usar true em consentimentos que precisam de resiliência.

⚠️
Prazo da 2ª tentativa intradia: A ITP deve enviar o novo pagamento via retry até as 12h do mesmo dia, quando o erro exige novo endToEndId. Após as 12h, a 2ª tentativa intradia não será mais possível.

⚠️
Cada retentativa extradia é um novo pagamento: O endpoint de retry cria um novo recurringPaymentId. O originalRecurringPaymentId vincula a tentativa ao pagamento original para rastreabilidade.

⚠️
Máximo de 3 tentativas extradia: Em dias diferentes. Após esgotar as tentativas, não é possível criar novas para o ciclo em questão. O recebedor deve contatar o pagador por outros meios.

⚠️
Notificação ao usuário obrigatória: Conforme IN BCB 513, a detentora deve notificar o pagador quando o pagamento não for liquidado por saldo insuficiente ou limite transacional.

Retentativas Intradia e Extradia

Visão Geral

Fluxo Intradia

Regras da 2ª Tentativa Intradia

Fluxo Extradia

Regras

Prazos máximos por periodicidade

Exemplo de Cenário Extradia

Endpoint de Retentativa

`POST /automatic-payments/v2/pix/recurring-payments/:originalRecurringPaymentId/retry`

Path Parameters

Request

Response

Tabela de Erros e Regras de Retentativa

Como interpretar a tabela

Pontos de Atenção

`isRetryAccepted: false` desabilita tudo: Se o consentimento foi criado com `isRetryAccepted: false`, nenhuma retentativa será realizada — nem intradia, nem extradia. Certifique-se de usar `true` em consentimentos que precisam de resiliência.

Prazo da 2ª tentativa intradia: A ITP deve enviar o novo pagamento via retry até as 12h do mesmo dia, quando o erro exige novo `endToEndId`. Após as 12h, a 2ª tentativa intradia não será mais possível.

Cada retentativa extradia é um novo pagamento: O endpoint de retry cria um novo `recurringPaymentId`. O `originalRecurringPaymentId` vincula a tentativa ao pagamento original para rastreabilidade.

Máximo de 3 tentativas extradia: Em dias diferentes. Após esgotar as tentativas, não é possível criar novas para o ciclo em questão. O recebedor deve contatar o pagador por outros meios.

Notificação ao usuário obrigatória: Conforme IN BCB 513, a detentora deve notificar o pagador quando o pagamento não for liquidado por saldo insuficiente ou limite transacional.

Visão Geral

Fluxo Intradia

Regras da 2ª Tentativa Intradia

Fluxo Extradia

Regras

Prazos máximos por periodicidade

Exemplo de Cenário Extradia

Endpoint de Retentativa

POST /automatic-payments/v2/pix/recurring-payments/:originalRecurringPaymentId/retry

Path Parameters

Request

Response

Tabela de Erros e Regras de Retentativa

Como interpretar a tabela

Pontos de Atenção

isRetryAccepted: false desabilita tudo: Se o consentimento foi criado com isRetryAccepted: false, nenhuma retentativa será realizada — nem intradia, nem extradia. Certifique-se de usar true em consentimentos que precisam de resiliência.

Prazo da 2ª tentativa intradia: A ITP deve enviar o novo pagamento via retry até as 12h do mesmo dia, quando o erro exige novo endToEndId. Após as 12h, a 2ª tentativa intradia não será mais possível.

Cada retentativa extradia é um novo pagamento: O endpoint de retry cria um novo recurringPaymentId. O originalRecurringPaymentId vincula a tentativa ao pagamento original para rastreabilidade.

Máximo de 3 tentativas extradia: Em dias diferentes. Após esgotar as tentativas, não é possível criar novas para o ciclo em questão. O recebedor deve contatar o pagador por outros meios.

Notificação ao usuário obrigatória: Conforme IN BCB 513, a detentora deve notificar o pagador quando o pagamento não for liquidado por saldo insuficiente ou limite transacional.

`POST /automatic-payments/v2/pix/recurring-payments/:originalRecurringPaymentId/retry`

`isRetryAccepted: false` desabilita tudo: Se o consentimento foi criado com `isRetryAccepted: false`, nenhuma retentativa será realizada — nem intradia, nem extradia. Certifique-se de usar `true` em consentimentos que precisam de resiliência.

Prazo da 2ª tentativa intradia: A ITP deve enviar o novo pagamento via retry até as 12h do mesmo dia, quando o erro exige novo `endToEndId`. Após as 12h, a 2ª tentativa intradia não será mais possível.

Cada retentativa extradia é um novo pagamento: O endpoint de retry cria um novo `recurringPaymentId`. O `originalRecurringPaymentId` vincula a tentativa ao pagamento original para rastreabilidade.