Comparação de Páginas

...

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)

Como assinar o payload JWS: [https://openfinancebrasil.atlassian.net/wiki/spaces/OF/pages/18055279/Como+Assinar+o+Payload+-+v2.0.0-rc1.0+-+Pagamentos](https://openfinancebrasil.atlassian.net/wiki/spaces/OF/pages/18055279/Como+Assinar+o+Payload+-+v2.0.0-rc1.0+-+Pagamentos)

## 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. Entretanto, a escolha do momento desta validação na criação do consentimento ou no pagamento, fica a cargo da detentora.

## 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:

Na criação do consentimento (*POST /consents*);
Na criação do pagamento - Síncrono (*POST /payments*);
Validações na consulta do pagamento (*GET /pix/payments/{paymentId}*);
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;
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**

**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).

**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**

**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).

**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 (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**.

**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 (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)

Como assinar o payload JWS: [Como Assinar o Payload](https://openfinancebrasil.atlassian.net/wiki/spaces/OF/pages/180061175/Como+Assinar+o+Payload+-+v3.0.0+-+Pagamentos)

## 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:

Na criação do consentimento (*POST /consents*);
Na criação do pagamento - Síncrono (*POST /payments*);
Validações na consulta do pagamento (*GET /pix/payments/{paymentId}*);
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;
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**

**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).

**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**

**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).

**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**.

**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/responses

Removido - "429"

Remoção

post/responses/201/data

Campo	O que foi alterado?	Tipo da Alteração	Antes	Depois
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

post/x-fapi-interaction-id

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.

Um UUID 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.

Um UUID 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 enviado pela iniciadora, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. Caso 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 ou 422 (com o código PARAMETRO_INVALIDO). A iniciadora deve acatar o valor gerado pelo detentor e recebido na resposta.

PSV202

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/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)

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/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"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/scheduledetails/oneOflocalInstrument	Alterado - "lengthdescription"	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	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/oneOf	Adicionado - "4description"	Adiçãopost		[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}

Response

post/x-fapi-interaction-id

Alterado - "description"

Alteração

Um UUID 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/

Um UUID 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 enviado pela iniciadora, a detentora deve gerar um 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

e retorná-lo na resposta com o HTTP status code 400. Caso 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 ou 422 (com o código PARAMETRO_INVALIDO). A iniciadora deve acatar o valor gerado pelo detentor e recebido na resposta.

PSV202

GET /consents/{consentId}

Response

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/

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	Adicionado Alterado - "exampledescription"	Adição	d78fc4e5-37ca-4da3-adf2-9b082bf92280	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 permitidosAlteraçã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	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/payment/scheduleexpirationDateTime	Adicionado Alterado - "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	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/scheduledetails/oneOflocalInstrument	Adicionado Alterado - "3description"	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	[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 deve ser informadodeverá 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/0/single/date	Alterado - "examplelength"	Alteração	01/01/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

x-fapi-interaction-id

Alterado - "description"

Alteração

Um UUID 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

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

e retorná-lo na resposta com o HTTP status code 400. A iniciadora deve acatar o valor recebido da detentora.

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

enviado pela iniciadora, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. Caso 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 ou 422 (com o código PARAMETRO_INVALIDO). 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

gerado pelo detentor e recebido na resposta.

PSV202

POST /pix/payments

Request

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

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	Adicionado Alterado - "exampledescription"	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

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/

responses/201

requestBody/data

Removido - "description"

Remoção

Objeto contendo dados do pagamento e

da conta

do recebedor (creditor).
post/

responses/201

requestBody/data	Removido - "required"	Remoção
post/

responses/201

requestBody/data	Removido - "properties"	Remoção
post/

responses

requestBody/

201/

data	Adicionado - "

items

minItems"	Adição		1
post/

responses/201/links/selfAlterado

requestBody/data

Adicionado - "

descriptionpost/responses/201/headers/

items"

Alteração

URI completo que gerou a resposta atual.

URI completo para o primeiro item presente na resposta.

Adição
x-fapi-interaction-id	Alterado - "description"	Alteração	Um

UID [RFC4122](https://tools.ietf.org/html/rfc4122)

UUID RFC4122 usado como um ID de correlação

. A detentora deve obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora

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.

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

enviado pela iniciadora, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. Caso 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 ou 422 (com o código PARAMETRO_INVALIDO). A iniciadora deve acatar o valor

recebido da detentora.post/responses/201/headers/

gerado pelo detentor e recebido na resposta.	PSV202
x-fapi-interaction-id	Alterado - "

pattern

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

description"

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 - "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

Um UUID 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

Um UUID 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

enviado pela iniciadora, 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/

Caso recebido um valor inválido, a detentora deve gerar um 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

e retorná-lo na resposta com o HTTP status code 400 ou 422 (com o código PARAMETRO_INVALIDO). A iniciadora deve acatar o valor gerado pelo detentor e recebido na resposta.

PSV202

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/

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/400201/headers/x-fapi-interaction-id	Adicionado Alterado - "minLengthpattern"	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-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/401201/headers/x-fapi-interaction-id	Alterado Adicionado - "patternminLength"	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}$Adição		1
post/responses/401201/headers/x-fapi-interaction-id	Alterado Adicionado - "maxLengthformat"	AlteraçãoAdição	100		36uuid
post/responses/401201/headers/x-fapi-interaction-id	Alterado Adicionado - "descriptionexample"	Alteração	Um UID [RFC4122Adiçã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/401400/headers/x-fapi-interaction-id	Adicionado Alterado - "minLengthpattern"	Adição	1	post/responses/401/headers/x-fapi-interaction-id	Adicionado - "format"	Adição	uuid	post/responses/401Alteraçã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	Adicionado Alterado - "examplemaxLength"	Alteração	Adição	d78fc4e5-37ca-4da3-adf2-9b082bf92280100	36
post/responses/403400/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/403400/headers/x-fapi-interaction-id	Alterado Adicionado - "patternminLength"	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}$Adição		1
post/responses/400/headers/x-fapi-interaction-id	Adicionado - "format"	Adição		uuid
post/responses/403400/headers/x-fapi-interaction-id	Alterado Adicionado - "maxLengthexample"	Alteração	100	36Adição		d78fc4e5-37ca-4da3-adf2-9b082bf92280
post/responses/403401/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/403401/headers/x-fapi-interaction-id	Adicionado Alterado - "minLengthpattern"	Adição	1	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/403401/headers/x-fapi-interaction-id	Adicionado Alterado - "formatmaxLength"	AdiçãoAlteração	100	uuid36
post/responses/403/headers/x-fapi-interaction-id	Adicionado - "example"	Adição	d78fc4e5-37ca-4da3-adf2-9b082bf92280	post/responses/404401/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/404401/headers/x-fapi-interaction-id	Alterado Adicionado - "patternminLength"	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}$Adição		1
post/responses/401/headers/x-fapi-interaction-id	Adicionado - "format"	Adição		uuid
post/responses/404401/headers/x-fapi-interaction-id	Alterado Adicionado - "maxLengthexample"	Alteração	100	36	Adição		d78fc4e5-37ca-4da3-adf2-9b082bf92280
post/responses/404403/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/404403/headers/x-fapi-interaction-id	Adicionado Alterado - "minLengthpattern"	Adição	1	post/responses/404/headers/x-fapi-interaction-id	Adicionado - "format"	Adição	uuidAlteraçã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/404403/headers/x-fapi-interaction-id	Adicionado Alterado - "examplemaxLength"	Adição	d78fc4e5-37ca-4da3-adf2-9b082bf92280Alteração	100	36
post/responses/405403/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/405403/headers/x-fapi-interaction-id	Alterado Adicionado - "patternminLength"	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}$Adição		1
post/responses/405403/headers/x-fapi-interaction-id	Alterado Adicionado - "maxLengthformat"	AlteraçãoAdição		100uuid	36
post/responses/405403/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/405404/headers/x-fapi-interaction-id	Adicionado Alterado - "minLengthpattern"	Adição	1	post/responses/405/headers/x-fapi-interaction-id	Adicionado - "format"	Adição	uuid	post/responses/405Alteraçã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	Adicionado Alterado - "examplemaxLength"	Alteração	Adição	d78fc4e5-37ca-4da3-adf2-9b082bf92280100	36
post/responses/406404/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/406404/headers/x-fapi-interaction-id	Alterado Adicionado - "patternminLength"	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}$Adição		1
post/responses/404/headers/x-fapi-interaction-id	Adicionado - "format"	Adição		uuid
post/responses/406404/headers/x-fapi-interaction-id	Alterado Adicionado - "maxLengthexample"	Alteração	100	36	Adição		d78fc4e5-37ca-4da3-adf2-9b082bf92280
post/responses/406405/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/406405/headers/x-fapi-interaction-id	Adicionado Alterado - "minLengthpattern"	Adição	1	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/406405/headers/x-fapi-interaction-id	Adicionado Alterado - "formatmaxLength"	AdiçãoAlteração	uuid	post/responses/406/headers/x-fapi-interaction-id	Adicionado - "example"	Adição	d78fc4e5-37ca-4da3-adf2-9b082bf92280100	36
post/responses/415405/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/415405/headers/x-fapi-interaction-id	Alterado Adicionado - "patternminLength"	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}$Adição		1
post/responses/405/headers/x-fapi-interaction-id	Adicionado - "format"	Adição		uuid
post/responses/415405/headers/x-fapi-interaction-id	Alterado Adicionado - "maxLengthexample"	Alteração	100	36	Adição		d78fc4e5-37ca-4da3-adf2-9b082bf92280
post/responses/415406/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/415406/headers/x-fapi-interaction-id	Adicionado Alterado - "minLengthpattern"	Adição	1	post/responses/415/headers/x-fapi-interaction-id	Adicionado - "format"	Adição	uuidAlteraçã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/415406/headers/x-fapi-interaction-id	Adicionado Alterado - "examplemaxLength"	Adição	d78fc4e5-37ca-4da3-adf2-9b082bf92280Alteração	100	36
post/responses/422406/errors/items/codeheaders/x-fapi-interaction-id	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 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 ou , Status Válido. CONSENTIMENTO_INVALIDO – : Consentimento inválido (em status finalstatus não é "authorised" ou está expirado). PARAMETRO_NAO_INFORMADO: endToEndIdParâmetro não informado. PARAMETRO_INVALIDO: endToEndIdParâmetro inválido. NAO_INFORMADO: Não reportado/identificado informada 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ócioDetalhe do pagamento inválido. PAGAMENTO_RECUSADO_DETENTORA: [descrição do motivo de recusa]Pagamento recusado pela detentora de conta. PAGAMENTO_RECUSADO_SPI: [código de erro conforme tabela de domínios reason PACS.002].Pagamento recusado no Sistema de Pagamentos Instantâneos (SPI). Título específico do erro reportado, de acordo com o código enviado 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	Erro idempotência.	Códigos de erros previstos na criação da iniciação de pagamento: SALDO_INSUFICIENTE: Saldo insuficienteEsta conta não possui saldo suficiente para realizar o pagamento. VALOR_ACIMA_LIMITE: Acima do limite estabelecidoO 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: Valor inválidoO valor enviado não é válido para o QR Code informado. COBRANCA_INVALIDA: Cobrança inválidaValidação de expiração, validação de vencimento, Status Válido. 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 informadoinformada pela detentora de conta. PAGAMENTO_DIVERGENTE_CONSENTIMENTO: Divergência entre pagamento e 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. Título específico do erro reportado, 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 enviadoreportado: SALDO_INSUFICIENTE: Saldo insuficienteA conta selecionada não possui saldo suficiente para realizar o pagamento. VALOR_ACIMA_LIMITE: Acima do limite estabelecidoO 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: Valor inválidoO valor enviado não é válido para o QR Code informado. COBRANCA_INVALIDA: Cobrança inválidaValidação de expiração, validação de vencimento ou Status Válido. CONSENTIMENTO_INVALIDO – : Consentimento inválido (em status finalstatus diferente de "AUTHORISED" ou está expirado). PARAMETRO_NAO_INFORMADO: Parâmetro obrigatório não informado.endToEndId PARAMETRO_INVALIDO: Parâmetro com valor inválido.endToEndId NAO_INFORMADO: Não informadoreportado/identificado pela instituição detentora de conta. PAGAMENTO_DIVERGENTE_CONSENTIMENTO: Divergência entre pagamento e Dados do pagamento divergentes dos dados do consentimento. DETALHE_PAGAMENTO_INVALIDO: Detalhe do pagamento inválidoParâmetro [nome_campo] não obedece às regras de negócio. PAGAMENTO_RECUSADO_DETENTORA: Pagamento recusado pela detentora de conta[descrição do motivo de recusa]. PAGAMENTO_RECUSADO_SPI: Pagamento recusado no Sistema de Pagamentos Instantâneos (SPI)[código de erro conforme tabela de domínios reason PACS.002].	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 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}$	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	Adicionado Alterado - "exampledescription"	Adição	d78fc4e5-37ca-4da3-adf2-9b082bf92280	post/responses/500/headers/x-fapi-interaction-id	Alterado - "description"	Alteração	Um UID [RFC4122](https://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/500422/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/500422/headers/x-fapi-interaction-id	Alterado - "maxLength"	Alteração	100	36
post/responses/500422/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/500422/headers/x-fapi-interaction-id	Adicionado - "minLength"	Adição		1
post/responses/500422/headers/x-fapi-interaction-id	Adicionado - "format"	Adição		uuid
post/responses/500422/headers/x-fapi-interaction-id	Adicionado - "example"	Adição		d78fc4e5-37ca-4da3-adf2-9b082bf92280
post/responses	Removido - "429"	Remoção	post/responses/201/data	Alterado - "type"	Alteração	object	array

GET /pix/payments/{paymentId}

Response

/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/parameters


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}$

get/parameters


post/responses/500/headers/x-fapi-interaction-id	Alterado - "maxLength"	Alteração	100	36

get


post/

parameters/x-fapi-interaction-id

Adicionado - "format"

Adição

uuid

get/parameters

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

Adicionado

Alterado - "

example

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

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.

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.

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).

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.

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

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

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

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

description"

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:

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.

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.

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.

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).

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.

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

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

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

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

Em caso insucesso:

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

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/responses	Removido - "429"	Remoção
post/responses/201/data	Alterado - "type"	Alteração	object	array
x-fapi-interaction-id	Alterado - "description"	Alteração	Um UUID 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.	Um UUID 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 enviado pela iniciadora, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. Caso 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 ou 422 (com o código PARAMETRO_INVALIDO). A iniciadora deve acatar o valor gerado pelo detentor e recebido na resposta.	PSV202

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: 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. 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. 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. 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). 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. RJCT (Rejected) Indica que a transação foi rejeitada pela detentora ou pelo SPI. ACSC (Accepted Settlement Completed Debitor Account) - Indica que a transação foi efetivada pela detentora ou pelo SPI. PDNG (Pending) - Indica que a detentora reteve temporariamente a transação Pix para análise. 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: 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. 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. 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). 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. RJCT (Rejected) Indica que a transação foi rejeitada pela detentora ou pelo SPI. ACSC (Accepted Settlement Completed Debitor Account) - Indica que a transação foi efetivada pela detentora ou pelo SPI. PDNG (Pending) - Indica que a detentora reteve temporariamente a transação Pix para análise. 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/200401/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/200401/headers/x-fapi-interaction-id	Alterado - "maxLength"	Alteração	100	36
get/responses/200401/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/200401/headers/x-fapi-interaction-id	Adicionado - "minLength"	Adição		1
get/responses/200401/headers/x-fapi-interaction-id	Adicionado - "format"	Adição		uuid
get/responses/200401/headers/x-fapi-interaction-id	Adicionado - "example"	Adição		d78fc4e5-37ca-4da3-adf2-9b082bf92280
get/responses/400403/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/400403/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/400403/headers/x-fapi-interaction-id	Alterado - "maxLength"	Alteração	100	36
get/responses/400403/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/400403/headers/x-fapi-interaction-id	Adicionado - "minLength"	Adição		1
get/responses/400403/headers/x-fapi-interaction-id	Adicionado - "format"	Adição		uuid
get/responses/400403/headers/x-fapi-interaction-id	Adicionado - "example"	Adição		d78fc4e5-37ca-4da3-adf2-9b082bf92280
get/responses/401404/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/401404/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/401404/headers/x-fapi-interaction-id	Alterado - "maxLength"	Alteração	100	36
get/responses/401404/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/401404/headers/x-fapi-interaction-id	Adicionado - "minLength"	Adição		1
get/responses/401404/headers/x-fapi-interaction-id	Adicionado - "format"	Adição		uuid
get/responses/401404/headers/x-fapi-interaction-id	Adicionado - "example"	Adição		d78fc4e5-37ca-4da3-adf2-9b082bf92280
get/responses/403405/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/403405/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/403405/headers/x-fapi-interaction-id	Alterado - "maxLength"	Alteração	100	36
get/responses/403405/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/403405/headers/x-fapi-interaction-id	Adicionado - "minLength"	Adição		1
get/responses/403405/headers/x-fapi-interaction-id	Adicionado - "format"	Adição		uuid
get/responses/403405/headers/x-fapi-interaction-id	Adicionado - "example"	Adição		d78fc4e5-37ca-4da3-adf2-9b082bf92280
get/responses/404406/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/404406/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/404406/headers/x-fapi-interaction-id	Alterado - "maxLength"	Alteração	100	36
get/responses/404406/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/404406/headers/x-fapi-interaction-id	Adicionado - "minLength"	Adição		1
get/responses/404406/headers/x-fapi-interaction-id	Adicionado - "format"	Adição		uuid
get/responses/404406/headers/x-fapi-interaction-id	Adicionado - "example"	Adição		d78fc4e5-37ca-4da3-adf2-9b082bf92280
get/responses/405500/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/405500/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/405500/headers/x-fapi-interaction-id	Alterado - "maxLength"	Alteração	100	36
get/responses/405500/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/405500/headers/x-fapi-interaction-id	Adicionado - "minLength"	Adição		1
get/responses/405500/headers/x-fapi-interaction-id	Adicionado - "format"	Adição		uuid
get/responses/405500/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)	Um UUID 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/	Um UUID 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 enviado pela iniciadora, a detentora deve gerar um 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/e retorná-lo na resposta com o HTTP status code 400. Caso 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 ou 422 (com o código PARAMETRO_INVALIDO). A iniciadora deve acatar o valor gerado pelo detentor e recebido na resposta.	PSV202

PATCH pix/payments/{paymentId}

Request

Campo	O que foi alterado?	Tipo da Alteração	Antes	Depois	N° Proposta	Data homologação
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/

Um UUID 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 enviado pela iniciadora, a detentora deve gerar um x-fapi-interaction-id

Adicionado - "minLength"

Adição

1

get/responses/406/headers/

e retorná-lo na resposta com o HTTP status code 400. Caso recebido um valor inválido, a detentora deve gerar um 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

e retorná-lo na resposta com o HTTP status code 400 ou 422 (com o código PARAMETRO_INVALIDO). A iniciadora deve acatar o valor gerado pelo detentor e recebido na resposta.	PSV202

Response

Campo	O que foi alterado?	Tipo da Alteração	Antes	Depois	N° Proposta	Data homologação
patch	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/

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.

get


patch/

responses/500/headers

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

Adicionado

Alterado - "

minLength

maxLength"

Alteração

Adição

100

1

36

get


patch/

responses

parameters/

500/headers/

x-fapi-interaction-id

Adicionado - "format"

Adição

uuid

get/responses/500/headers


patch/parameters/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
patchpatch/responses	Removido - "429"	Remoção
patch/responses/200/data/localInstrument	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-idEspecifica 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	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: 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. 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. 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. 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). 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. RJCT (Rejected) Indica que a transação foi rejeitada pela detentora ou pelo SPI. ACSC (Accepted Settlement Completed Debitor Account) - Indica que a transação foi efetivada pela detentora ou pelo SPI. PDNG (Pending) - Indica que a detentora reteve temporariamente a transação Pix para análise. 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: 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. 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. 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). 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. RJCT (Rejected) Indica que a transação foi rejeitada pela detentora ou pelo SPI. ACSC (Accepted Settlement Completed Debitor Account) - Indica que a transação foi efetivada pela detentora ou pelo SPI. PDNG (Pending) - Indica que a detentora reteve temporariamente a transação Pix para análise. 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	Estado atual da iniciação de pagamento. O estado evolui na seguinte ordem: 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. 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. 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. 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). 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. RJCT (Rejected) Indica que a transação foi rejeitada pela detentora ou pelo SPI. ACSC (Accepted Settlement Completed Debitor Account) - Indica que a transação foi efetivada pela detentora ou pelo SPI. PDNG (Pending) - Indica que a detentora reteve temporariamente a transação Pix para análise. 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: 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. 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. 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). 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. RJCT (Rejected) Indica que a transação foi rejeitada pela detentora ou pelo SPI. ACSC (Accepted Settlement Completed Debitor Account) - Indica que a transação foi efetivada pela detentora ou pelo SPI. PDNG (Pending) - Indica que a detentora reteve temporariamente a transação Pix para análise. 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/200400/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/200400/headers/x-fapi-interaction-id	Alterado - "maxLength"	Alteração	100	36
patch/responses/200400/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/200400/headers/x-fapi-interaction-id	Adicionado - "minLength"	Adição		1
patch/responses/200400/headers/x-fapi-interaction-id	Adicionado - "format"	Adição		uuid
patch/responses/200400/headers/x-fapi-interaction-id	Adicionado - "example"	Adição		d78fc4e5-37ca-4da3-adf2-9b082bf92280
patch/responses/400401/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/400401/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/400401/headers/x-fapi-interaction-id	Alterado - "maxLength"	Alteração	100	36
patch/responses/400401/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/400401/headers/x-fapi-interaction-id	Adicionado - "minLength"	Adição		1
patch/responses/400401/headers/x-fapi-interaction-id	Adicionado - "format"	Adição		uuid
patch/responses/400401/headers/x-fapi-interaction-id	Adicionado - "example"	Adição		d78fc4e5-37ca-4da3-adf2-9b082bf92280
patch/responses/401403/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/401403/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/401403/headers/x-fapi-interaction-id	Alterado - "maxLength"	Alteração	100	36
patch/responses/401403/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/401403/headers/x-fapi-interaction-id	Adicionado - "minLength"	Adição		1
patch/responses/401403/headers/x-fapi-interaction-id	Adicionado - "format"	Adição		uuid
patch/responses/401403/headers/x-fapi-interaction-id	Adicionado - "example"	Adição		d78fc4e5-37ca-4da3-adf2-9b082bf92280
patch/responses/403404/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/403404/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/403404/headers/x-fapi-interaction-id	Alterado - "maxLength"	Alteração	100	36
patch/responses/403404/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/403404/headers/x-fapi-interaction-id	Adicionado - "minLength"	Adição		1
patch/responses/403404/headers/x-fapi-interaction-id	Adicionado - "format"	Adição		uuid
patch/responses/403404/headers/x-fapi-interaction-id	Adicionado - "example"	Adição		d78fc4e5-37ca-4da3-adf2-9b082bf92280
patch/responses/404405/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/404405/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/404405/headers/x-fapi-interaction-id	Alterado - "maxLength"	Alteração	100	36
patch/responses/404405/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/404405/headers/x-fapi-interaction-id	Adicionado - "minLength"	Adição		1
patch/responses/404405/headers/x-fapi-interaction-id	Adicionado - "format"	Adição		uuid
patch/responses/404405/headers/x-fapi-interaction-id	Adicionado - "example"	Adição		d78fc4e5-37ca-4da3-adf2-9b082bf92280
patch/responses/405406/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/405406/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/405406/headers/x-fapi-interaction-id	Alterado - "maxLength"	Alteração	100	36
patch/responses/405406/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/405406/headers/x-fapi-interaction-id	Adicionado - "minLength"	Adição		1
patch/responses/405406/headers/x-fapi-interaction-id	Adicionado - "format"	Adição		uuid
patch/responses/405406/headers/x-fapi-interaction-id	Adicionado - "example"	Adição		d78fc4e5-37ca-4da3-adf2-9b082bf92280
patch/responses/422	Alterado - "description"	Alteração	A requisição foi malformada, omitindo atributos obrigatórios, seja no payload ou através de atributos na URL.	Seguir as orientações presentes na descrição deste endpoint.
patch/responses/406422/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/406422/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/406422/headers/x-fapi-interaction-id	Alterado - "maxLength"	Alteração	100	36
patch/responses/406422/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/406422/headers/x-fapi-interaction-id	Adicionado - "minLength"	Adição		1
patch/responses/406422/headers/x-fapi-interaction-id	Adicionado - "format"	Adição		uuid
patch/responses/406422/headers/x-fapi-interaction-id	Adicionado - "example"	Adição	d78fc4e5-37ca-4da3-adf2-9b082bf92280	patch/responses/422	Alterado - "description"	Alteração	A requisição foi malformada, omitindo atributos obrigatórios, seja no payload ou através de atributos na URL.	Seguir as orientações presentes na descrição deste endpoint.	Adicionado - "example"	Adição		d78fc4e5-37ca-4da3-adf2-9b082bf92280
patch/responses/422500/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/422500/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/422500/headers/x-fapi-interaction-id	Alterado - "maxLength"	Alteração	100	36
patch/responses/422500/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 obrigatoriamente retornar o campo com o mesmo valor recebido da iniciadora.Um UUID [RFC4122](https://tools.ietf.org/html/rfc4122) 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
x-fapi-interaction-id	Alterado - "description"	Alteração	Um UUID 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/	Um UUID 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 enviado pela iniciadora, a detentora deve gerar um x-fapi-interaction-id	Adicionado - "minLength"	Adição	1	patch/responses/422/headers/e retorná-lo na resposta com o HTTP status code 400. Caso recebido um valor inválido, a detentora deve gerar um 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/e retorná-lo na resposta com o HTTP status code 400 ou 422 (com o código PARAMETRO_INVALIDO). A iniciadora deve acatar o valor gerado pelo detentor e recebido na resposta.	PSV202

PATCH pix/payments/consents/{consentId}

Request

Campo	O que foi alterado?	Tipo da Alteração	Antes	Depois	N° Proposta	Data homologação
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) patch/responses/500/headers/

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}$

Um UUID 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 enviado pela iniciadora, a detentora deve gerar um x-fapi-interaction-id e retorná-lo na resposta com o HTTP status code 400. Caso recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id

Alterado - "maxLength"

Alteração

100

36

patch/responses/500/headers/

e retorná-lo na resposta com o HTTP status code 400 ou 422 (com o código PARAMETRO_INVALIDO). A iniciadora deve acatar o valor gerado pelo detentor e recebido na resposta.	PSV202

Response

Campo	O que foi alterado?	Tipo da Alteração	Antes	Depois	N° Proposta	Data homologação
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)

Um UUID 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/

Um UUID 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 enviado pela iniciadora, a detentora deve gerar um x-fapi-interaction-id

Adicionado - "minLength"

Adição

1

patch/responses/500/headers/

e retorná-lo na resposta com o HTTP status code 400. Caso recebido um valor inválido, a detentora deve gerar um x-fapi-interaction-id

Adicionado - "format"

Adição

uuid

PATCH pix/payments/consents/{consentId}

Request

...

Campo

...

O que foi alterado?

...

Tipo da Alteração

...

Antes

...

Depois

...

N° Proposta

...

Data homologação

Response

Data homologação

Campo	O que foi alterado?	Tipo da Alteração	Antes	Depois	N° Proposta	e retorná-lo na resposta com o HTTP status code 400 ou 422 (com o código PARAMETRO_INVALIDO). A iniciadora deve acatar o valor gerado pelo detentor e recebido na resposta.	PSV202

Versões comparadas

Versão antiga 2

Nova versão 3

Chave

POST /consents

Request

Response

Response

GET /consents/{consentId}

Response

GET /consents/{consentId}

Response

POST /pix/payments

Request

POST /pix/payments

Request

Response

Response

GET /pix/payments/{paymentId}

Response

GET /pix/payments/{paymentId}

Response

PATCH pix/payments/{paymentId}

Request

Response

PATCH pix/payments/{paymentId}

Request

Response

PATCH pix/payments/consents/{consentId}

Request

Response

PATCH pix/payments/consents/{consentId}

Request

Response