Changelog - [SV] Pagamentos Automáticos - v2.2.0 - v2.1.0

Changelog - [SV] Pagamentos Automáticos - v2.2.0 - v2.1.0

 

Alterações na seção de orientações do swagger

Campo

O que foi alterado?

Tipo da Alteração

Antes

Depois

Campo

O que foi alterado?

Tipo da Alteração

Antes

Depois

/info

Alterado - "description"

Alteração

API de Iniciação de Pagamentos automáticos, responsável por viabilizar as operações de iniciação de pagamentos automáticos (Pix automático e Transferências Inteligentes) para o Open Finance Brasil…


API de Iniciação de Pagamentos automáticos, responsável por viabilizar as operações de iniciação de pagamentos automáticos (Pix automático e Transferências Inteligentes) para o Open Finance Brasil…


/info

Alterado - "version"

Alteração

2.1.0

2.2.0

paths

Adicionado - "/pix/recurring-payments/{originalRecurringPaymentId}/retry"

Adição

 

 

GET /pix/recurring-payments

Response

Campo

O que foi alterado?

Tipo da Alteração

Antes

Depois

Campo

O que foi alterado?

Tipo da Alteração

Antes

Depois

get/parameters/originalRecurringPaymentId

Alterado - "description"

Alteração

Campo que contém o código ou o identificador da tentativa original de pagamento que falhou.
Código ou identificador único criado pela instituição detentora da conta para representar a iniciação de pagamento.
Caso informado, devem ser retornados todos os pagamentos associados ao identificador informado, sendo eles o pagamento original (dono do identificador) e as novas tentativas que enviaram o identificador na sua requisição, indicando que representam nova tentativa.

Campo que contém o código ou o identificador da tentativa original de pagamento que falhou. 
Código ou identificador único criado pela instituição detentora da conta para representar a iniciação de pagamento. 
Caso informado, devem ser retornados todos os pagamentos associados ao identificador informado, sendo eles o pagamento original (dono do identificador) e as novas tentativas que enviaram o identificador na sua requisição, indicando que representam nova tentativa.

get/responses/200/data/items/document/identification

Alterado - "pattern"

Alteração

^(?:\d{11}|\d{14})$

^([0-9]{11})$|^([0-9A-Z]{12}[0-9]{2})$

get/responses/200/data/items/endToEndId

Alterado - "pattern"

Alteração

^([E])([0-9]{8})([0-9]{4})(0[1-9]|1[0-2])(0[1-9]|[1-2][0-9]|3[0-1])(2[0-3]|[01][0-9])([0-5][0-9])([a-zA-Z0-9]{11})$

^([E])([0-9A-Z]{8})([0-9]{4})(0[1-9]|1[0-2])(0[1-9]|[1-2][0-9]|3[0-1])(2[0-3]|[01][0-9])([0-5][0-9])([a-zA-Z0-9]{11})$

get/responses/200/data/items/paymentReference

Removido - "maxLength"

Remoção

10

 

get/responses/200/data/items/paymentReference

Alterado - "description"

Alteração

[Restrição]
Campo de preenchimento obrigatório caso seja um pagamento de Pix automático, caso não respeitado, a instituição detentora deve retornar erro HTTP 422 com o código DETALHE_PAGAMENTO_INVALIDO.

  • Primeiro pagamento: Se for o pagamento inicial especificado em “/data/firstPayment”, preencha o campo com a string fixa “zero”.

  • Semanal: Preencha com W$numSemana-$ano, onde $numSemana representa o número da semana no ano. Exemplo: "W50-2024".

  • Mensal: Use M$mês-$ano, onde $mês representa o mês com dois dígitos. Exemplo: "M09-2024".

  • Trimestral: Utilize Q$trimestre-$ano, onde $trimestre indica o trimestre do ano (1 a 4).

  • Janeiro a Março: Q1-$ano (ex.: "Q1-2024").

  • Abril a Junho: Q2-$ano (ex.: "Q2-2024").

  • Julho a Setembro: Q3-$ano (ex.: "Q3-2024").

  • Outubro a Dezembro: Q4-$ano (ex.: "Q4-2024").

  • Semestral: Utilize $semestre-$ano, onde $semestre indica o semestre do ano (1 para janeiro a junho e 2 para julho a dezembro).

  • Janeiro a Junho: S1-$ano (ex.: "S1-2024").

  • Julho a Dezembro: S2-$ano (ex.: "S2-2024").

  • Anual: Use Y$ano, apenas com o ano. Exemplo: "Y2024".

  • Exemplo de Formatos:

  • Primeiro pagamento: "zero"

  • Semanal: "W50-2024"

  • Mensal: "M09-2024"

  • Trimestral: "Q3-2024"

  • Semestral: "S2-2024"

  • Anual: "Y2024"



[Restrição] Campo de preenchimento obrigatório caso seja um pagamento de Pix automático e deve ser enviado para critérios de coleta de métricas do ecossistema. Caso essa regra não seja respeitada, a instituição detentora da conta deve retornar um erro HTTP 422 com o código DETALHE_PAGAMENTO_INVALIDO. 
O preenchimento deve seguir a seguinte lógica: 

  • Primeiro Pagamento: Se for o pagamento inicial especificado no campo /data/firstPayment, preencha o campo com a string fixa "zero". 

  • Pagamentos Recorrentes (Subsequentes): Para todos os pagamentos recorrentes após o inicial, o campo paymentReference deve ser preenchido com uma string ISO 8601 no formato ```R/<start>/<duration>```, representando o ciclo exato que está sendo pago. 

  • ```R```, seguindo o padrão ISO8601 para representar a recorrência única do ciclo que se iniciou no dia informado no componente ```<start>```. 

  • O componente ```<start>``` deve ser a data de início do ciclo específico, no formato ```YYYY-MM-DD```, ao qual o pagamento sendo enviado se refere.   

  • O componente ```<duration>``` representa o intervalo de ciclos definido para o consentimento autorizado (P1W para semanal, P1M para mensal, P3M para trimestral, P6M para semestral e P1Y para anual).  

  • Exemplos:

  • 1: Data de início do ciclo definido no consentimento: 23/07/25

  • Periodicidade definida no consentimento: Semanal

  • Preenchimento do paymentReference:

  • Primeiro ciclo: R/2025-07-23/P1W

  • Segundo ciclo:  R/2025-07-30/P1W

  • Terceiro ciclo: R/2025-08-06/P1W

  • 2: Data de início do ciclo definido no consentimento: 23/07/25

  • Periodicidade definida no consentimento: Mensal

  • Preenchimento do paymentReference:

  • Primeiro ciclo: R/2025-07-23/P1M

  • Segundo ciclo: R/2025-08-23/P1M

  • Terceiro ciclo: R/2025-09-23/P1M



get/responses/200/data/items/paymentReference

Adicionado - "example"

Adição

 

R/2025-09-23/P1M

get/responses/200/data/items/rejectionReason/code

Alterado - "description"

Alteração

Código identificador do motivo de rejeição.
Motivo da rejeição do pagamento. Informações complementares sobre o motivo do status.

  • SALDO_INSUFICIENTE

  • VALOR_ACIMA_LIMITE

  • VALOR_INVALIDO

  • NAO_INFORMADO

  • PAGAMENTO_DIVERGENTE_CONSENTIMENTO

  • PAGAMENTO_RECUSADO_DETENTORA

  • PAGAMENTO_RECUSADO_SPI

  • CONSENTIMENTO_INVALIDO

  • FALHA_INFRAESTRUTURA_SPI

  • FALHA_INFRAESTRUTURA_ICP

  • FALHA_INFRAESTRUTURA_PSP_RECEBEDOR

  • FALHA_INFRAESTRUTURA_DETENTORA

  • LIMITE_PERIODO_VALOR_EXCEDIDO

  • LIMITE_PERIODO_QUANTIDADE_EXCEDIDO

  • TITULARIDADE_INCONSISTENTE

  • LIMITE_VALOR_TOTAL_CONSENTIMENTO_EXCEDIDO

  • LIMITE_VALOR_TRANSACAO_CONSENTIMENTO_EXCEDIDO: O valor da transação ultrapassar o limite de valor por transação

  • CONSENTIMENTO_REVOGADO

  • LIMITE_TENTATIVAS_EXCEDIDO

  • FORA_PRAZO_PERMITIDO

  • DETALHE_TENTATIVA_INVALIDO

  • DETALHE_PAGAMENTO_INVALIDO

[Restrição] Esse motivo deverá ser enviado quando o campo `/data/status` for igual a RJCT (REJECTED).

Código identificador do motivo de rejeição.
Motivo da rejeição do pagamento. Informações complementares sobre o motivo do status.

  • SALDO_INSUFICIENTE

  • VALOR_ACIMA_LIMITE

  • VALOR_INVALIDO

  • NAO_INFORMADO

  • PAGAMENTO_DIVERGENTE_CONSENTIMENTO

  • PAGAMENTO_RECUSADO_DETENTORA

  • PAGAMENTO_RECUSADO_SPI

  • CONSENTIMENTO_INVALIDO

  • FALHA_INFRAESTRUTURA_SPI

  • FALHA_INFRAESTRUTURA_ICP

  • FALHA_INFRAESTRUTURA_PSP_RECEBEDOR

  • FALHA_INFRAESTRUTURA_DETENTORA

  • LIMITE_PERIODO_VALOR_EXCEDIDO

  • LIMITE_PERIODO_QUANTIDADE_EXCEDIDO

  • TITULARIDADE_INCONSISTENTE

  • LIMITE_VALOR_TOTAL_CONSENTIMENTO_EXCEDIDO

  • LIMITE_VALOR_TRANSACAO_CONSENTIMENTO_EXCEDIDO: O valor da transação ultrapassar o limite de valor por transação

  • LIMITE_TENTATIVAS_EXCEDIDO

  • FORA_PRAZO_PERMITIDO

  • DETALHE_TENTATIVA_INVALIDO

  • DETALHE_PAGAMENTO_INVALIDO

[Restrição] Esse motivo deverá ser enviado quando o campo `/data/status` for igual a RJCT (REJECTED).