Versões comparadas

Versão antiga 1

changes.mady.by.user Cecilia De Figueiredo Fernandes

Gravado em

comparado com

Nova versão 2

changes.mady.by.user Cecilia De Figueiredo Fernandes

Gravado em

Chave

  • Esta linha foi adicionada.
  • Esta linha foi removida.
  • A formatação mudou.

...

View file
nameChangelog - [SV] Pagamentos - v4.0.0-rc.2 - v3.0.0.csv

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

Campo

O que foi alterado?

Tipo da Alteração

Antes

Depois

N° Proposta

Data homologação

/info

Alterado - "description"

Alteração

API de Iniciação de Pagamentos, responsável por viabilizar as operações de iniciação de pagamentos para o Open Finance Brasil.
Para cada uma das formas de pagamento previstas é necessário obter prévio consentimento do cliente através dos `endpoints` dedicados ao consentimento nesta API.

# Orientações
No diretório de participantes duas `Roles` estão relacionadas à presente API:

  • `CONTA`, referente às instituições detentoras de conta participantes do Open Finance Brasil;

  • `PAGTO`, referente às instituições iniciadoras de pagamento participantes do Open Finance Brasil.

Os tokens utilizados para consumo nos endpoints de consentimentos devem possuir o scope `payments` e os `endpoints` de pagamentos devem possuir os `scopes`, `openid` e `payments`.
Esta API não requer a implementação de `permissions` para sua utilização. Todas as requisições e respostas devem ser assinadas seguindo o protocolo estabelecido na sessão <a href="https://openbanking-brasil.github.io/areadesenvolvedor/#assinaturas" target="_blank">Assinaturas</a> do guia de segurança.

## Regras do arranjo Pix
A implementação e o uso da API de Pagamentos Pix devem seguir as regras do arranjo Pix do Banco Central, que podem ser encontradas no link abaixo:  
[https://www.bcb.gov.br/estabilidadefinanceira/pix?modalAberto=regulamentacao_pix](https://www.bcb.gov.br/estabilidadefinanceira/pix?modalAberto=regulamentacao_pix)

## Assinatura de payloads

No contexto da API Payment Initiation, os `payloads` de mensagem que trafegam tanto por parte da instituição iniciadora de transação de pagamento quanto por parte da instituição detentora
de conta devem estar assinados. Para o processo de assinatura destes `payloads` as instituições devem seguir as especificações de segurança publicadas no Portal do desenvolvedor:

  • Certificados exigidos para assinatura de mensagens:

[Padrões de certificados digitais Open Finance Brasil](https://github.com/OpenBanking-Brasil/specs-seguranca/blob/main/open-banking-brasil-certificate-standards-1_ID1.md#certificado-de-assinatura-certificadoassinatura)

## Controle de acesso

O endpoint de consulta de pagamento GET /pix/payments/{​​​paymentId}​​​ deve suportar acesso a partir de access_token emitido por meio de um grant_type do tipo `client credentials`, como opção do uso do token vinculado ao consentimento (hybrid flow).

Para evitar vazamento de informação, a detentora deve validar que o pagamento consultado pertence ao ClientId que o criou e, caso haja divergências, retorne um erro HTTP 400.

Para o caso de QR Code estático e dinâmico a detentora deverá obrigatoriamente realizar validações sobre o conteúdo dos campos recebidos, de acordo com o tópico “Validações” abaixo.

## Aprovações de múltipla alçada

Para o caso de Pix imediato, todas as aprovações necessárias devem ser realizadas nos canais da detentora até às 23:59 (horário de Brasília) da data de solicitação do pagamento.
Já para o caso de Pix agendado, todas as aprovações devem ser realizadas até a data/hora limite suportada pela detentora.

## Validações
**Validações** (*após o processo de DCR e obtenção de token client credential*– não escopo dessa documentação) 
Durante a jornada de iniciação de pagamento, diferentes validações são necessárias pela instituição detentora
de conta e devem ocorrer conforme a seguir:

  1. Na criação do consentimento (*POST /consents*);

  2. Na criação do pagamento - Síncrono (*POST /payments*);

  3. Validações na consulta do pagamento (*GET /pix/payments/{paymentId}*);

  4. Demais validações executadas durante o processamento assíncrono do pagamento pela detentora, poderão ser consultados pela iniciadora através do endpoint (*GET /pix/payments/{paymentId}*) previstos com retorno HTTP Code 200 - OK com status RJCT (Rejected) e rejectionReason;

  5. Demais validações executadas durante o processamento assíncrono do consentimento pela detentora poderão ser consultados pela iniciadora através do endpoint (*GET /consents/{consentId}*) previstos com retorno HTTP Code 200 – OK com status REJECTED e rejectionReason

**Os tipos de validações dispostas abaixo não determinam a ordem em que as instituições devem implementá-las**

  1. **Validações na criação do consentimento (_POST /consents_)** 

  1.1 **Orientações Iniciais** 
    &ensp;1.1.1 Não devem ser retornadas na resposta deste endpointinformações associadas ao usuário/cliente (ex.  insuficiência de saldo, conta inexistente/bloqueada). 
    &ensp;1.1.2 Não devem ser executadas validações no DICT (Diretório de Identificadores de Contas Transacionais do Pix), a partir dos dados compartilhados nesse *endpoint*. Tais  validações podem ocorrer somente na criação do pagamento;   
    &ensp;1.1.3 Não devem ser realizadas validações de informações sobre o usuário/cliente durante a criação do consentimento. 
  1.2 **Casos de erro relacionados às permissões de segurança para acesso à API (ex. certificado, access_token, jwt, assinatura)** 
    &ensp;1.2.1 Validação de Certificado: Valida utilização de certificado correto durante processo de DCR - HTTP Code 401 (INVALID_CLIENT); 
    &ensp;1.2.2 Validação de Access_Token: Verifica se Access_Token utilizado está correto - HTTP Code 401 (UNAUTHORIZED); 
    &ensp;1.2.3 Validação de assinatura da mensagem: Valida se assinatura das mensagens enviadas está correta – HTTP Code 400 (BAD_SIGNATURE); 
    &ensp;1.2.4 Validação de Claims (exceto data); 
      &emsp;1.2.4.1 Valida se dados (aud, iss, iat e jti) são válidos - HTTP status code 403 – (INVALID_CLIENT); 
      &emsp;1.2.4.2 Valida reuso de jti - HTTP Code 403 (INVALID_CLIENT). 
  1.3 **Casos de erro sintáticos e semânticos, previstos com retorno HTTP Code 422 - Unprocessable Entity (detalhamento adicional na documentação técnica da API):**  
    &ensp;1.3.1 **Sintáticos** 
      &emsp;1.3.1.1 Envio de campos obrigatórios: Valida se todos os campos obrigatórios são informados (PARAMETRO_NAO_INFORMADO); 
      &emsp;1.3.1.2 Formatação de parâmetros: Valida se parâmetros informados obedecem a formatação especificada (PARAMETRO_INVALIDO). 
    &ensp;1.3.2 **Semânticos** 
      &emsp;1.3.2.1 Forma de pagamento: Valida se a forma de pagamento é suportada pela detentora (FORMA_PAGAMENTO_INVALIDA) **Obs. No detalhe do erro, a variável “modalidade” deve ser comunicada pela detentora da forma mais clara possível - ex. modalidade de pagamento não suportada (_localInstrument_ - QRES) ou tipo de arranjo pagamento não suportado (_type_ – ex. Pix / TED – previsto para inclusão futura);** 
      &emsp;1.3.2.2 Data de pagamento: Valida se a data de pagamento enviada é válida para a forma de pagamento selecionada (DATA_PAGAMENTO_INVALIDA); 
      &emsp;1.3.2.3 Detalhes do pagamento: Valida se determinado parâmetro informado obedece às regras de negócio (DETALHE_PAGAMENTO_INVALIDO); 
      &emsp;1.3.2.4 Demais validações não explicitamente informadas (ex. suspeita de fraude): (NAO_INFORMADO); 
      &emsp;1.3.2.5 Idempotência: Valida se há divergência entre chave de idempotência e informações enviadas (ERRO_IDEMPOTENCIA). 

  1. **Validações na criação do pagamento - Síncrono (_POST /payments_)** 

  2.1 **Casos de erro relacionados às permissões de segurança para acesso à API (ex. certificado, access_token, jwt, assinatura)** 
    &ensp;2.1.1 Validação de Certificado: Valida utilização de certificado correto durante processo de DCR - HTTP Code 401 (INVALID_CLIENT); 
    &ensp;2.1.2 Validação de Access_Token: Verifica se Access_Token utilizado está correto - HTTP Code 401 (UNAUTHORIZED); 
    &ensp;2.1.3 Validação de assinatura da mensagem: Valida se assinatura das mensagens enviadas está correta – HTTP Code 400 (BAD_SIGNATURE); 
    &ensp;2.1.4 Validação de Claims (exceto data); 
      &emsp;2.1.4.1 Valida se dados (aud, iss, iat e jti) são válidos - HTTP status code 403 – (INVALID_CLIENT); 
      &emsp;2.1.4.2 Valida reuso de jti - HTTP Code 403 (INVALID_CLIENT). 
  2.2 **Casos de erro sintáticos e semânticos, previstos com retorno HTTP Code 422 - Unprocessable Entity (detalhamento adicional na documentação técnica da API):** 
    &ensp;2.2.1 **Sintáticos** 
      &emsp;2.3.1.1 Envio de campos obrigatórios: Valida se todos os campos obrigatórios são informados (PARAMETRO_NAO_INFORMADO); 
      &emsp;2.3.1.2 Formatação de parâmetros: Valida se parâmetros informados obedecem a formatação especificada (PARAMETRO_INVALIDO). 
    &ensp;2.2.2 **Semânticos** 
      &emsp;2.2.2.1 Saldo do usuário: Valida se a conta selecionada possui saldo suficiente para realizar o pagamento (SALDO_INSUFICIENTE); 
      &emsp;2.2.2.2 Limites da transação: Valida se valor (ou quantidade de transações) ultrapassa faixa de limite parametrizada na detentora (VALOR_ACIMA_LIMITE); 
      &emsp;2.2.2.3 Valor informado (QR Code): Valida se valor enviado é válido para o QR Code informado (VALOR_INVALIDO); 
      &emsp;2.2.2.4 Cobrança inválida: Valida expiração, vencimento e status (COBRANCA_INVALIDA); 
      &emsp;2.2.2.5 Status Consentimento: Valida se status de consentimento é diferente de “AUTHORISED” (CONSENTIMENTO_INVALIDO); 
      &emsp;2.2.2.6 Divergência entre pagamento e consentimento: Valida se dados do pagamento são diferentes dos dados do consentimento (PAGAMENTO_DIVERGENTE_CONSENTIMENTO) 
      &emsp;2.2.2.7 Recusado pela detentora: Valida se pagamento foi recusado pela detentora (PAGAMENTO_RECUSADO_DETENTORA), com a descrição do motivo de recusa (ex. chave Pix inválida, QRCode inválido, conta bloqueada); 
      &emsp;2.2.2.8 Detalhes do pagamento: Valida se determinado parâmetro informado obedece às regras de negócio (DETALHE_PAGAMENTO_INVALIDO); 
      &emsp;2.2.2.9 Demais validações não explicitamente informadas (ex. suspeita de fraude): (NAO_INFORMADO); 
      &emsp;2.2.2.10 Idempotência: Valida se há divergência entre chave de idempotência e informações enviadas (ERRO_IDEMPOTENCIA). 
  2.3 **Casos de erro para validações síncronas no DICT** 
    &ensp;Nesse cenário, o pagamento não é criado, porém o consentimento deve ser alterado para o status CONSUMED Retorno esperado do endpoint POST/Payments: HTTP Code 422 - Unprocessable Entity: 
    &ensp;• Erro por dados inválidos: Conforme item **2.2.2.8** 
    &ensp;• Erro por suspeita de fraude: Conforme item **2.2.2.9** 

  1. **Validações na consulta do pagamento (_GET /pix/payments/{paymentId}_)** 

  3.1 **Casos de erro relacionados às permissões de segurança para acesso à API (ex. certificado, access_token)** 
    &ensp;3.1.1 Validação de Certificado: Valida utilização de certificado correto durante processo de DCR - HTTP Code 401 (INVALID_CLIENT); 
    &ensp;3.1.2 Validação de Access_Token: Verifica se Access_Token utilizado está correto - HTTP Code 401 (UNAUTHORIZED). 

  1. **Demais validações executadas durante o processamento assíncrono do pagamento pela detentora, poderão ser consultados pela iniciadora através do endpoint _GET /pix/payments/{paymentId}_ previstos com retorno HTTP Code 200 - OK com status RJCT (Rejected) e rejectionReason conforme abaixo (detalhamento adicional na documentação técnica da API):** 

  4.1 **Demais validações durante processamento assíncrono** 
    &ensp;4.1.1 Saldo do usuário: Valida se a conta selecionada possui saldo suficiente para realizar o pagamento. No caso de um pagamento agendado, a validação só ocorre na tentativa de liquidação do pagamento (SALDO_INSUFICIENTE); 
    &ensp;4.1.2 Limites da transação: Valida se valor (ou quantidade de transações) ultrapassa faixa de limite parametrizada na detentora (VALOR_ACIMA_LIMITE); 
    &ensp;4.1.3 Valor informado (QR Code): Valida se valor enviado é válido para o QR Code informado (VALOR_INVALIDO); 
    &ensp;4.1.4 Cobrança inválida: Valida expiração, vencimento e status (COBRANCA_INVALIDA); 
    &ensp;4.1.5 Divergência entre pagamento e consentimento: Valida se dados do pagamento são diferentes dos dados do consentimento (PAGAMENTO_DIVERGENTE_CONSENTIMENTO); 
    &ensp;4.1.6 Recusado pela detentora: Valida se pagamento foi recusado pela detentora (PAGAMENTO_RECUSADO_DETENTORA), com a descrição do motivo de recusa (ex. chave Pix inválida, QRCode inválido, conta bloqueada); 
    &ensp;4.1.7 Detalhes do pagamento: Valida se determinado parâmetro informado obedece às regras de negócio (DETALHE_PAGAMENTO_INVALIDO); 
    &ensp;4.1.8 Demais validações não explicitamente informadas (ex. suspeita de fraude): (NAO_INFORMADO); 
    &ensp;4.1.9 Validação SPI: Externaliza validações no SPI (PAGAMENTO_RECUSADO_SPI); 
  4.2 **Casos de erro para validações assíncronas no DICT** 
    &ensp;Neste cenário o pagamento é criado com sucesso (status RCVD) e o consentimento é consumido (status CONSUMED), porém, as validações contra o DICT só ocorrerão de forma assíncrona e em caso de negativa será percebido pela iniciadora na consulta do pagamento (GET /Payments). 
    &ensp;Retorno esperado do endpoint GET /Payments: HTTP Code 200 - OK. 
    &ensp;Status do Pagamento: RJCT (Rejected), com as seguintes opções rejectionReason: 
    &ensp;• Erro por dados inválidos: Conforme item **4.1.7**; 
    &ensp;• Erro por suspeita de fraude: Conforme item **4.1.8**.

  1. **Demais validações executadas durante o processamento assíncrono do consentimento pela detentora poderão ser consultados pela iniciadora através do endpoint _GET /consents/{consentId}_ previstos com retorno HTTP Code 200 – OK com status REJECTED e rejectionReason conforme abaixo:** 

  5.1 **Validações durante o processamento assíncrono** 
    &ensp;5.1.1 - Falha de infraestrutura: Ocorreu algum erro interno na detentora durante processamento da criação do consentimento (FALHA_INFRAESTRUTURA) 
    &ensp;5.1.2 - Tempo de autorização expirado: O usuário não confirmou o consentimento e o mesmo expirou (TEMPO_EXPIRADO_AUTORIZACAO); 
    &ensp;5.1.3 - Rejeitado pelo usuário: O usuário explicitamente rejeitou a autorização do consentimento (REJEITADO_USUARIO); 
    &ensp;5.1.4 - Mesma conta origem/destino: A conta indicada pelo usuário para recebimento é a mesma selecionada para o pagamento (CONTAS_ORIGEM_DESTINO_IGUAIS); 
    &ensp;5.1.5 - Tipo de conta inválida: A conta indicada não permite operações de pagamento (CONTA_NAO_PERMITE_PAGAMENTO); 
    &ensp;5.1.6 - Saldo do usuário: Valida se a conta selecionada possui saldo suficiente para realizar o pagamento. Essa validação não deverá ocorrer no caso de um pagamento agendado (SALDO_INSUFICIENTE); 
    &ensp;5.1.7 - Limites da transação: Valida se o valor ultrapassa o limite estabelecido [na instituição/no arranjo/outro] para permitir a realização de transações pelo cliente(VALOR_ACIMA_LIMITE); 
    &ensp;5.1.8 - QRCode inválido: O QRCode utilizado para a iniciação de pagamento não é válido (QRCODE_INVALIDO); 
    &ensp;5.1.9 - Valor inválido: O valor enviado não é válido para o QR Code informado (VALOR_INVALIDO); 
    &ensp;5.1.10 - Não informado: Demais validações não explicitamente informadas (ex. suspeita de fraude) e consentimentos rejeitados em versões que não existiam o campo rejectionReason na API de Pagamentos (NAO_INFORMADO) 
    &ensp;5.1.11 - Tempo expirado consumo: O usuário não finalizou o fluxo de pagamento e o consentimento expirou (TEMPO_EXPIRADO_CONSUMO). 
  5.2 **[Momentos obrigatórios de validação dos rejectionReasons de acordo com o funil de consentimentos.](https://openfinancebrasil.atlassian.net/wiki/spaces/OF/pages/150863940)**
 
  ```
  |----------------------------------|------------------------------|
  | Etapas do funil de consentimento | rejectionReason/code         |
  |----------------------------------|------------------------------|
  | Início da autenticação           | FALHA_INFRAESTRUTURA         |
  |                                  | TEMPO_EXPIRADO_AUTORIZACAO   |
  |                                  | NAO_INFORMADO                |
  |----------------------------------|------------------------------|
  | Conclusão da autenticação        | FALHA_INFRAESTRUTURA         |
  |                                  | TEMPO_EXPIRADO_AUTORIZACAO   |
  |                                  | REJEITADO_USUARIO            |
  |                                  | NAO_INFORMADO                |
  |----------------------------------|------------------------------|
  | Autorização do cliente           | FALHA_INFRAESTRUTURA         |
  |                                  | CONTAS_ORIGEM_DESTINO_IGUAIS |
  |                                  | CONTA_NAO_PERMITE_PAGAMENTO  |
  |                                  | SALDO_INSUFICIENTE           |
  |                                  | VALOR_ACIMA_LIMITE           |
  |                                  | QRCODE_INVALIDO              |
  |                                  | VALOR_INVALIDO               |
  |                                  | NAO_INFORMADO                |
  |----------------------------------|------------------------------|
  | Authorisation code emitido       | FALHA_INFRAESTRUTURA         |
  |                                  | TEMPO_EXPIRADO_CONSUMO       |
  |                                  | NAO_INFORMADO                |
  |----------------------------------|------------------------------|
  ```

API de Iniciação de Pagamentos, responsável por viabilizar as operações de iniciação de pagamentos para o Open Finance Brasil.
Para cada uma das formas de pagamento previstas é necessário obter prévio consentimento do cliente através dos `endpoints` dedicados ao consentimento nesta API.

# Orientações
No diretório de participantes duas `Roles` estão relacionadas à presente API:

  • `CONTA`, referente às instituições detentoras de conta participantes do Open Finance Brasil;

  • `PAGTO`, referente às instituições iniciadoras de pagamento participantes do Open Finance Brasil.

Os tokens utilizados para consumo nos endpoints de consentimentos devem possuir o scope `payments` e os `endpoints` de pagamentos devem possuir os `scopes`, `openid` e `payments`.
Esta API não requer a implementação de `permissions` para sua utilização. Todas as requisições e respostas devem ser assinadas seguindo o protocolo estabelecido na sessão <a href="https://openbanking-brasil.github.io/areadesenvolvedor/#assinaturas" target="_blank">Assinaturas</a> do guia de segurança.

## Regras do arranjo Pix
A implementação e o uso da API de Pagamentos Pix devem seguir as regras do arranjo Pix do Banco Central, que podem ser encontradas no link abaixo:  
[https://www.bcb.gov.br/estabilidadefinanceira/pix?modalAberto=regulamentacao_pix](https://www.bcb.gov.br/estabilidadefinanceira/pix?modalAberto=regulamentacao_pix)

## Assinatura de payloads

No contexto da API Payment Initiation, os `payloads` de mensagem que trafegam tanto por parte da instituição iniciadora de transação de pagamento quanto por parte da instituição detentora
de conta devem estar assinados. Para o processo de assinatura destes `payloads` as instituições devem seguir as especificações de segurança publicadas no Portal do desenvolvedor:

  • Certificados exigidos para assinatura de mensagens:

[[EN] Padrão de Certificados Open Finance Brasil 2.1](https://openfinancebrasil.atlassian.net/wiki/spaces/OF/pages/82084176/EN+Padr+o+de+Certificados+Open+Finance+Brasil+2.1%20%E2%80%8B)

## Controle de acesso

Os endpoints de consulta e cancelamento devem suportar somente acesso a partir de access_token emitido por meio de um grant_type do tipo client_credentials.

Para a criação do consentimento deve-se utilizar client_credentials e para criação de pagamentos deve-se utilizar authorization_code.

## Aprovações de múltipla alçada

  • Para o caso de pagamento imediato, todas as aprovações necessárias devem ser realizadas nos canais da detentora até às 23:59 (horário de Brasília) da data de solicitação do pagamento.

Já para o caso de pagamento agendado, todas as aprovações devem ser realizadas até o exato dia anterior à data/hora prevista para primeira liquidação, respeitando a data/hora limite suportada pela detentora.
Caso não seja possível aprovação, o consentimento deve ser rejeitado pelo detentor.

## Validações para pagamentos recorrentes

  • No cenário onde o usuário pagador tenha agendado recorrências para os dias 29, 30 ou 31 de cada mês e o dia previsto na recorrência não exista no respectivo mês,

o iniciador deve enviar a ordem de pagamento para liquidação com o endToEndId representando o dia seguinte à data prevista para a liquidação.
Se identificado pelo detentor que a data enviada no endToEndId corresponde a um dia inexistente, ele deve rejeitar o pagamento com erro 422,
com código PARAMETRO_INVALIDO e detalhe “Data de liquidação inválida”

  • Quando o detentor receber mais de um item na lista de pagamentos enviados pelo iniciador e optar por responder

assincronamente, é de responsabilidade do detentor realizar a transição para o status SCHD de todos os itens enviados na
lista de pagamentos em até 60 minutos (contados a partir da resposta de sucesso da solicitação).
Caso não seja possível realizar a transição de todos os pagamentos para SCHD, o detentor deverá mover todos os pagamentos
enviados pelo iniciador naquela mesma requisição para RJCT e preencher o motivo de rejeição correspondente,
FALHA_AGENDAMENTO_PAGAMENTOS. O consentimento irá para CONSUMED.

## Validações
**Validações** (*após o processo de DCR e obtenção de token client credential*– não escopo dessa documentação) 
Durante a jornada de iniciação de pagamento, diferentes validações são necessárias pela instituição detentora
de conta e devem ocorrer conforme a seguir:

  1. Na criação do consentimento (*POST /consents*);

  2. Na criação do pagamento - Síncrono (*POST /payments*);

  3. Validações na consulta do pagamento (*GET /pix/payments/{paymentId}*);

  4. Demais validações executadas durante o processamento assíncrono do pagamento pela detentora, poderão ser consultados pela iniciadora através do endpoint (*GET /pix/payments/{paymentId}*) previstos com retorno HTTP Code 200 - OK com status RJCT (Rejected) e rejectionReason;

  5. Demais validações executadas durante o processamento assíncrono do consentimento pela detentora poderão ser consultados pela iniciadora através do endpoint (*GET /consents/{consentId}*) previstos com retorno HTTP Code 200 – OK com status REJECTED e rejectionReason

**Os tipos de validações dispostas abaixo não determinam a ordem em que as instituições devem implementá-las**

  1. **Validações na criação do consentimento (_POST /consents_)** 

  1.1 **Orientações Iniciais** 
    &ensp;1.1.1 Não devem ser retornadas na resposta deste endpointinformações associadas ao usuário/cliente (ex.  insuficiência de saldo, conta inexistente/bloqueada). 
    &ensp;1.1.2 Não devem ser executadas validações no DICT (Diretório de Identificadores de Contas Transacionais do Pix), a partir dos dados compartilhados nesse *endpoint*. Tais  validações podem ocorrer somente na criação do pagamento;   
    &ensp;1.1.3 Não devem ser realizadas validações de informações sobre o usuário/cliente durante a criação do consentimento.
  1.2 **Casos de erro relacionados às permissões de segurança para acesso à API (ex. certificado, access_token, jwt, assinatura)** 
    &ensp;1.2.1 Validação de Certificado: Valida utilização de certificado correto durante processo de DCR - HTTP Code 401 (INVALID_CLIENT); 
    &ensp;1.2.2 Validação de Access_Token: Verifica se Access_Token utilizado está correto - HTTP Code 401 (UNAUTHORIZED); 
    &ensp;1.2.3 Validação de assinatura da mensagem: Valida se assinatura das mensagens enviadas está correta – HTTP Code 400 (BAD_SIGNATURE); 
    &ensp;1.2.4 Validação de Claims (exceto data); 
      &emsp;1.2.4.1 Valida se dados (aud, iss, iat e jti) são válidos - HTTP status code 403 – (INVALID_CLIENT); 
      &emsp;1.2.4.2 Valida reuso de jti - HTTP Code 403 (INVALID_CLIENT). 
  1.3 **Casos de erro sintáticos e semânticos, previstos com retorno HTTP Code 422 - Unprocessable Entity (detalhamento adicional na documentação técnica da API):**  
    &ensp;1.3.1 **Sintáticos** 
      &emsp;1.3.1.1 Envio de campos obrigatórios: Valida se todos os campos obrigatórios são informados (PARAMETRO_NAO_INFORMADO); 
      &emsp;1.3.1.2 Formatação de parâmetros: Valida se parâmetros informados obedecem a formatação especificada (PARAMETRO_INVALIDO). 
    &ensp;1.3.2 **Semânticos** 
      &emsp;1.3.2.1 Forma de pagamento: Valida se a forma de pagamento é suportada pela detentora (FORMA_PAGAMENTO_INVALIDA) **Obs. No detalhe do erro, a variável “modalidade” deve ser comunicada pela detentora da forma mais clara possível - ex. modalidade de pagamento não suportada (_localInstrument_ - QRES) ou tipo de arranjo pagamento não suportado (_type_ – ex. Pix / TED – previsto para inclusão futura);** 
      &emsp;1.3.2.2 Data de pagamento: Valida se a data de pagamento enviada é válida para a forma de pagamento selecionada (DATA_PAGAMENTO_INVALIDA); 
      &emsp;1.3.2.3 Detalhes do pagamento: Valida se determinado parâmetro informado obedece às regras de negócio (DETALHE_PAGAMENTO_INVALIDO); 
      &emsp;1.3.2.4 Demais validações não explicitamente informadas (ex. suspeita de fraude): (NAO_INFORMADO); 
      &emsp;1.3.2.5 Idempotência: Valida se há divergência entre chave de idempotência e informações enviadas (ERRO_IDEMPOTENCIA). 

  1. **Validações na criação do pagamento - Síncrono (_POST /payments_)** 

  2.1 **Casos de erro relacionados às permissões de segurança para acesso à API (ex. certificado, access_token, jwt, assinatura)** 
    &ensp;2.1.1 Validação de Certificado: Valida utilização de certificado correto durante processo de DCR - HTTP Code 401 (INVALID_CLIENT); 
    &ensp;2.1.2 Validação de Access_Token: Verifica se Access_Token utilizado está correto - HTTP Code 401 (UNAUTHORIZED); 
    &ensp;2.1.3 Validação de assinatura da mensagem: Valida se assinatura das mensagens enviadas está correta – HTTP Code 400 (BAD_SIGNATURE); 
    &ensp;2.1.4 Validação de Claims (exceto data); 
      &emsp;2.1.4.1 Valida se dados (aud, iss, iat e jti) são válidos - HTTP status code 403 – (INVALID_CLIENT); 
      &emsp;2.1.4.2 Valida reuso de jti - HTTP Code 403 (INVALID_CLIENT). 
  2.2 **Casos de erro sintáticos e semânticos, previstos com retorno HTTP Code 422 - Unprocessable Entity (detalhamento adicional na documentação técnica da API):** 
    &ensp;2.2.1 **Sintáticos** 
      &emsp;2.3.1.1 Envio de campos obrigatórios: Valida se todos os campos obrigatórios são informados (PARAMETRO_NAO_INFORMADO); 
      &emsp;2.3.1.2 Formatação de parâmetros: Valida se parâmetros informados obedecem a formatação especificada (PARAMETRO_INVALIDO). 
    &ensp;2.2.2 **Semânticos** 
      &emsp;2.2.2.1 Saldo do usuário: Valida se a conta selecionada possui saldo suficiente para realizar o pagamento (SALDO_INSUFICIENTE); 
      &emsp;2.2.2.2 Limites da transação: Valida se valor (ou quantidade de transações) ultrapassa faixa de limite parametrizada na detentora (VALOR_ACIMA_LIMITE); 
      &emsp;2.2.2.3 Valor informado (QR Code): Valida se valor enviado é válido para o QR Code informado (VALOR_INVALIDO); 
      &emsp;2.2.2.4 Cobrança inválida: Valida expiração, vencimento e status (COBRANCA_INVALIDA); 
      &emsp;2.2.2.5 Status Consentimento: Valida se o consentimento encontra-se em um dos estados finais “CONSUMED” ou “REJECTED" (CONSENTIMENTO_INVALIDO); 
      &emsp;2.2.2.6 Divergência entre pagamento e consentimento: Valida se dados do pagamento são diferentes dos dados do consentimento (PAGAMENTO_DIVERGENTE_CONSENTIMENTO) 
      &emsp;2.2.2.7 Recusado pela detentora: Valida se pagamento foi recusado pela detentora (PAGAMENTO_RECUSADO_DETENTORA), com a descrição do motivo de recusa (ex. chave Pix inválida, QRCode inválido, conta bloqueada); 
      &emsp;2.2.2.8 Detalhes do pagamento: Valida se determinado parâmetro informado obedece às regras de negócio (DETALHE_PAGAMENTO_INVALIDO); 
      &emsp;2.2.2.9 Demais validações não explicitamente informadas (ex. suspeita de fraude): (NAO_INFORMADO); 
      &emsp;2.2.2.10 Idempotência: Valida se há divergência entre chave de idempotência e informações enviadas (ERRO_IDEMPOTENCIA); 
      &emsp;2.2.2.11 Consentimento pendente de autorização: Em `PARTIALLY_ACCEPTED` aguardando aprovação de múltiplas alçadas. Não consome nem invalida o consentimento (CONSENTIMENTO_PENDENTE_AUTORIZACAO). 
  2.3 **Casos de erro para validações síncronas no DICT** 
    &ensp;Nesse cenário, o pagamento não é criado, porém o consentimento deve ser alterado para o status CONSUMED Retorno esperado do endpoint POST/Payments: HTTP Code 422 - Unprocessable Entity: 
    &ensp;• Erro por dados inválidos: Conforme item **2.2.2.8** 
    &ensp;• Erro por suspeita de fraude: Conforme item **2.2.2.9** 

  1. **Validações na consulta do pagamento (_GET /pix/payments/{paymentId}_)** 

  3.1 **Casos de erro relacionados às permissões de segurança para acesso à API (ex. certificado, access_token)** 
    &ensp;3.1.1 Validação de Certificado: Valida utilização de certificado correto durante processo de DCR - HTTP Code 401 (INVALID_CLIENT); 
    &ensp;3.1.2 Validação de Access_Token: Verifica se Access_Token utilizado está correto - HTTP Code 401 (UNAUTHORIZED). 

  1. **Demais validações executadas durante o processamento assíncrono do pagamento pela detentora, poderão ser consultados pela iniciadora através do endpoint _GET /pix/payments/{paymentId}_ previstos com retorno HTTP Code 200 - OK com status RJCT (Rejected) e rejectionReason conforme abaixo (detalhamento adicional na documentação técnica da API):** 

  4.1 **Demais validações durante processamento assíncrono** 
    &ensp;4.1.1 Saldo do usuário: Valida se a conta selecionada possui saldo suficiente para realizar o pagamento. No caso de um pagamento agendado, a validação só ocorre na tentativa de liquidação do pagamento (SALDO_INSUFICIENTE); 
    &ensp;4.1.2 Limites da transação: Valida se valor (ou quantidade de transações) ultrapassa faixa de limite parametrizada na detentora (VALOR_ACIMA_LIMITE); 
    &ensp;4.1.3 Valor informado (QR Code): Valida se valor enviado é válido para o QR Code informado (VALOR_INVALIDO); 
    &ensp;4.1.4 Cobrança inválida: Valida expiração, vencimento e status (COBRANCA_INVALIDA); 
    &ensp;4.1.5 Divergência entre pagamento e consentimento: Valida se dados do pagamento são diferentes dos dados do consentimento (PAGAMENTO_DIVERGENTE_CONSENTIMENTO); 
    &ensp;4.1.6 Recusado pela detentora: Valida se pagamento foi recusado pela detentora (PAGAMENTO_RECUSADO_DETENTORA), com a descrição do motivo de recusa (ex. chave Pix inválida, QRCode inválido, conta bloqueada); 
    &ensp;4.1.7 Detalhes do pagamento: Valida se determinado parâmetro informado obedece às regras de negócio (DETALHE_PAGAMENTO_INVALIDO); 
    &ensp;4.1.8 Demais validações não explicitamente informadas (ex. suspeita de fraude): (NAO_INFORMADO); 
    &ensp;4.1.9 Validação SPI: Externaliza validações no SPI (PAGAMENTO_RECUSADO_SPI); 
    &ensp;4.1.10 Falha em agendamentos: Uma ou mais incidências de pagamento não foram possíveis de ser agendadas (FALHA_AGENDAMENTO_PAGAMENTOS); 
  4.2 **Casos de erro para validações assíncronas no DICT** 
    &ensp;Neste cenário o pagamento é criado com sucesso (status RCVD) e o consentimento é consumido (status CONSUMED), porém, as validações contra o DICT só ocorrerão de forma assíncrona e em caso de negativa será percebido pela iniciadora na consulta do pagamento (GET /Payments). 
    &ensp;Retorno esperado do endpoint GET /Payments: HTTP Code 200 - OK. 
    &ensp;Status do Pagamento: RJCT (Rejected), com as seguintes opções rejectionReason: 
    &ensp;• Erro por dados inválidos: Conforme item **4.1.7**; 
    &ensp;• Erro por suspeita de fraude: Conforme item **4.1.8**.

  1. **Demais validações executadas durante o processamento assíncrono do consentimento pela detentora poderão ser consultados pela iniciadora através do endpoint _GET /consents/{consentId}_ previstos com retorno HTTP Code 200 – OK com status REJECTED e rejectionReason conforme abaixo:** 

  5.1 **Validações durante o processamento assíncrono** 
    &ensp;5.1.1 - Falha de infraestrutura: Ocorreu algum erro interno na detentora durante processamento da criação do consentimento (FALHA_INFRAESTRUTURA) 
    &ensp;5.1.2 - Tempo de autorização expirado: O usuário não confirmou o consentimento e o mesmo expirou (TEMPO_EXPIRADO_AUTORIZACAO); 
    &ensp;5.1.3 - Rejeitado pelo usuário: O usuário explicitamente rejeitou a autorização do consentimento (REJEITADO_USUARIO); 
    &ensp;5.1.4 - Mesma conta origem/destino: A conta indicada pelo usuário para recebimento é a mesma selecionada para o pagamento (CONTAS_ORIGEM_DESTINO_IGUAIS); 
    &ensp;5.1.5 - Tipo de conta inválida: A conta indicada não permite operações de pagamento (CONTA_NAO_PERMITE_PAGAMENTO); 
    &ensp;5.1.6 - Saldo do usuário: Valida se a conta selecionada possui saldo suficiente para realizar o pagamento. Essa validação não deverá ocorrer no caso de um pagamento agendado (SALDO_INSUFICIENTE); 
    &ensp;5.1.7 - Limites da transação: Valida se o valor ultrapassa o limite estabelecido [na instituição/no arranjo/outro] para permitir a realização de transações pelo cliente (VALOR_ACIMA_LIMITE); 
    &ensp;5.1.8 - QRCode inválido: O QRCode utilizado para a iniciação de pagamento não é válido (QRCODE_INVALIDO); 
    &ensp;5.1.9 - Valor inválido: O valor enviado não é válido para o QR Code informado (VALOR_INVALIDO); 
    &ensp;5.1.10 - Não informado: Demais validações não explicitamente informadas (ex. suspeita de fraude) e consentimentos rejeitados em versões que não existiam o campo rejectionReason na API de Pagamentos (NAO_INFORMADO) 
    &ensp;5.1.11 - Tempo expirado consumo: O usuário não finalizou o fluxo de pagamento e o consentimento expirou (TEMPO_EXPIRADO_CONSUMO). 
  5.2 **[Momentos obrigatórios de validação dos rejectionReasons de acordo com o funil de consentimentos.](https://openfinancebrasil.atlassian.net/wiki/spaces/OF/pages/150863940) Para casos em que um consentimento for rejeitado por mais de um motivo, seguir a ordem de prioridade da tabela.**
 
  ```
  |----------------------------------|------------------------------|---------------------|
  | Etapas do funil de consentimento | rejectionReason/code         | Ordem de prioridade |
  |----------------------------------|------------------------------|---------------------|
  |                                  | TEMPO_EXPIRADO_AUTORIZACAO   |          1          |
  | Início da autenticação           | FALHA_INFRAESTRUTURA         |          2          |
  |                                  | NAO_INFORMADO                |          3          |
  |----------------------------------|------------------------------|---------------------|
  |                                  | TEMPO_EXPIRADO_AUTORIZACAO   |          1          |
  |                                  | REJEITADO_USUARIO            |          2          |
  | Conclusão da autenticação        | FALHA_INFRAESTRUTURA         |          3          |
  |                                  | NAO_INFORMADO                |          4          |
  |----------------------------------|------------------------------|---------------------|
  |                                  | CONTA_NAO_PERMITE_PAGAMENTO  |          1          |
  |                                  | CONTAS_ORIGEM_DESTINO_IGUAIS |          2          |
  |                                  | VALOR_INVALIDO               |          3          |
  | Autorização do cliente           | QRCODE_INVALIDO              |          4          |
  |                                  | VALOR_ACIMA_LIMITE           |          5          |
  |                                  | SALDO_INSUFICIENTE           |          6          |
  |                                  | FALHA_INFRAESTRUTURA         |          7          |
  |                                  | NAO_INFORMADO                |          8          |
  |----------------------------------|------------------------------|---------------------|
  |                                  | FALHA_INFRAESTRUTURA         |          1          |
  | Authorisation code emitido       | NAO_INFORMADO                |          2          |
  |                                  | TEMPO_EXPIRADO_CONSUMO       |          3          |
  |----------------------------------|------------------------------|---------------------|
  ```
  Existem dois `endpoints` para cancelamento de pagamentos, um deles é o _PATCH /pix/payments/{paymentId}_ e o outro é o _PATCH /pix/payments/consents/{consentId}_.

  • O _PATCH /pix/payments/{paymentId}_ deve ser utilizado para o cancelamento de um pagamento de forma unitária. Não deve ser utilizado para o cancelamento de todos os agendamentos recorrentes associados a um consentimento.

  • O _PATCH /pix/payments/consents/{consentId}_ deve ser utilizado no cancelamento de todas as ocorrências de pagamentos agendados presentes em uma recorrência de pagamentos. Todos os pagamentos associados ao consentimento informado e passíveis de cancelamento (ainda não liquidados, com os status PDNG e SCHD) deverão ser cancelados.

 
  ## Quantidade máxima permitida para agendamentos recorrentes
  A quantidade máxima de pagamentos que podem transitar do iniciador para o detentor são de 60 pagamentos, independente do modelo de recorrência definido no consentimento, respeitando o prazo máximo de dois anos para agendamentos.
  Caso a opção de recorrência enviada pelo iniciador não respeite a regra acima, o detentor deve retornar o erro 422 "PARAMETRO_INVALIDO" com o detalhe "Quantidade permitida de pagamentos excedida".

POST /consents

Request

Campo

O que foi alterado?

Tipo da Alteração

Antes

Depois

N° Proposta

Data homologação

post/parameters/Authorization

Adicionado - "minLength"

Adição

1

post/parameters/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

post/parameters/x-fapi-interaction-id

Alterado - "pattern"

Alteração

^[a-zA-Z0-9][a-zA-Z0-9\-]{0,99}$

^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$

post/parameters/x-fapi-interaction-id

Alterado - "maxLength"

Alteração

100

36

post/parameters/x-fapi-interaction-id

Adicionado - "format"

Adição

uuid

post/parameters/x-fapi-interaction-id

Adicionado - "example"

Adição

d78fc4e5-37ca-4da3-adf2-9b082bf92280

post/parameters/x-idempotency-key

Adicionado - "minLength"

Adição

1

post/requestBody/data

Alterado - "description"

Alteração

Objeto contendo as informações de consentimento para a iniciação de pagamento individual.

Objeto contendo as informações de consentimento para a iniciação de pagamento.

post/requestBody/data/payment/details/localInstrument

Alterado - "description"

Alteração

Especifica a forma de iniciação do pagamento:

  • MANU - Inserção manual de dados da conta transacional

  • DICT - Inserção manual de chave Pix

  • QRDN - QR code dinâmico

  • QRES - QR code estático

  • INIC - Indica que o recebedor (creditor) contratou o Iniciador de Pagamentos especificamente para realizar iniciações de pagamento em que o beneficiário é previamente conhecido.

Especifica a forma de iniciação do pagamento:

  • MANU - Inserção manual de dados da conta transacional

  • DICT - Inserção manual de chave Pix

  • QRDN - QR code dinâmico

  • QRES - QR code estático

  • INIC - Indica que o recebedor (creditor) contratou o Iniciador de Pagamentos especificamente para realizar iniciações de pagamento em que o beneficiário é previamente conhecido.

[Restrição] Se /data/payment/schedule enviado com valor diferente de single durante a criação do consentimento, apenas os métodos MANU, DICT ou QRES são permitidos.

post/requestBody/data/payment/schedule

Adicionado - "description"

Adição

[Restrição] Mutuamente excludente com o campo date.
Este campo é obrigatório no caso de agendamento.
Neste caso, o campo date não deverá ser informado.
O prazo máximo para o consentimento deverá ser de dois anos, contando a partir da data de criação do consentimento retornada na criação do mesmo (campo /data/creationDateTime).
Agendamento de pagamento único deve utilizar exclusivamente o objeto "single".

post/requestBody/data/payment/schedule/oneOf

Alterado - "length"

Alteração

1

5

post/requestBody/data/payment/schedule/oneOf

Adicionado - "1"

Adição

post/requestBody/data/payment/schedule/oneOf

Adicionado - "2"

Adição

post/requestBody/data/payment/schedule/oneOf

Adicionado - "3"

Adição

post/requestBody/data/payment/schedule/oneOf

Adicionado - "4"

Adição

post/requestBody/data/payment/schedule/oneOf/0

Removido - "description"

Remoção

[Restrição] Mutuamente excludente com o campo date.

Este campo é obrigatório no caso de agendamento.

Neste caso, o campo date não deve ser informado.

post/requestBody/data/payment/schedule/oneOf/0/single/date

Alterado - "example"

Alteração

01/01/2021

23/08/2023

post/requestBody/data/payment/schedule/oneOf/0/single/date

Alterado - "description"

Alteração

Define a data alvo da liquidação do pagamento.

O fuso horário de Brasília deve ser utilizado para criação e racionalização sobre os dados deste campo.

Observação: Esse campo deverá sempre ser no mínimo D+1 corrido, ou seja, a data imediatamente posterior em relação a data do consentimento considerando o fuso horário de Brasília e deverá ser no máximo D+365 corridos a partir da data do consentimento considerando o fuso horário de Brasília

Define a data alvo da liquidação do pagamento.
O fuso horário de Brasília deve ser utilizado para criação e racionalização sobre os dados deste campo.

[Restrição] Esse campo deverá sempre ser no mínimo D+1 corrido, ou seja, a data imediatamente posterior em
relação a data do consentimento considerando o fuso horário de Brasília e deverá ser no máximo D+730 corridos a
partir da data do consentimento, também considerando o fuso horário de Brasília.

Response

Campo

O que foi alterado?

Tipo da Alteração

Antes

Depois

N° Proposta

Data homologação

post/responses

Removido - "429"

Remoção

post/responses/201/data

Alterado - "description"

Alteração

Objeto contendo as informações de resposta do consentimento para a iniciação de pagamento individual.

Objeto contendo as informações de consentimento para a iniciação de pagamento.

post/responses/201/data/expirationDateTime

Alterado - "description"

Alteração

Data e hora em que o consentimento da iniciação de pagamento expira, devendo ser sempre o creationDateTime mais 5 minutos. Uma string com data e hora conforme especificação RFC-3339, sempre com a utilização de timezone UTC (UTC time format).
O consentimento é criado com o status AWAITING_AUTHORISATION, e deve assumir o status AUTHORIZED ou REJECTED antes do tempo de expiração - 5 minutos. Caso o tempo seja expirado, o status deve assumir REJECTED.
Para o cenário em que o status assumiu AUTHORISED, o tempo máximo do expirationDateTime do consentimento deve assumir "now + 60 minutos". Este é o tempo para consumir o consentimento autorizado, mudando seu status para CONSUMED. Não é possível prorrogar este tempo e a criação de um novo consentimento será necessária para os cenários de insucesso.
O tempo do expirationDateTime é garantido com os 15 minutos do access token, sendo possível utilizar mais três refresh tokens até totalizar 60 minutos.

Data e hora em que o consentimento da iniciação de pagamento expira.
Para consentimentos em status AWAITING_AUTHORISATION, deve ser sempre “creationDateTime + 5 minutos”.
Após esse tempo, não sendo aprovado (seja a aprovação única ou primeiro aprovador), o consentimento deve ir para REJECTED.
Para consentimentos em status PARTIALLY_ACCEPTED, deve assumir o valor da política de aprovação de cada instituição.
Para consentimentos em status AUTHORISED, devem assumir o valor de “statusUpdateDateTime + 60 minutos”, sendo esse o tempo máximo permitido para o consumo do consentimento.
Caso não seja consumido, deve ser movido para o status REJECTED.

post/responses/201/data/payment/details/localInstrument

Alterado - "description"

Alteração

Especifica a forma de iniciação do pagamento:

  • MANU - Inserção manual de dados da conta transacional

  • DICT - Inserção manual de chave Pix

  • QRDN - QR code dinâmico

  • QRES - QR code estático

  • INIC - Indica que o recebedor (creditor) contratou o Iniciador de Pagamentos especificamente para realizar iniciações de pagamento em que o beneficiário é previamente conhecido.

Especifica a forma de iniciação do pagamento:

  • MANU - Inserção manual de dados da conta transacional

  • DICT - Inserção manual de chave Pix

  • QRDN - QR code dinâmico

  • QRES - QR code estático

  • INIC - Indica que o recebedor (creditor) contratou o Iniciador de Pagamentos especificamente para realizar iniciações de pagamento em que o beneficiário é previamente conhecido.

[Restrição] Se /data/payment/schedule enviado com valor diferente de single durante a criação do consentimento, apenas os métodos MANU, DICT ou QRES são permitidos.

post/responses/201/data/payment/schedule

Adicionado - "description"

Adição

[Restrição] Mutuamente excludente com o campo date.
Este campo é obrigatório no caso de agendamento.
Neste caso, o campo date não deverá ser informado.
O prazo máximo para o consentimento deverá ser de dois anos, contando a partir da data de criação do consentimento retornada na criação do mesmo (campo /data/creationDateTime).
Agendamento de pagamento único deve utilizar exclusivamente o objeto "single".

post/responses/201/data/payment/schedule/oneOf

Alterado - "length"

Alteração

1

5

post/responses/201/data/payment/schedule/oneOf

Adicionado - "1"

Adição

post/responses/201/data/payment/schedule/oneOf

Adicionado - "2"

Adição

post/responses/201/data/payment/schedule/oneOf

Adicionado - "3"

Adição

post/responses/201/data/payment/schedule/oneOf

Adicionado - "4"

Adição

post/responses/201/data/payment/schedule/oneOf/0

Removido - "description"

Remoção

[Restrição] Mutuamente excludente com o campo date.

Este campo é obrigatório no caso de agendamento.

Neste caso, o campo date não deve ser informado.

post/responses/201/data/payment/schedule/oneOf/0/single/date

Alterado - "example"

Alteração

01/01/2021

23/08/2023

post/responses/201/data/payment/schedule/oneOf/0/single/date

Alterado - "description"

Alteração

Define a data alvo da liquidação do pagamento.

O fuso horário de Brasília deve ser utilizado para criação e racionalização sobre os dados deste campo.

Observação: Esse campo deverá sempre ser no mínimo D+1 corrido, ou seja, a data imediatamente posterior em relação a data do consentimento considerando o fuso horário de Brasília e deverá ser no máximo D+365 corridos a partir da data do consentimento considerando o fuso horário de Brasília

Define a data alvo da liquidação do pagamento.
O fuso horário de Brasília deve ser utilizado para criação e racionalização sobre os dados deste campo.

[Restrição] Esse campo deverá sempre ser no mínimo D+1 corrido, ou seja, a data imediatamente posterior em
relação a data do consentimento considerando o fuso horário de Brasília e deverá ser no máximo D+730 corridos a
partir da data do consentimento, também considerando o fuso horário de Brasília.

post/responses/201/data/status

Alterado - "description"

Alteração

Retorna o estado do consentimento, o qual no momento de sua criação será AWAITING_AUTHORISATION.
Este estado será alterado depois da autorização do consentimento na detentora da conta do pagador (Debtor) para AUTHORISED ou REJECTED.
O consentimento fica no estado CONSUMED após ocorrer a iniciação do pagamento referente ao consentimento. 
Em caso de consentimento expirado a detentora deverá retornar o status REJECTED. 
Estados possíveis: 
AWAITING_AUTHORISATION - Aguardando autorização 
AUTHORISED - Autorizado  
REJECTED - Rejeitado 
CONSUMED - Consumido

Retorna o estado do consentimento, o qual no momento de sua criação será AWAITING_AUTHORISATION. Na situação de múltiplas alçadas PARTIALLY_ACCEPTED, indica que consentimento precisa da confirmação de mais autorizadores. Este estado será alterado depois da(s) autorização(ões) do(s) consentimento(s) na detentora da conta do pagador (Debtor) para AUTHORISED ou REJECTED. O consentimento fica no estado CONSUMED após ocorrer a iniciação do pagamento referente ao consentimento.

Em caso de consentimento expirado a detentora deverá retornar o status REJECTED.

Estados possíveis:

AWAITING_AUTHORISATION - Aguardando autorização

PARTIALLY_ACCEPTED – Aguardando múltiplas alçadas

AUTHORISED - Autorizado

REJECTED - Rejeitado

CONSUMED - Consumido

post/responses/201/data/status/enum

Adicionado - "PARTIALLY_ACCEPTED"

Adição

enum

post/responses/201/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

post/responses/201/headers/x-fapi-interaction-id

Alterado - "pattern"

Alteração

^[a-zA-Z0-9][a-zA-Z0-9\-]{0,99}$

^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$

post/responses/201/headers/x-fapi-interaction-id

Alterado - "maxLength"

Alteração

100

36

post/responses/201/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

post/responses/201/headers/x-fapi-interaction-id

Adicionado - "minLength"

Adição

1

post/responses/201/headers/x-fapi-interaction-id

Adicionado - "format"

Adição

uuid

post/responses/201/headers/x-fapi-interaction-id

Adicionado - "example"

Adição

d78fc4e5-37ca-4da3-adf2-9b082bf92280

post/responses/400/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

post/responses/400/headers/x-fapi-interaction-id

Alterado - "pattern"

Alteração

^[a-zA-Z0-9][a-zA-Z0-9\-]{0,99}$

^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$

post/responses/400/headers/x-fapi-interaction-id

Alterado - "maxLength"

Alteração

100

36

post/responses/400/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

post/responses/400/headers/x-fapi-interaction-id

Adicionado - "minLength"

Adição

1

post/responses/400/headers/x-fapi-interaction-id

Adicionado - "format"

Adição

uuid

post/responses/400/headers/x-fapi-interaction-id

Adicionado - "example"

Adição

d78fc4e5-37ca-4da3-adf2-9b082bf92280

post/responses/401/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

post/responses/401/headers/x-fapi-interaction-id

Alterado - "pattern"

Alteração

^[a-zA-Z0-9][a-zA-Z0-9\-]{0,99}$

^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$

post/responses/401/headers/x-fapi-interaction-id

Alterado - "maxLength"

Alteração

100

36

post/responses/401/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

post/responses/401/headers/x-fapi-interaction-id

Adicionado - "minLength"

Adição

1

post/responses/401/headers/x-fapi-interaction-id

Adicionado - "format"

Adição

uuid

post/responses/401/headers/x-fapi-interaction-id

Adicionado - "example"

Adição

d78fc4e5-37ca-4da3-adf2-9b082bf92280

post/responses/403/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

post/responses/403/headers/x-fapi-interaction-id

Alterado - "pattern"

Alteração

^[a-zA-Z0-9][a-zA-Z0-9\-]{0,99}$

^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$

post/responses/403/headers/x-fapi-interaction-id

Alterado - "maxLength"

Alteração

100

36

post/responses/403/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

post/responses/403/headers/x-fapi-interaction-id

Adicionado - "minLength"

Adição

1

post/responses/403/headers/x-fapi-interaction-id

Adicionado - "format"

Adição

uuid

post/responses/403/headers/x-fapi-interaction-id

Adicionado - "example"

Adição

d78fc4e5-37ca-4da3-adf2-9b082bf92280

post/responses/404/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

post/responses/404/headers/x-fapi-interaction-id

Alterado - "pattern"

Alteração

^[a-zA-Z0-9][a-zA-Z0-9\-]{0,99}$

^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$

post/responses/404/headers/x-fapi-interaction-id

Alterado - "maxLength"

Alteração

100

36

post/responses/404/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

post/responses/404/headers/x-fapi-interaction-id

Adicionado - "minLength"

Adição

1

post/responses/404/headers/x-fapi-interaction-id

Adicionado - "format"

Adição

uuid

post/responses/404/headers/x-fapi-interaction-id

Adicionado - "example"

Adição

d78fc4e5-37ca-4da3-adf2-9b082bf92280

post/responses/405/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

post/responses/405/headers/x-fapi-interaction-id

Alterado - "pattern"

Alteração

^[a-zA-Z0-9][a-zA-Z0-9\-]{0,99}$

^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$

post/responses/405/headers/x-fapi-interaction-id

Alterado - "maxLength"

Alteração

100

36

post/responses/405/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

post/responses/405/headers/x-fapi-interaction-id

Adicionado - "minLength"

Adição

1

post/responses/405/headers/x-fapi-interaction-id

Adicionado - "format"

Adição

uuid

post/responses/405/headers/x-fapi-interaction-id

Adicionado - "example"

Adição

d78fc4e5-37ca-4da3-adf2-9b082bf92280

post/responses/406/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

post/responses/406/headers/x-fapi-interaction-id

Alterado - "pattern"

Alteração

^[a-zA-Z0-9][a-zA-Z0-9\-]{0,99}$

^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$

post/responses/406/headers/x-fapi-interaction-id

Alterado - "maxLength"

Alteração

100

36

post/responses/406/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

post/responses/406/headers/x-fapi-interaction-id

Adicionado - "minLength"

Adição

1

post/responses/406/headers/x-fapi-interaction-id

Adicionado - "format"

Adição

uuid

post/responses/406/headers/x-fapi-interaction-id

Adicionado - "example"

Adição

d78fc4e5-37ca-4da3-adf2-9b082bf92280

post/responses/415/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

post/responses/415/headers/x-fapi-interaction-id

Alterado - "pattern"

Alteração

^[a-zA-Z0-9][a-zA-Z0-9\-]{0,99}$

^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$

post/responses/415/headers/x-fapi-interaction-id

Alterado - "maxLength"

Alteração

100

36

post/responses/415/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

post/responses/415/headers/x-fapi-interaction-id

Adicionado - "minLength"

Adição

1

post/responses/415/headers/x-fapi-interaction-id

Adicionado - "format"

Adição

uuid

post/responses/415/headers/x-fapi-interaction-id

Adicionado - "example"

Adição

d78fc4e5-37ca-4da3-adf2-9b082bf92280

post/responses/422/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

post/responses/422/headers/x-fapi-interaction-id

Alterado - "pattern"

Alteração

^[a-zA-Z0-9][a-zA-Z0-9\-]{0,99}$

^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$

post/responses/422/headers/x-fapi-interaction-id

Alterado - "maxLength"

Alteração

100

36

post/responses/422/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

post/responses/422/headers/x-fapi-interaction-id

Adicionado - "minLength"

Adição

1

post/responses/422/headers/x-fapi-interaction-id

Adicionado - "format"

Adição

uuid

post/responses/422/headers/x-fapi-interaction-id

Adicionado - "example"

Adição

d78fc4e5-37ca-4da3-adf2-9b082bf92280

post/responses/500/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

post/responses/500/headers/x-fapi-interaction-id

Alterado - "pattern"

Alteração

^[a-zA-Z0-9][a-zA-Z0-9\-]{0,99}$

^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$

post/responses/500/headers/x-fapi-interaction-id

Alterado - "maxLength"

Alteração

100

36

post/responses/500/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

post/responses/500/headers/x-fapi-interaction-id

Adicionado - "minLength"

Adição

1

post/responses/500/headers/x-fapi-interaction-id

Adicionado - "format"

Adição

uuid

post/responses/500/headers/x-fapi-interaction-id

Adicionado - "example"

Adição

d78fc4e5-37ca-4da3-adf2-9b082bf92280

GET /consents/{consentId}

Request

Campo

O que foi alterado?

Tipo da Alteração

Antes

Depois

N° Proposta

Data homologação

get/parameters/Authorization

Adicionado - "minLength"

Adição

1

get/parameters/consentId

Adicionado - "minLength"

Adição

1

get/parameters/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

get/parameters/x-fapi-interaction-id

Alterado - "pattern"

Alteração

^[a-zA-Z0-9][a-zA-Z0-9\-]{0,99}$

^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$

get/parameters/x-fapi-interaction-id

Alterado - "maxLength"

Alteração

100

36

get/parameters/x-fapi-interaction-id

Adicionado - "format"

Adição

uuid

get/parameters/x-fapi-interaction-id

Adicionado - "example"

Adição

d78fc4e5-37ca-4da3-adf2-9b082bf92280

Response

Campo

O que foi alterado?

Tipo da Alteração

Antes

Depois

N° Proposta

Data homologação

get/responses

Removido - "429"

Remoção

get/responses/200/data

Alterado - "description"

Alteração

Objeto contendo as informações de resposta do consentimento para a iniciação de pagamento individual.

Objeto contendo as informações de consentimento para a iniciação de pagamento.

get/responses/200/data/expirationDateTime

Alterado - "description"

Alteração

Data e hora em que o consentimento da iniciação de pagamento expira, devendo ser sempre o creationDateTime mais 5 minutos. Uma string com data e hora conforme especificação RFC-3339, sempre com a utilização de timezone UTC (UTC time format).
O consentimento é criado com o status AWAITING_AUTHORISATION, e deve assumir o status AUTHORIZED ou REJECTED antes do tempo de expiração - 5 minutos. Caso o tempo seja expirado, o status deve assumir REJECTED.
Para o cenário em que o status assumiu AUTHORISED, o tempo máximo do expirationDateTime do consentimento deve assumir "now + 60 minutos". Este é o tempo para consumir o consentimento autorizado, mudando seu status para CONSUMED. Não é possível prorrogar este tempo e a criação de um novo consentimento será necessária para os cenários de insucesso.
O tempo do expirationDateTime é garantido com os 15 minutos do access token, sendo possível utilizar mais três refresh tokens até totalizar 60 minutos.

Data e hora em que o consentimento da iniciação de pagamento expira.
Para consentimentos em status AWAITING_AUTHORISATION, deve ser sempre “creationDateTime + 5 minutos”.
Após esse tempo, não sendo aprovado (seja a aprovação única ou primeiro aprovador), o consentimento deve ir para REJECTED.
Para consentimentos em status PARTIALLY_ACCEPTED, deve assumir o valor da política de aprovação de cada instituição.
Para consentimentos em status AUTHORISED, devem assumir o valor de “statusUpdateDateTime + 60 minutos”, sendo esse o tempo máximo permitido para o consumo do consentimento.
Caso não seja consumido, deve ser movido para o status REJECTED.

get/responses/200/data/payment/details/localInstrument

Alterado - "description"

Alteração

Especifica a forma de iniciação do pagamento:

  • MANU - Inserção manual de dados da conta transacional

  • DICT - Inserção manual de chave Pix

  • QRDN - QR code dinâmico

  • QRES - QR code estático

  • INIC - Indica que o recebedor (creditor) contratou o Iniciador de Pagamentos especificamente para realizar iniciações de pagamento em que o beneficiário é previamente conhecido.

Especifica a forma de iniciação do pagamento:

  • MANU - Inserção manual de dados da conta transacional

  • DICT - Inserção manual de chave Pix

  • QRDN - QR code dinâmico

  • QRES - QR code estático

  • INIC - Indica que o recebedor (creditor) contratou o Iniciador de Pagamentos especificamente para realizar iniciações de pagamento em que o beneficiário é previamente conhecido.

[Restrição] Se /data/payment/schedule enviado com valor diferente de single durante a criação do consentimento, apenas os métodos MANU, DICT ou QRES são permitidos.

get/responses/200/data/payment/schedule

Adicionado - "description"

Adição

[Restrição] Mutuamente excludente com o campo date.
Este campo é obrigatório no caso de agendamento.
Neste caso, o campo date não deverá ser informado.
O prazo máximo para o consentimento deverá ser de dois anos, contando a partir da data de criação do consentimento retornada na criação do mesmo (campo /data/creationDateTime).
Agendamento de pagamento único deve utilizar exclusivamente o objeto "single".

get/responses/200/data/payment/schedule/oneOf

Alterado - "length"

Alteração

1

5

get/responses/200/data/payment/schedule/oneOf

Adicionado - "1"

Adição

get/responses/200/data/payment/schedule/oneOf

Adicionado - "2"

Adição

get/responses/200/data/payment/schedule/oneOf

Adicionado - "3"

Adição

get/responses/200/data/payment/schedule/oneOf

Adicionado - "4"

Adição

get/responses/200/data/payment/schedule/oneOf/0

Removido - "description"

Remoção

[Restrição] Mutuamente excludente com o campo date.

Este campo é obrigatório no caso de agendamento.

Neste caso, o campo date não deve ser informado.

get/responses/200/data/payment/schedule/oneOf/0/single/date

Alterado - "example"

Alteração

01/01/2021

23/08/2023

get/responses/200/data/payment/schedule/oneOf/0/single/date

Alterado - "description"

Alteração

Define a data alvo da liquidação do pagamento.

O fuso horário de Brasília deve ser utilizado para criação e racionalização sobre os dados deste campo.

Observação: Esse campo deverá sempre ser no mínimo D+1 corrido, ou seja, a data imediatamente posterior em relação a data do consentimento considerando o fuso horário de Brasília e deverá ser no máximo D+365 corridos a partir da data do consentimento considerando o fuso horário de Brasília

Define a data alvo da liquidação do pagamento.
O fuso horário de Brasília deve ser utilizado para criação e racionalização sobre os dados deste campo.

[Restrição] Esse campo deverá sempre ser no mínimo D+1 corrido, ou seja, a data imediatamente posterior em
relação a data do consentimento considerando o fuso horário de Brasília e deverá ser no máximo D+730 corridos a
partir da data do consentimento, também considerando o fuso horário de Brasília.

get/responses/200/data/status

Alterado - "description"

Alteração

Retorna o estado do consentimento, o qual no momento de sua criação será AWAITING_AUTHORISATION.
Este estado será alterado depois da autorização do consentimento na detentora da conta do pagador (Debtor) para AUTHORISED ou REJECTED.
O consentimento fica no estado CONSUMED após ocorrer a iniciação do pagamento referente ao consentimento. 
Em caso de consentimento expirado a detentora deverá retornar o status REJECTED. 
Estados possíveis: 
AWAITING_AUTHORISATION - Aguardando autorização 
AUTHORISED - Autorizado  
REJECTED - Rejeitado 
CONSUMED - Consumido

Retorna o estado do consentimento, o qual no momento de sua criação será AWAITING_AUTHORISATION. Na situação de múltiplas alçadas PARTIALLY_ACCEPTED, indica que consentimento precisa da confirmação de mais autorizadores. Este estado será alterado depois da(s) autorização(ões) do(s) consentimento(s) na detentora da conta do pagador (Debtor) para AUTHORISED ou REJECTED. O consentimento fica no estado CONSUMED após ocorrer a iniciação do pagamento referente ao consentimento.

Em caso de consentimento expirado a detentora deverá retornar o status REJECTED.

Estados possíveis:

AWAITING_AUTHORISATION - Aguardando autorização

PARTIALLY_ACCEPTED – Aguardando múltiplas alçadas

AUTHORISED - Autorizado

REJECTED - Rejeitado

CONSUMED - Consumido

get/responses/200/data/status/enum

Adicionado - "PARTIALLY_ACCEPTED"

Adição

enum

get/responses/200/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

get/responses/200/headers/x-fapi-interaction-id

Alterado - "pattern"

Alteração

^[a-zA-Z0-9][a-zA-Z0-9\-]{0,99}$

^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$

get/responses/200/headers/x-fapi-interaction-id

Alterado - "maxLength"

Alteração

100

36

get/responses/200/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

get/responses/200/headers/x-fapi-interaction-id

Adicionado - "minLength"

Adição

1

get/responses/200/headers/x-fapi-interaction-id

Adicionado - "format"

Adição

uuid

get/responses/200/headers/x-fapi-interaction-id

Adicionado - "example"

Adição

d78fc4e5-37ca-4da3-adf2-9b082bf92280

get/responses/400/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

get/responses/400/headers/x-fapi-interaction-id

Alterado - "pattern"

Alteração

^[a-zA-Z0-9][a-zA-Z0-9\-]{0,99}$

^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$

get/responses/400/headers/x-fapi-interaction-id

Alterado - "maxLength"

Alteração

100

36

get/responses/400/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

get/responses/400/headers/x-fapi-interaction-id

Adicionado - "minLength"

Adição

1

get/responses/400/headers/x-fapi-interaction-id

Adicionado - "format"

Adição

uuid

get/responses/400/headers/x-fapi-interaction-id

Adicionado - "example"

Adição

d78fc4e5-37ca-4da3-adf2-9b082bf92280

get/responses/401/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

get/responses/401/headers/x-fapi-interaction-id

Alterado - "pattern"

Alteração

^[a-zA-Z0-9][a-zA-Z0-9\-]{0,99}$

^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$

get/responses/401/headers/x-fapi-interaction-id

Alterado - "maxLength"

Alteração

100

36

get/responses/401/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

get/responses/401/headers/x-fapi-interaction-id

Adicionado - "minLength"

Adição

1

get/responses/401/headers/x-fapi-interaction-id

Adicionado - "format"

Adição

uuid

get/responses/401/headers/x-fapi-interaction-id

Adicionado - "example"

Adição

d78fc4e5-37ca-4da3-adf2-9b082bf92280

get/responses/403/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

get/responses/403/headers/x-fapi-interaction-id

Alterado - "pattern"

Alteração

^[a-zA-Z0-9][a-zA-Z0-9\-]{0,99}$

^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$

get/responses/403/headers/x-fapi-interaction-id

Alterado - "maxLength"

Alteração

100

36

get/responses/403/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

get/responses/403/headers/x-fapi-interaction-id

Adicionado - "minLength"

Adição

1

get/responses/403/headers/x-fapi-interaction-id

Adicionado - "format"

Adição

uuid

get/responses/403/headers/x-fapi-interaction-id

Adicionado - "example"

Adição

d78fc4e5-37ca-4da3-adf2-9b082bf92280

get/responses/404/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

get/responses/404/headers/x-fapi-interaction-id

Alterado - "pattern"

Alteração

^[a-zA-Z0-9][a-zA-Z0-9\-]{0,99}$

^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$

get/responses/404/headers/x-fapi-interaction-id

Alterado - "maxLength"

Alteração

100

36

get/responses/404/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

get/responses/404/headers/x-fapi-interaction-id

Adicionado - "minLength"

Adição

1

get/responses/404/headers/x-fapi-interaction-id

Adicionado - "format"

Adição

uuid

get/responses/404/headers/x-fapi-interaction-id

Adicionado - "example"

Adição

d78fc4e5-37ca-4da3-adf2-9b082bf92280

get/responses/405/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

get/responses/405/headers/x-fapi-interaction-id

Alterado - "pattern"

Alteração

^[a-zA-Z0-9][a-zA-Z0-9\-]{0,99}$

^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$

get/responses/405/headers/x-fapi-interaction-id

Alterado - "maxLength"

Alteração

100

36

get/responses/405/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

get/responses/405/headers/x-fapi-interaction-id

Adicionado - "minLength"

Adição

1

get/responses/405/headers/x-fapi-interaction-id

Adicionado - "format"

Adição

uuid

get/responses/405/headers/x-fapi-interaction-id

Adicionado - "example"

Adição

d78fc4e5-37ca-4da3-adf2-9b082bf92280

get/responses/406/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

get/responses/406/headers/x-fapi-interaction-id

Alterado - "pattern"

Alteração

^[a-zA-Z0-9][a-zA-Z0-9\-]{0,99}$

^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$

get/responses/406/headers/x-fapi-interaction-id

Alterado - "maxLength"

Alteração

100

36

get/responses/406/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

get/responses/406/headers/x-fapi-interaction-id

Adicionado - "minLength"

Adição

1

get/responses/406/headers/x-fapi-interaction-id

Adicionado - "format"

Adição

uuid

get/responses/406/headers/x-fapi-interaction-id

Adicionado - "example"

Adição

d78fc4e5-37ca-4da3-adf2-9b082bf92280

get/responses/500/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

get/responses/500/headers/x-fapi-interaction-id

Alterado - "pattern"

Alteração

^[a-zA-Z0-9][a-zA-Z0-9\-]{0,99}$

^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$

get/responses/500/headers/x-fapi-interaction-id

Alterado - "maxLength"

Alteração

100

36

get/responses/500/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

get/responses/500/headers/x-fapi-interaction-id

Adicionado - "minLength"

Adição

1

get/responses/500/headers/x-fapi-interaction-id

Adicionado - "format"

Adição

uuid

get/responses/500/headers/x-fapi-interaction-id

Adicionado - "example"

Adição

d78fc4e5-37ca-4da3-adf2-9b082bf92280

POST /pix/payments

Request

Campo

O que foi alterado?

Tipo da Alteração

Antes

Depois

N° Proposta

Data homologação

post/parameters/Authorization

Adicionado - "minLength"

Adição

1

post/parameters/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

post/parameters/x-fapi-interaction-id

Alterado - "pattern"

Alteração

^[a-zA-Z0-9][a-zA-Z0-9\-]{0,99}$

^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$

post/parameters/x-fapi-interaction-id

Alterado - "maxLength"

Alteração

100

36

post/parameters/x-fapi-interaction-id

Adicionado - "format"

Adição

uuid

post/parameters/x-fapi-interaction-id

Adicionado - "example"

Adição

d78fc4e5-37ca-4da3-adf2-9b082bf92280

post/parameters/x-idempotency-key

Adicionado - "minLength"

Adição

1

post/requestBody/data

Alterado - "type"

Alteração

object

array

post/requestBody/data

Removido - "description"

Remoção

Objeto contendo dados do pagamento e do recebedor (creditor).

post/requestBody/data

Removido - "required"

Remoção

post/requestBody/data

Removido - "properties"

Remoção

post/requestBody/data

Adicionado - "minItems"

Adição

1

post/requestBody/data

Adicionado - "items"

Adição

Response

Campo

O que foi alterado?

Tipo da Alteração

Antes

Depois

N° Proposta

Data homologação

post/responses

Removido - "429"

Remoção

post/responses/201/data

Alterado - "type"

Alteração

object

array

post/responses/201/data

Removido - "description"

Remoção

Objeto contendo dados do pagamento e da conta do recebedor (creditor).

post/responses/201/data

Removido - "required"

Remoção

post/responses/201/data

Removido - "properties"

Remoção

post/responses/201/data

Adicionado - "items"

Adição

post/responses/201/links/self

Alterado - "description"

Alteração

URI completo que gerou a resposta atual.

URI completo para o primeiro item presente na resposta.

post/responses/201/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

post/responses/201/headers/x-fapi-interaction-id

Alterado - "pattern"

Alteração

^[a-zA-Z0-9][a-zA-Z0-9\-]{0,99}$

^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$

post/responses/201/headers/x-fapi-interaction-id

Alterado - "maxLength"

Alteração

100

36

post/responses/201/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

post/responses/201/headers/x-fapi-interaction-id

Adicionado - "minLength"

Adição

1

post/responses/201/headers/x-fapi-interaction-id

Adicionado - "format"

Adição

uuid

post/responses/201/headers/x-fapi-interaction-id

Adicionado - "example"

Adição

d78fc4e5-37ca-4da3-adf2-9b082bf92280

post/responses/400/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

post/responses/400/headers/x-fapi-interaction-id

Alterado - "pattern"

Alteração

^[a-zA-Z0-9][a-zA-Z0-9\-]{0,99}$

^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$

post/responses/400/headers/x-fapi-interaction-id

Alterado - "maxLength"

Alteração

100

36

post/responses/400/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

post/responses/400/headers/x-fapi-interaction-id

Adicionado - "minLength"

Adição

1

post/responses/400/headers/x-fapi-interaction-id

Adicionado - "format"

Adição

uuid

post/responses/400/headers/x-fapi-interaction-id

Adicionado - "example"

Adição

d78fc4e5-37ca-4da3-adf2-9b082bf92280

post/responses/401/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

post/responses/401/headers/x-fapi-interaction-id

Alterado - "pattern"

Alteração

^[a-zA-Z0-9][a-zA-Z0-9\-]{0,99}$

^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$

post/responses/401/headers/x-fapi-interaction-id

Alterado - "maxLength"

Alteração

100

36

post/responses/401/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

post/responses/401/headers/x-fapi-interaction-id

Adicionado - "minLength"

Adição

1

post/responses/401/headers/x-fapi-interaction-id

Adicionado - "format"

Adição

uuid

post/responses/401/headers/x-fapi-interaction-id

Adicionado - "example"

Adição

d78fc4e5-37ca-4da3-adf2-9b082bf92280

post/responses/403/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

post/responses/403/headers/x-fapi-interaction-id

Alterado - "pattern"

Alteração

^[a-zA-Z0-9][a-zA-Z0-9\-]{0,99}$

^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$

post/responses/403/headers/x-fapi-interaction-id

Alterado - "maxLength"

Alteração

100

36

post/responses/403/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

post/responses/403/headers/x-fapi-interaction-id

Adicionado - "minLength"

Adição

1

post/responses/403/headers/x-fapi-interaction-id

Adicionado - "format"

Adição

uuid

post/responses/403/headers/x-fapi-interaction-id

Adicionado - "example"

Adição

d78fc4e5-37ca-4da3-adf2-9b082bf92280

post/responses/404/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

post/responses/404/headers/x-fapi-interaction-id

Alterado - "pattern"

Alteração

^[a-zA-Z0-9][a-zA-Z0-9\-]{0,99}$

^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$

post/responses/404/headers/x-fapi-interaction-id

Alterado - "maxLength"

Alteração

100

36

post/responses/404/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

post/responses/404/headers/x-fapi-interaction-id

Adicionado - "minLength"

Adição

1

post/responses/404/headers/x-fapi-interaction-id

Adicionado - "format"

Adição

uuid

post/responses/404/headers/x-fapi-interaction-id

Adicionado - "example"

Adição

d78fc4e5-37ca-4da3-adf2-9b082bf92280

post/responses/405/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

post/responses/405/headers/x-fapi-interaction-id

Alterado - "pattern"

Alteração

^[a-zA-Z0-9][a-zA-Z0-9\-]{0,99}$

^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$

post/responses/405/headers/x-fapi-interaction-id

Alterado - "maxLength"

Alteração

100

36

post/responses/405/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

post/responses/405/headers/x-fapi-interaction-id

Adicionado - "minLength"

Adição

1

post/responses/405/headers/x-fapi-interaction-id

Adicionado - "format"

Adição

uuid

post/responses/405/headers/x-fapi-interaction-id

Adicionado - "example"

Adição

d78fc4e5-37ca-4da3-adf2-9b082bf92280

post/responses/406/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

post/responses/406/headers/x-fapi-interaction-id

Alterado - "pattern"

Alteração

^[a-zA-Z0-9][a-zA-Z0-9\-]{0,99}$

^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$

post/responses/406/headers/x-fapi-interaction-id

Alterado - "maxLength"

Alteração

100

36

post/responses/406/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

post/responses/406/headers/x-fapi-interaction-id

Adicionado - "minLength"

Adição

1

post/responses/406/headers/x-fapi-interaction-id

Adicionado - "format"

Adição

uuid

post/responses/406/headers/x-fapi-interaction-id

Adicionado - "example"

Adição

d78fc4e5-37ca-4da3-adf2-9b082bf92280

post/responses/415/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

post/responses/415/headers/x-fapi-interaction-id

Alterado - "pattern"

Alteração

^[a-zA-Z0-9][a-zA-Z0-9\-]{0,99}$

^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$

post/responses/415/headers/x-fapi-interaction-id

Alterado - "maxLength"

Alteração

100

36

post/responses/415/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

post/responses/415/headers/x-fapi-interaction-id

Adicionado - "minLength"

Adição

1

post/responses/415/headers/x-fapi-interaction-id

Adicionado - "format"

Adição

uuid

post/responses/415/headers/x-fapi-interaction-id

Adicionado - "example"

Adição

d78fc4e5-37ca-4da3-adf2-9b082bf92280

post/responses/422/errors/items/code

Alterado - "description"

Alteração

Códigos de erros previstos na criação da iniciação de pagamento:

  • SALDO_INSUFICIENTE: Esta conta não possui saldo suficiente para realizar o pagamento.

  • VALOR_ACIMA_LIMITE: O valor (ou quantidade de transações) ultrapassa a faixa de limite parametrizada na detentora para permitir a realização de transações pelo cliente.

  • VALOR_INVALIDO: O valor enviado não é válido para o QR Code informado.

  • COBRANCA_INVALIDA: Validação de expiração, validação de vencimento, Status Válido.

  • CONSENTIMENTO_INVALIDO: Consentimento inválido (status não é "authorised" ou está expirado).

  • PARAMETRO_NAO_INFORMADO: Parâmetro não informado. 

  • PARAMETRO_INVALIDO: Parâmetro inválido.

  • NAO_INFORMADO: Não informada pela detentora de conta.

  • PAGAMENTO_DIVERGENTE_CONSENTIMENTO: Dados do pagamento divergentes dos dados do consentimento.

  • DETALHE_PAGAMENTO_INVALIDO: Detalhe do pagamento inválido.

  • PAGAMENTO_RECUSADO_DETENTORA: Pagamento recusado pela detentora de conta.

  • PAGAMENTO_RECUSADO_SPI: Pagamento recusado no Sistema de Pagamentos Instantâneos (SPI).

  • ERRO_IDEMPOTENCIA: Erro idempotência.

Códigos de erros previstos na criação da iniciação de pagamento:

  • SALDO_INSUFICIENTE: Esta conta não possui saldo suficiente para realizar o pagamento.

  • VALOR_ACIMA_LIMITE: O valor (ou quantidade de transações) ultrapassa a faixa de limite parametrizada na detentora para permitir a realização de transações pelo cliente.

  • VALOR_INVALIDO: O valor enviado não é válido para o QR Code informado.

  • COBRANCA_INVALIDA: Validação de expiração, validação de vencimento, Status Válido.

  • CONSENTIMENTO_INVALIDO – Consentimento inválido (em status final).

  • PARAMETRO_NAO_INFORMADO: Parâmetro não informado. 

  • PARAMETRO_INVALIDO: Parâmetro inválido.

  • NAO_INFORMADO: Não informada pela detentora de conta.

  • PAGAMENTO_DIVERGENTE_CONSENTIMENTO: Dados do pagamento divergentes dos dados do consentimento.

  • DETALHE_PAGAMENTO_INVALIDO: Detalhe do pagamento inválido.

  • PAGAMENTO_RECUSADO_DETENTORA: Pagamento recusado pela detentora de conta.

  • PAGAMENTO_RECUSADO_SPI: Pagamento recusado no Sistema de Pagamentos Instantâneos (SPI).

  • ERRO_IDEMPOTENCIA: Erro idempotência.

  • CONSENTIMENTO_PENDENTE_AUTORIZACAO: Consentimento pendente autorização de múltiplas alçadas (status “PARTIALLY_ACCEPTED”)

post/responses/422/errors/items/code/enum

Adicionado - "CONSENTIMENTO_PENDENTE_AUTORIZACAO"

Adição

enum

post/responses/422/errors/items/detail

Alterado - "description"

Alteração

Descrição específica do erro de acordo com o código reportado:

  • SALDO_INSUFICIENTE: A conta selecionada não possui saldo suficiente para realizar o pagamento.

  • VALOR_ACIMA_LIMITE: O valor (ou quantidade de transações) ultrapassa a faixa de limite parametrizada na detentora para permitir a realização de transações pelo cliente.

  • VALOR_INVALIDO: O valor enviado não é válido para o QR Code informado.

  • COBRANCA_INVALIDA: Validação de expiração, validação de vencimento ou Status Válido.

  • CONSENTIMENTO_INVALIDO: Consentimento inválido (status diferente de "AUTHORISED" ou está expirado).

  • PARAMETRO_NAO_INFORMADO: endToEndId

  • PARAMETRO_INVALIDO: endToEndId

  • NAO_INFORMADO: Não reportado/identificado pela instituição detentora de conta.

  • PAGAMENTO_DIVERGENTE_CONSENTIMENTO: Dados do pagamento divergentes dos dados do consentimento.

  • DETALHE_PAGAMENTO_INVALIDO: Parâmetro [nome_campo] não obedece às regras de negócio.

  • PAGAMENTO_RECUSADO_DETENTORA: [descrição do motivo de recusa].

  • PAGAMENTO_RECUSADO_SPI: [código de erro conforme tabela de domínios reason PACS.002].

  • ERRO_IDEMPOTENCIA: Conteúdo da mensagem (claim data) diverge do conteúdo associado a esta chave de idempotência (x-idempotency-key).

Descrição específica do erro de acordo com o código reportado:

  • SALDO_INSUFICIENTE: A conta selecionada não possui saldo suficiente para realizar o pagamento.

  • VALOR_ACIMA_LIMITE: O valor (ou quantidade de transações) ultrapassa a faixa de limite parametrizada na detentora para permitir a realização de transações pelo cliente.

  • VALOR_INVALIDO: O valor enviado não é válido para o QR Code informado.

  • COBRANCA_INVALIDA: Validação de expiração, validação de vencimento ou Status Válido.

  • CONSENTIMENTO_INVALIDO – Consentimento inválido (em status final).

  • PARAMETRO_NAO_INFORMADO: endToEndId

  • PARAMETRO_INVALIDO: endToEndId

  • NAO_INFORMADO: Não reportado/identificado pela instituição detentora de conta.

  • PAGAMENTO_DIVERGENTE_CONSENTIMENTO: Dados do pagamento divergentes dos dados do consentimento.

  • DETALHE_PAGAMENTO_INVALIDO: Parâmetro [nome_campo] não obedece às regras de negócio.

  • PAGAMENTO_RECUSADO_DETENTORA: [descrição do motivo de recusa].

  • PAGAMENTO_RECUSADO_SPI: [código de erro conforme tabela de domínios reason PACS.002].

  • ERRO_IDEMPOTENCIA: Conteúdo da mensagem (claim data) diverge do conteúdo associado a esta chave de idempotência (x-idempotency-key).

  • CONSENTIMENTO_PENDENTE_AUTORIZACAO: Consentimento pendente autorização de múltiplas alçadas (status “PARTIALLY_ACCEPTED”).

post/responses/422/errors/items/title

Alterado - "description"

Alteração

Título específico do erro reportado, de acordo com o código enviado:

  • SALDO_INSUFICIENTE: Saldo insuficiente.

  • VALOR_ACIMA_LIMITE: Acima do limite estabelecido.

  • VALOR_INVALIDO: Valor inválido.

  • COBRANCA_INVALIDA: Cobrança inválida.

  • CONSENTIMENTO_INVALIDO: Consentimento inválido.

  • PARAMETRO_NAO_INFORMADO: Parâmetro obrigatório não informado.

  • PARAMETRO_INVALIDO: Parâmetro com valor inválido.

  • NAO_INFORMADO: Não informado.

  • PAGAMENTO_DIVERGENTE_CONSENTIMENTO: Divergência entre pagamento e consentimento.

  • DETALHE_PAGAMENTO_INVALIDO: Detalhe do pagamento inválido.

  • PAGAMENTO_RECUSADO_DETENTORA: Pagamento recusado pela detentora de conta.

  • PAGAMENTO_RECUSADO_SPI: Pagamento recusado no Sistema de Pagamentos Instantâneos (SPI).

  • ERRO_IDEMPOTENCIA: Erro idempotência.

Título específico do erro reportado, de acordo com o código enviado:

  • SALDO_INSUFICIENTE: Saldo insuficiente.

  • VALOR_ACIMA_LIMITE: Acima do limite estabelecido.

  • VALOR_INVALIDO: Valor inválido.

  • COBRANCA_INVALIDA: Cobrança inválida.

  • CONSENTIMENTO_INVALIDO – Consentimento inválido (em status final).

  • PARAMETRO_NAO_INFORMADO: Parâmetro obrigatório não informado.

  • PARAMETRO_INVALIDO: Parâmetro com valor inválido.

  • NAO_INFORMADO: Não informado.

  • PAGAMENTO_DIVERGENTE_CONSENTIMENTO: Divergência entre pagamento e consentimento.

  • DETALHE_PAGAMENTO_INVALIDO: Detalhe do pagamento inválido.

  • PAGAMENTO_RECUSADO_DETENTORA: Pagamento recusado pela detentora de conta.

  • PAGAMENTO_RECUSADO_SPI: Pagamento recusado no Sistema de Pagamentos Instantâneos (SPI).

  • ERRO_IDEMPOTENCIA: Erro idempotência.

  • CONSENTIMENTO_PENDENTE_AUTORIZACAO: Consentimento pendente autorização de múltiplas alçadas (status “PARTIALLY_ACCEPTED”).

post/responses/422/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

post/responses/422/headers/x-fapi-interaction-id

Alterado - "pattern"

Alteração

^[a-zA-Z0-9][a-zA-Z0-9\-]{0,99}$

^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$

post/responses/422/headers/x-fapi-interaction-id

Alterado - "maxLength"

Alteração

100

36

post/responses/422/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

post/responses/422/headers/x-fapi-interaction-id

Adicionado - "minLength"

Adição

1

post/responses/422/headers/x-fapi-interaction-id

Adicionado - "format"

Adição

uuid

post/responses/422/headers/x-fapi-interaction-id

Adicionado - "example"

Adição

d78fc4e5-37ca-4da3-adf2-9b082bf92280

post/responses/500/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

post/responses/500/headers/x-fapi-interaction-id

Alterado - "pattern"

Alteração

^[a-zA-Z0-9][a-zA-Z0-9\-]{0,99}$

^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$

post/responses/500/headers/x-fapi-interaction-id

Alterado - "maxLength"

Alteração

100

36

post/responses/500/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

post/responses/500/headers/x-fapi-interaction-id

Adicionado - "minLength"

Adição

1

post/responses/500/headers/x-fapi-interaction-id

Adicionado - "format"

Adição

uuid

post/responses/500/headers/x-fapi-interaction-id

Adicionado - "example"

Adição

d78fc4e5-37ca-4da3-adf2-9b082bf92280

post/security

Alterado - "length"

Alteração

1

2

post/security

Adicionado - "1"

Adição

GET /pix/payments/{paymentId}

Response

Campo

O que foi alterado?

Tipo da Alteração

Antes

Depois

N° Proposta

Data homologação

get/parameters/Authorization

Adicionado - "minLength"

Adição

1

get/parameters/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

get/parameters/x-fapi-interaction-id

Alterado - "pattern"

Alteração

^[a-zA-Z0-9][a-zA-Z0-9\-]{0,99}$

^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$

get/parameters/x-fapi-interaction-id

Alterado - "maxLength"

Alteração

100

36

get/parameters/x-fapi-interaction-id

Adicionado - "format"

Adição

uuid

get/parameters/x-fapi-interaction-id

Adicionado - "example"

Adição

d78fc4e5-37ca-4da3-adf2-9b082bf92280

get/responses

Removido - "429"

Remoção

get/responses/200/data/localInstrument

Alterado - "description"

Alteração

Especifica a forma de iniciação do pagamento:

  • MANU - Inserção manual de dados da conta transacional

  • DICT - Inserção manual de chave Pix

  • QRDN - QR code dinâmico

  • QRES - QR code estático

  • INIC - Indica que o recebedor (creditor) contratou o Iniciador de Pagamentos especificamente para realizar iniciações de pagamento em que o beneficiário é previamente conhecido.

Especifica a forma de iniciação do pagamento:

  • MANU - Inserção manual de dados da conta transacional

  • DICT - Inserção manual de chave Pix

  • QRDN - QR code dinâmico

  • QRES - QR code estático

  • INIC - Indica que o recebedor (creditor) contratou o Iniciador de Pagamentos especificamente para realizar iniciações de pagamento em que o beneficiário é previamente conhecido.

[Restrição] Se /data/payment/schedule enviado com valor diferente de single durante a criação do consentimento, apenas os métodos MANU, DICT ou QRES são permitidos.

get/responses/200/data/rejectionReason/code

Alterado - "description"

Alteração

Define o código da razão pela qual o pagamento foi rejeitado

  • SALDO_INSUFICIENTE - A conta selecionada não possui saldo suficiente para realizar o pagamento.

  • VALOR_ACIMA_LIMITE - O valor ultrapassa o limite estabelecido [na instituição/no arranjo/outro] para permitir a realização de transações pelo cliente.

  • VALOR_INVALIDO - O valor enviado não é válido para o QR Code informado.

  • COBRANCA_INVALIDA - Validação de expiração, validação de vencimento ou Status Válido.

  • NAO_INFORMADO - Não reportado/identificado pela instituição detentora de conta.

  • PAGAMENTO_DIVERGENTE_CONSENTIMENTO - Dados do pagamento divergentes dos dados do consentimento.

  • DETALHE_PAGAMENTO_INVALIDO - Parâmetro [nome_campo] não obedecer às regras de negócio.

  • PAGAMENTO_RECUSADO_DETENTORA - [Descrição do motivo de recusa].

  • PAGAMENTO_RECUSADO_SPI - [Código de erro conforme tabela de domínios reason PACS.002].

  • FALHA_INFRAESTRUTURA - [Descrição de qual falha na infraestrutura inviabilizou o processamento].

  • FALHA_INFRAESTRUTURA_SPI - Indica uma falha no Sistema de Pagamentos Instantâneos (SPI).

  • FALHA_INFRAESTRUTURA_DICT - Indica uma falha no Diretório de Identificadores de Contas Transacionais (DICT).

  • FALHA_INFRAESTRUTURA_ICP - Indica uma falha na Infraestrutura de Chaves Públicas (ICP).

  • FALHA_INFRAESTRUTURA_PSP_RECEBEDOR - Indica uma falha na infraestrutura do Prestador de Serviço de Pagamento (PSP) que recebe o pagamento.

  • FALHA_INFRAESTRUTURA_DETENTORA - indica uma falha na infraestrutura da instituição detentora das informações ou recursos.

  • CONTAS_ORIGEM_DESTINO_IGUAIS - Indica uma tentativa de pagamento onde a conta origem e a conta de destino são iguais.

O rejectionReason FALHA_INFRAESTRUTURA não será excluído, apenas deixará de ser utilizado, permitindo assim, retrocompatibilidade e integridade entre os participantes.

Define o código da razão pela qual o pagamento foi rejeitado

  • SALDO_INSUFICIENTE - A conta selecionada não possui saldo suficiente para realizar o pagamento.

  • VALOR_ACIMA_LIMITE - O valor ultrapassa o limite estabelecido [na instituição/no arranjo/outro] para permitir a realização de transações pelo cliente.

  • VALOR_INVALIDO - O valor enviado não é válido para o QR Code informado.

  • COBRANCA_INVALIDA - Validação de expiração, validação de vencimento ou Status Válido.

  • NAO_INFORMADO - Não reportado/identificado pela instituição detentora de conta.

  • PAGAMENTO_DIVERGENTE_CONSENTIMENTO - Dados do pagamento divergentes dos dados do consentimento.

  • DETALHE_PAGAMENTO_INVALIDO - Parâmetro [nome_campo] não obedecer às regras de negócio.

  • PAGAMENTO_RECUSADO_DETENTORA - [Descrição do motivo de recusa].

  • PAGAMENTO_RECUSADO_SPI - [Código de erro conforme tabela de domínios reason PACS.002].

  • FALHA_INFRAESTRUTURA - [Descrição de qual falha na infraestrutura inviabilizou o processamento].

  • FALHA_INFRAESTRUTURA_SPI - Indica uma falha no Sistema de Pagamentos Instantâneos (SPI).

  • FALHA_INFRAESTRUTURA_DICT - Indica uma falha no Diretório de Identificadores de Contas Transacionais (DICT).

  • FALHA_INFRAESTRUTURA_ICP - Indica uma falha na Infraestrutura de Chaves Públicas (ICP).

  • FALHA_INFRAESTRUTURA_PSP_RECEBEDOR - Indica uma falha na infraestrutura do Prestador de Serviço de Pagamento (PSP) que recebe o pagamento.

  • FALHA_INFRAESTRUTURA_DETENTORA - indica uma falha na infraestrutura da instituição detentora das informações ou recursos.

  • CONTAS_ORIGEM_DESTINO_IGUAIS - Indica uma tentativa de pagamento onde a conta origem e a conta de destino são iguais.

  • FALHA_AGENDAMENTO_PAGAMENTOS - Falha ao agendar pagamentos.

O rejectionReason FALHA_INFRAESTRUTURA não será excluído, apenas deixará de ser utilizado, permitindo assim, retrocompatibilidade e integridade entre os participantes.

get/responses/200/data/rejectionReason/code/enum

Adicionado - "FALHA_AGENDAMENTO_PAGAMENTOS"

Adição

enum

get/responses/200/data/status

Alterado - "description"

Alteração

Estado atual da iniciação de pagamento. O estado evolui na seguinte ordem: 

  1. RCVD (Received) - Indica que a requisição de pagamento foi recebida com sucesso pela detentora, mas ainda há validações a serem feitas antes de ser submetida para liquidação.

  1. PATC (Partially Accepted Technical Correct) - Indica que a transação precisa da confirmação de mais autorizadores para que o processamento do pagamento possa prosseguir. 

  1. CANC (Cancelled) - Indica que a transação Pix pendente foi cancelada com sucesso pelo usuário antes que fosse confirmada (ACCP) ou rejeitada (RJCT) pela detentora.

  1. ACCP( Accepted Customer Profile) - Indica que todas as verificações necessárias já foram realizadas pela detentora e que a transação está pronta para ser enviada para liquidação (no SPI se for Pix para outra instituição ou internamente se for para outra conta na mesma instituição).

  1. ACPD (Accepted Clearing Processed) - Indica que a detentora já submeteu a transação para liquidação, mas ainda não tem a confirmação se foi liquidada ou rejeitada.

  1. RJCT (Rejected) Indica que a transação foi rejeitada pela detentora ou pelo SPI.

  1. ACSC (Accepted Settlement Completed Debitor Account) - Indica que a transação foi efetivada pela detentora ou pelo SPI.

  1. PDNG (Pending) - Indica que a detentora reteve temporariamente a transação Pix para análise.

  1. SCHD (Scheduled) - Indica que a transação Pix foi agendada com sucesso na detentora.

Em caso insucesso:
 
RJCT (REJECTED) - Instrução de pagamento rejeitada.

Estado atual da iniciação de pagamento. O estado evolui na seguinte ordem:

  1. RCVD (Received) - Indica que a requisição de pagamento foi recebida com sucesso pela detentora, mas ainda há validações a serem feitas antes de ser submetida para liquidação.

  1. CANC (Cancelled) - Indica que a transação Pix pendente foi cancelada com sucesso pelo usuário antes que fosse confirmada (ACCP) ou rejeitada (RJCT) pela detentora.

  1. ACCP( Accepted Customer Profile) - Indica que todas as verificações necessárias já foram realizadas pela detentora e que a transação está pronta para ser enviada para liquidação (no SPI se for Pix para outra instituição ou internamente se for para outra conta na mesma instituição).

  1. ACPD (Accepted Clearing Processed) - Indica que a detentora já submeteu a transação para liquidação, mas ainda não tem a confirmação se foi liquidada ou rejeitada.

  1. RJCT (Rejected) Indica que a transação foi rejeitada pela detentora ou pelo SPI.

  1. ACSC (Accepted Settlement Completed Debitor Account) - Indica que a transação foi efetivada pela detentora ou pelo SPI.

  1. PDNG (Pending) - Indica que a detentora reteve temporariamente a transação Pix para análise.

  1. SCHD (Scheduled) - Indica que a transação Pix foi agendada com sucesso na detentora.

Em caso insucesso:

RJCT (REJECTED) - Instrução de pagamento rejeitada.

get/responses/200/data/status/enum

Removido - "PATC"

Remoção

enum

get/responses/200/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

get/responses/200/headers/x-fapi-interaction-id

Alterado - "pattern"

Alteração

^[a-zA-Z0-9][a-zA-Z0-9\-]{0,99}$

^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$

get/responses/200/headers/x-fapi-interaction-id

Alterado - "maxLength"

Alteração

100

36

get/responses/200/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

get/responses/200/headers/x-fapi-interaction-id

Adicionado - "minLength"

Adição

1

get/responses/200/headers/x-fapi-interaction-id

Adicionado - "format"

Adição

uuid

get/responses/200/headers/x-fapi-interaction-id

Adicionado - "example"

Adição

d78fc4e5-37ca-4da3-adf2-9b082bf92280

get/responses/400/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

get/responses/400/headers/x-fapi-interaction-id

Alterado - "pattern"

Alteração

^[a-zA-Z0-9][a-zA-Z0-9\-]{0,99}$

^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$

get/responses/400/headers/x-fapi-interaction-id

Alterado - "maxLength"

Alteração

100

36

get/responses/400/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

get/responses/400/headers/x-fapi-interaction-id

Adicionado - "minLength"

Adição

1

get/responses/400/headers/x-fapi-interaction-id

Adicionado - "format"

Adição

uuid

get/responses/400/headers/x-fapi-interaction-id

Adicionado - "example"

Adição

d78fc4e5-37ca-4da3-adf2-9b082bf92280

get/responses/401/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

get/responses/401/headers/x-fapi-interaction-id

Alterado - "pattern"

Alteração

^[a-zA-Z0-9][a-zA-Z0-9\-]{0,99}$

^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$

get/responses/401/headers/x-fapi-interaction-id

Alterado - "maxLength"

Alteração

100

36

get/responses/401/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

get/responses/401/headers/x-fapi-interaction-id

Adicionado - "minLength"

Adição

1

get/responses/401/headers/x-fapi-interaction-id

Adicionado - "format"

Adição

uuid

get/responses/401/headers/x-fapi-interaction-id

Adicionado - "example"

Adição

d78fc4e5-37ca-4da3-adf2-9b082bf92280

get/responses/403/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

get/responses/403/headers/x-fapi-interaction-id

Alterado - "pattern"

Alteração

^[a-zA-Z0-9][a-zA-Z0-9\-]{0,99}$

^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$

get/responses/403/headers/x-fapi-interaction-id

Alterado - "maxLength"

Alteração

100

36

get/responses/403/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

get/responses/403/headers/x-fapi-interaction-id

Adicionado - "minLength"

Adição

1

get/responses/403/headers/x-fapi-interaction-id

Adicionado - "format"

Adição

uuid

get/responses/403/headers/x-fapi-interaction-id

Adicionado - "example"

Adição

d78fc4e5-37ca-4da3-adf2-9b082bf92280

get/responses/404/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

get/responses/404/headers/x-fapi-interaction-id

Alterado - "pattern"

Alteração

^[a-zA-Z0-9][a-zA-Z0-9\-]{0,99}$

^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$

get/responses/404/headers/x-fapi-interaction-id

Alterado - "maxLength"

Alteração

100

36

get/responses/404/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

get/responses/404/headers/x-fapi-interaction-id

Adicionado - "minLength"

Adição

1

get/responses/404/headers/x-fapi-interaction-id

Adicionado - "format"

Adição

uuid

get/responses/404/headers/x-fapi-interaction-id

Adicionado - "example"

Adição

d78fc4e5-37ca-4da3-adf2-9b082bf92280

get/responses/405/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

get/responses/405/headers/x-fapi-interaction-id

Alterado - "pattern"

Alteração

^[a-zA-Z0-9][a-zA-Z0-9\-]{0,99}$

^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$

get/responses/405/headers/x-fapi-interaction-id

Alterado - "maxLength"

Alteração

100

36

get/responses/405/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

get/responses/405/headers/x-fapi-interaction-id

Adicionado - "minLength"

Adição

1

get/responses/405/headers/x-fapi-interaction-id

Adicionado - "format"

Adição

uuid

get/responses/405/headers/x-fapi-interaction-id

Adicionado - "example"

Adição

d78fc4e5-37ca-4da3-adf2-9b082bf92280

get/responses/406/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

get/responses/406/headers/x-fapi-interaction-id

Alterado - "pattern"

Alteração

^[a-zA-Z0-9][a-zA-Z0-9\-]{0,99}$

^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$

get/responses/406/headers/x-fapi-interaction-id

Alterado - "maxLength"

Alteração

100

36

get/responses/406/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

get/responses/406/headers/x-fapi-interaction-id

Adicionado - "minLength"

Adição

1

get/responses/406/headers/x-fapi-interaction-id

Adicionado - "format"

Adição

uuid

get/responses/406/headers/x-fapi-interaction-id

Adicionado - "example"

Adição

d78fc4e5-37ca-4da3-adf2-9b082bf92280

get/responses/500/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

get/responses/500/headers/x-fapi-interaction-id

Alterado - "pattern"

Alteração

^[a-zA-Z0-9][a-zA-Z0-9\-]{0,99}$

^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$

get/responses/500/headers/x-fapi-interaction-id

Alterado - "maxLength"

Alteração

100

36

get/responses/500/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

get/responses/500/headers/x-fapi-interaction-id

Adicionado - "minLength"

Adição

1

get/responses/500/headers/x-fapi-interaction-id

Adicionado - "format"

Adição

uuid

get/responses/500/headers/x-fapi-interaction-id

Adicionado - "example"

Adição

d78fc4e5-37ca-4da3-adf2-9b082bf92280

PATCH pix/payments/{paymentId}

Request

Campo

O que foi alterado?

Tipo da Alteração

Antes

Depois

N° Proposta

Data homologação

Response

Campo

O que foi alterado?

Tipo da Alteração

Antes

Depois

N° Proposta

Data homologação

patch

Alterado - "description"

Alteração

Esse endpoint deve ser usado para cancelar, a pedido do cliente pagador, as transações que estejam em uma das seguintes situações: Agendada com sucesso (SCHD), retida para análise (PDNG) ou aguardando autorização de múltiplas alçadas (PATC). 

  • Caso a requisição seja bem sucedida, a transação vai para a situação CANC.

  • Caso o status do pagamento seja diferente de SCHD/PDNG/PATC ou alguma outra regra de negócio impeça o cancelamento, a requisição PATCH retorna HTTP Status 422 com o code PAGAMENTO_NAO_PERMITE_CANCELAMENTO.

  • Caso receba um 422, a iniciadora deve fazer uma requisição GET no pagamento para verificar a situação atual dele, bem como detalhes associados. 

O cancelamento de pagamento agendado (SCHD) pode ser enviado até 23:59 (Horário de Brasília) do dia anterior à data de efetivação do pagamento. 

Esse endpoint deve ser usado para cancelar, a pedido do cliente pagador, as transações que estejam em uma das seguintes situações: Agendada com sucesso (SCHD) ou retida para análise (PDNG).

  • Caso a requisição seja bem sucedida, a transação vai para a situação CANC.

  • Caso o status do pagamento seja diferente de SCHD/PDNG ou alguma outra regra de negócio impeça o cancelamento, a requisição PATCH retorna HTTP Status 422 com o code PAGAMENTO_NAO_PERMITE_CANCELAMENTO.

  • Caso receba um 422, a iniciadora deve fazer uma requisição GET no pagamento para verificar a situação atual dele, bem como detalhes associados.

O cancelamento de pagamento agendado (SCHD) pode ser enviado até 23:59 (Horário de Brasília) do dia anterior à data de efetivação do pagamento.

patch/parameters/Authorization

Adicionado - "minLength"

Adição

1

patch/parameters/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

patch/parameters/x-fapi-interaction-id

Alterado - "pattern"

Alteração

^[a-zA-Z0-9][a-zA-Z0-9\-]{0,99}$

^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$

patch/parameters/x-fapi-interaction-id

Alterado - "maxLength"

Alteração

100

36

patch/parameters/x-fapi-interaction-id

Adicionado - "format"

Adição

uuid

patch/parameters/x-fapi-interaction-id

Adicionado - "example"

Adição

d78fc4e5-37ca-4da3-adf2-9b082bf92280

patch/responses

Removido - "429"

Remoção

patch/responses/200/data/localInstrument

Alterado - "description"

Alteração

Especifica a forma de iniciação do pagamento:

  • MANU - Inserção manual de dados da conta transacional

  • DICT - Inserção manual de chave Pix

  • QRDN - QR code dinâmico

  • QRES - QR code estático

  • INIC - Indica que o recebedor (creditor) contratou o Iniciador de Pagamentos especificamente para realizar iniciações de pagamento em que o beneficiário é previamente conhecido.

Especifica a forma de iniciação do pagamento:

  • MANU - Inserção manual de dados da conta transacional

  • DICT - Inserção manual de chave Pix

  • QRDN - QR code dinâmico

  • QRES - QR code estático

  • INIC - Indica que o recebedor (creditor) contratou o Iniciador de Pagamentos especificamente para realizar iniciações de pagamento em que o beneficiário é previamente conhecido.

[Restrição] Se /data/payment/schedule enviado com valor diferente de single durante a criação do consentimento, apenas os métodos MANU, DICT ou QRES são permitidos.

patch/responses/200/data/status

Alterado - "description"

Alteração

Estado atual da iniciação de pagamento. O estado evolui na seguinte ordem: 

  1. RCVD (Received) - Indica que a requisição de pagamento foi recebida com sucesso pela detentora, mas ainda há validações a serem feitas antes de ser submetida para liquidação.

  1. PATC (Partially Accepted Technical Correct) - Indica que a transação precisa da confirmação de mais autorizadores para que o processamento do pagamento possa prosseguir. 

  1. CANC (Cancelled) - Indica que a transação Pix pendente foi cancelada com sucesso pelo usuário antes que fosse confirmada (ACCP) ou rejeitada (RJCT) pela detentora.

  1. ACCP( Accepted Customer Profile) - Indica que todas as verificações necessárias já foram realizadas pela detentora e que a transação está pronta para ser enviada para liquidação (no SPI se for Pix para outra instituição ou internamente se for para outra conta na mesma instituição).

  1. ACPD (Accepted Clearing Processed) - Indica que a detentora já submeteu a transação para liquidação, mas ainda não tem a confirmação se foi liquidada ou rejeitada.

  1. RJCT (Rejected) Indica que a transação foi rejeitada pela detentora ou pelo SPI.

  1. ACSC (Accepted Settlement Completed Debitor Account) - Indica que a transação foi efetivada pela detentora ou pelo SPI.

  1. PDNG (Pending) - Indica que a detentora reteve temporariamente a transação Pix para análise.

  1. SCHD (Scheduled) - Indica que a transação Pix foi agendada com sucesso na detentora.

Em caso insucesso:
 
RJCT (REJECTED) - Instrução de pagamento rejeitada.

Estado atual da iniciação de pagamento. O estado evolui na seguinte ordem:

  1. RCVD (Received) - Indica que a requisição de pagamento foi recebida com sucesso pela detentora, mas ainda há validações a serem feitas antes de ser submetida para liquidação.

  1. CANC (Cancelled) - Indica que a transação Pix pendente foi cancelada com sucesso pelo usuário antes que fosse confirmada (ACCP) ou rejeitada (RJCT) pela detentora.

  1. ACCP( Accepted Customer Profile) - Indica que todas as verificações necessárias já foram realizadas pela detentora e que a transação está pronta para ser enviada para liquidação (no SPI se for Pix para outra instituição ou internamente se for para outra conta na mesma instituição).

  1. ACPD (Accepted Clearing Processed) - Indica que a detentora já submeteu a transação para liquidação, mas ainda não tem a confirmação se foi liquidada ou rejeitada.

  1. RJCT (Rejected) Indica que a transação foi rejeitada pela detentora ou pelo SPI.

  1. ACSC (Accepted Settlement Completed Debitor Account) - Indica que a transação foi efetivada pela detentora ou pelo SPI.

  1. PDNG (Pending) - Indica que a detentora reteve temporariamente a transação Pix para análise.

  1. SCHD (Scheduled) - Indica que a transação Pix foi agendada com sucesso na detentora.

Em caso insucesso:

RJCT (REJECTED) - Instrução de pagamento rejeitada.

patch/responses/200/data/status/enum

Removido - "PATC"

Remoção

enum

patch/responses/200/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

patch/responses/200/headers/x-fapi-interaction-id

Alterado - "pattern"

Alteração

^[a-zA-Z0-9][a-zA-Z0-9\-]{0,99}$

^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$

patch/responses/200/headers/x-fapi-interaction-id

Alterado - "maxLength"

Alteração

100

36

patch/responses/200/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

patch/responses/200/headers/x-fapi-interaction-id

Adicionado - "minLength"

Adição

1

patch/responses/200/headers/x-fapi-interaction-id

Adicionado - "format"

Adição

uuid

patch/responses/200/headers/x-fapi-interaction-id

Adicionado - "example"

Adição

d78fc4e5-37ca-4da3-adf2-9b082bf92280

patch/responses/400/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

patch/responses/400/headers/x-fapi-interaction-id

Alterado - "pattern"

Alteração

^[a-zA-Z0-9][a-zA-Z0-9\-]{0,99}$

^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$

patch/responses/400/headers/x-fapi-interaction-id

Alterado - "maxLength"

Alteração

100

36

patch/responses/400/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

patch/responses/400/headers/x-fapi-interaction-id

Adicionado - "minLength"

Adição

1

patch/responses/400/headers/x-fapi-interaction-id

Adicionado - "format"

Adição

uuid

patch/responses/400/headers/x-fapi-interaction-id

Adicionado - "example"

Adição

d78fc4e5-37ca-4da3-adf2-9b082bf92280

patch/responses/401/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

patch/responses/401/headers/x-fapi-interaction-id

Alterado - "pattern"

Alteração

^[a-zA-Z0-9][a-zA-Z0-9\-]{0,99}$

^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$

patch/responses/401/headers/x-fapi-interaction-id

Alterado - "maxLength"

Alteração

100

36

patch/responses/401/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

patch/responses/401/headers/x-fapi-interaction-id

Adicionado - "minLength"

Adição

1

patch/responses/401/headers/x-fapi-interaction-id

Adicionado - "format"

Adição

uuid

patch/responses/401/headers/x-fapi-interaction-id

Adicionado - "example"

Adição

d78fc4e5-37ca-4da3-adf2-9b082bf92280

patch/responses/403/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

patch/responses/403/headers/x-fapi-interaction-id

Alterado - "pattern"

Alteração

^[a-zA-Z0-9][a-zA-Z0-9\-]{0,99}$

^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$

patch/responses/403/headers/x-fapi-interaction-id

Alterado - "maxLength"

Alteração

100

36

patch/responses/403/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

patch/responses/403/headers/x-fapi-interaction-id

Adicionado - "minLength"

Adição

1

patch/responses/403/headers/x-fapi-interaction-id

Adicionado - "format"

Adição

uuid

patch/responses/403/headers/x-fapi-interaction-id

Adicionado - "example"

Adição

d78fc4e5-37ca-4da3-adf2-9b082bf92280

patch/responses/404/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

patch/responses/404/headers/x-fapi-interaction-id

Alterado - "pattern"

Alteração

^[a-zA-Z0-9][a-zA-Z0-9\-]{0,99}$

^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$

patch/responses/404/headers/x-fapi-interaction-id

Alterado - "maxLength"

Alteração

100

36

patch/responses/404/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

patch/responses/404/headers/x-fapi-interaction-id

Adicionado - "minLength"

Adição

1

patch/responses/404/headers/x-fapi-interaction-id

Adicionado - "format"

Adição

uuid

patch/responses/404/headers/x-fapi-interaction-id

Adicionado - "example"

Adição

d78fc4e5-37ca-4da3-adf2-9b082bf92280

patch/responses/405/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

patch/responses/405/headers/x-fapi-interaction-id

Alterado - "pattern"

Alteração

^[a-zA-Z0-9][a-zA-Z0-9\-]{0,99}$

^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$

patch/responses/405/headers/x-fapi-interaction-id

Alterado - "maxLength"

Alteração

100

36

patch/responses/405/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

patch/responses/405/headers/x-fapi-interaction-id

Adicionado - "minLength"

Adição

1

patch/responses/405/headers/x-fapi-interaction-id

Adicionado - "format"

Adição

uuid

patch/responses/405/headers/x-fapi-interaction-id

Adicionado - "example"

Adição

d78fc4e5-37ca-4da3-adf2-9b082bf92280

patch/responses/406/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

patch/responses/406/headers/x-fapi-interaction-id

Alterado - "pattern"

Alteração

^[a-zA-Z0-9][a-zA-Z0-9\-]{0,99}$

^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$

patch/responses/406/headers/x-fapi-interaction-id

Alterado - "maxLength"

Alteração

100

36

patch/responses/406/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

patch/responses/406/headers/x-fapi-interaction-id

Adicionado - "minLength"

Adição

1

patch/responses/406/headers/x-fapi-interaction-id

Adicionado - "format"

Adição

uuid

patch/responses/406/headers/x-fapi-interaction-id

Adicionado - "example"

Adição

d78fc4e5-37ca-4da3-adf2-9b082bf92280

patch/responses/422/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

patch/responses/422/headers/x-fapi-interaction-id

Alterado - "pattern"

Alteração

^[a-zA-Z0-9][a-zA-Z0-9\-]{0,99}$

^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$

patch/responses/422/headers/x-fapi-interaction-id

Alterado - "maxLength"

Alteração

100

36

patch/responses/422/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

patch/responses/422/headers/x-fapi-interaction-id

Adicionado - "minLength"

Adição

1

patch/responses/422/headers/x-fapi-interaction-id

Adicionado - "format"

Adição

uuid

patch/responses/422/headers/x-fapi-interaction-id

Adicionado - "example"

Adição

d78fc4e5-37ca-4da3-adf2-9b082bf92280

patch/responses/500/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

patch/responses/500/headers/x-fapi-interaction-id

Alterado - "pattern"

Alteração

^[a-zA-Z0-9][a-zA-Z0-9\-]{0,99}$

^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$

patch/responses/500/headers/x-fapi-interaction-id

Alterado - "maxLength"

Alteração

100

36

patch/responses/500/headers/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.

Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) usado como um ID de correlação entre request e response. Campo de geração e envio obrigatório pela iniciadora (client) e o seu valor deve ser “espelhado” pela detentora (server) no cabeçalho de resposta. Caso não seja recebido ou se for recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

patch/responses/500/headers/x-fapi-interaction-id

Adicionado - "minLength"

Adição

1

patch/responses/500/headers/x-fapi-interaction-id

Adicionado - "format"

Adição

uuid

patch/responses/500/headers/x-fapi-interaction-id

Adicionado - "example"

Adição

d78fc4e5-37ca-4da3-adf2-9b082bf92280

PATCH pix/payments/consents/{consentId}

Request

Campo

O que foi alterado?

Tipo da Alteração

Antes

Depois

N° Proposta

Data homologação

Response

Campo

O que foi alterado?

Tipo da Alteração

Antes

Depois

N° Proposta

Data homologação