Releases: bacen/pix-api
Releases · bacen/pix-api
2.6.3
- Inclusão de esclarecimento referente ao domínio
AGPSS
do campomodalidadeAgente
para Pix Saque e Pix Troco, dispondo que ele deve ser convertido paraAGFSS
na elaboração da mensagempacs.008
. Optou-se pela não alteração desse domínio (paraAGFSS
) na API Pix neste momento, ficando a uniformização com o Catálogo de Mensagens do SPI reservada para a próxima major version da API Pix. - Descontos em cobranças com vencimento agora podem ser aplicados para datas menores ou iguais à data de vencimento.
- Correção dos exemplos
F
eG
conforme apontado na issue [#485]. - Uniformização das descrições dos campos
/lotecobv/{id}
do request eid
no response do GET/lotecobv/{id}
que semânticamente são o mesmo valor. - Remoção do 'pagador' como campo obrigatório do 'Pix' no seu respectivo schema.
2.6.2
[2.6.2]
- Inclusão do valor
AGTOT
no domínio do campovalor.retirada.troco.modalidadeAgente
. - Ajuste da descrição do valor domínio
AGTOT
de 'Agente Outra Espécie de Pessoa Jurídica' para 'Agente Outra Espécie de Pessoa Jurídica ou Correspondente no País'. - Exclusão do valor
AGPSS
dos domínios dos camposPixValorTroco.troco.modalidadeAgente
eCobPayload.valor.retirada.troco.modalidadeAgente
. - Substituição da expressão 'Prestador de Serviços de Saque' por 'Facilitador de Serviço de Saque' em linha com a nova instrução normativa.
- Correção do exemplo 'cobrança com troco alterável' para inclusão da estrutura
retirada
. - Correção do exemplo 'troco com valor.original alterável', estrutura
retirada.troco
comAGTOT
.
2.6.1
2.6.0
[2.6.0]
- Inclusão e referenciamento de "Status do registro de cobrança" onde lia-se "Status da Cobrança" com a descrição da semântica de cada estado.
- Inclusão do campo
pixCopiaECola
(opcional) correspondente às cobranças. - Na listagem
componentesValor
do objetoPix
foram incluídas as informações relativas aos juros, multas, descontos e abatimentos quando o Pix se refere a um pagamento de cobrança com vencimento. Tendo assim o detalhamento em caso de antecipações ou atrasos no pagamento. - Inclusão do campo
descricao
nos objetos que tratam de Devoluções. - Ajuste na descrição do campo
natureza
nas Devoluções.
2.5.0
[2.5.0]
- Inclusão do atributo
retirada
como campo opcional do objetovalor
nos endpoints de consulta, criação e revisão da cobrança imediata. O campo pode ser preenchido com os atributossaque
outroco
exclusivamente, detalhados pelos atributosvalor
emodalidadeAlteracao
. Se apresentarem o campomodalidadeAlteracao
como valor 1, significa que o usuário pagador pode alterar o valor do saque ou troco.
Em sua ausência, assume-se o valor 0, que significa que o valor do saque ou troco não pode ser alterado. - Inclusão do atributo
componentesValor
como campo opcional nos endpoints de consulta Pix para informações da composição do valor final do Pix, este será detalhado por um array de objetos compostos portipo
evalor
. - Formatações gerais de referências a campos, objetos e schemas.
- Inclusão do domínio
natureza
nas devoluções para diferenciamento de devoluções de Pix comuns, ou oriundos de Saque/Troco. - Referências a https://www.bcb.gov.br/estabilidadefinanceira/pagamentosinstantaneos trocadas por https://www.bcb.gov.br/estabilidadefinanceira/pix.
2.4.0-rc.0
- Inclusão do atributo
retirada
como campo opcional do objetovalor
nos endpoints de consulta, criação e revisão da cobrança imediata. O campo pode ser preenchido com os atributossaque
outroco
exclusivamente, detalhados pelos atributosvalor
emodalidadeAlteracao
. Se apresentarem o campomodalidadeAlteracao
como valor 1, significa que o usuário pagador pode alterar o valor do saque ou troco.
Em sua ausência, assume-se o valor 0, que significa que o valor do saque ou troco não pode ser alterado. - Inclusão do atributo
componentesValor
como campo opcional nos endpoints de consulta Pix para informações da composição do valor final do Pix, este será detalhado por um array de objetos compostos portipo
evalor
. - Formatações gerais de referências a campos, objetos e schemas.
2.3.0
modalidadeAlteracao
agora é um campo opcional do objetovalor
no payload da cobrança imediata e nos endpoints de criação e revisão da cobrança imediata.
Se apresentado como valor 1, significa que o usuário pagador pode alterar o valor da cobrança.
Em sua ausência, assume-se o valor 0, que significa que a cobrança não pode ser alterada.- Não é mais obrigatório que o fragmento de versão (
v2
) esteja presente na location.
Não há problema em manter o fragmento; este será considerado como parte integrante da location. - [#348]: corrige "case" do padrão de datas de
yyyy-mm-dd
->YYYY-MM-DD
. - [#354]: Aprimora a descrição do webhook detalhando
a ativação em caso de devolução de um pix. O callback deve ser ativado, também, no caso de serem atingidos
os status finais da devolução: "devolvido" e "não realizado". - [#356]: Adiciona dois cenários de erro para o endpoint
PUT /pix/{e2eid}/devolucao/{id}
na seção de tratamentos de erros. - [#357]: aprimora a descrição do campo "motivo" no retorno do endpoint
/pix/{e2eid}/devolucao/{id}
.
2.2.2
- [#331]: O campo
validadeAposVencimento
estava constando comoopcional
na resposta da criação da cobrança, um efeito colateral da correção correlata ocorrida na release 2.2.1. - [#334]: adicionados detalhes a respeito da manipulação da revisão da cobrança em cenário de alteração do location.
- [#342]: removidos trechos duplicados na seção de tratamento de erros.
2.2.1
Corrigido:
- Os campos no objeto "devedor" no request do endpoint
PUT /cobv/{txid}
passam a ser opcionais.
Nem sempre o usuário recebedor tem a posse de todas as informações que constavam como obrigatórias. - [#307]: Detalhada a semântica do campo
validadeAposVencimento
. Passa a apresentar redação
detalhando o que ocorre em casos de exceção em que o vencimento da cobrança seja um final de semana
ou um feriado juntamente com a atribuição de um valor pequeno paravalidadeAposVencimento
. - O campo
validadeAposVencimento
estava constando comorequired
, o que estava incorreto.
Quando não preenchido, o PSP recebedor assume o valor deste campo como 30, então não há motivos para
o campo ser obrigatório. - [#269]. A regex do txid, na parte concernente ao tamanho, nos endpoints /pix e no callback webhook,
estava errada. Corrigida de{26,35}
para{1,35}
porque pode haver a presença de pagamentos de QRs
estáticos nesses locais. - [#270]: O id do objeto
location
estava especificado comoint32
. De fato, apenas cerca de 2 bilhões
de possibilidades pode acabar muito rápido para grandes emissores de cobranças. Entendemos que o identificador do objetolotecobv
se encaixa na mesma situação. Nesse sentido, alteramos deint32
paraint64
,
o que não deve causar maiores problemas no momento. - [#249], [#250]: Com a entrada do campo "chave" como identificador do webhook, toda a parte referente à paginação
em GET /webhook perde a razão de existir. Nesse sentido, os parâmetros de busca "inicio" e "fim" passam
a ser opcionais. O objeto de paginação "parametros", também torna-se opcional. - [#239]: Conforme relatado nesta discussão, entendemos que
seria interessante, tanto sob o aspecto de segurança quanto sob o aspecto de funcionalidade, que o
objeto pix agregue o atributo "chave", opcional. - [#241]: Acrescentamos detalhes em relação à questão do acionamento do webhook por parte do PSP recebedor.
- [#294]: Erro de ortografia. Na documentação, onde se lê
pixUrlAcessToken
deveria estar escritopixUrlAccessToken
. - [#273]: O texto do response 202 do endpoint
PATCH lotecobv/{id}
estava erroneamente induzindo o
leitor a pensar que o lote já estava revisado quando, na verdade, estaria apenas em processamento - [#273]: Na lista de violações em lotecobv, havia indicações do endpoint
/lotecobv/{txid}
, o que inexiste. O correto é/lotecobv/{id}
. - [#316]: Duas violações específicas foram removidas por questões de performance.
2.2.1-rc.0
Corrigido:
- Os campos no objeto "devedor" no request do endpoint
PUT /cobv/{txid}
passam a ser opcionais.
Nem sempre o usuário recebedor tem a posse de todas as informações que constavam como obrigatórias. - [#307]: Detalhada a semântica do campo
validadeAposVencimento
. Passa a apresentar redação
detalhando o que ocorre em casos de exceção em que o vencimento da cobrança seja um final de semana
ou um feriado juntamente com a atribuição de um valor pequeno paravalidadeAposVencimento
. - [#269]. A regex do txid, na parte concernente ao tamanho, nos endpoints /pix e no callback webhook,
estava errada. Corrigida de{26,35}
para{1,35}
porque pode haver a presença de pagamentos de QRs
estáticos nesses locais. - [#270]: O id do objeto
location
estava especificado comoint32
. De fato, apenas cerca de 2 bilhões
de possibilidades pode acabar muito rápido para grandes emissores de cobranças. Entendemos que o identificador do objetolotecobv
se encaixa na mesma situação. Nesse sentido, alteramos deint32
paraint64
,
o que não deve causar maiores problemas no momento. - [#249], [#250]: Com a entrada do campo "chave" como identificador do webhook, toda a parte referente à paginação
em GET /webhook perde a razão de existir. Nesse sentido, os parâmetros de busca "inicio" e "fim" passam
a ser opcionais. O objeto de paginação "parametros", também torna-se opcional. - [#239]: Conforme relatado nesta discussão, entendemos que
seria interessante, tanto sob o aspecto de segurança quanto sob o aspecto de funcionalidade, que o
objeto pix agregue o atributo "chave", opcional. - [#241]: Acrescentamos detalhes em relação à questão do acionamento do webhook por parte do PSP recebedor.
- [#294]: Erro de ortografia. Na documentação, onde se lê
pixUrlAcessToken
deveria estar escritopixUrlAccessToken
. - [#273]: O texto do response 202 do endpoint
PATCH lotecobv/{id}
estava erroneamente induzindo o
leitor a pensar que o lote já estava revisado quando, na verdade, estaria apenas em processamento - [#273]: Na lista de violações em lotecobv, havia indicações do endpoint
/lotecobv/{txid}
, o que inexiste. O correto é/lotecobv/{id}
. - [#316]: Duas violações específicas foram removidas por questões de performance.