API Pix: a API do Arranjo de Pagamentos Instantâneos Brasileiro, Pix, criado pelo Banco Central do Brasil.
AGPSS do campo modalidadeAgente para Pix Saque e Pix Troco, dispondo que ele deve ser convertido para AGFSS na elaboração da mensagem pacs.008. Optou-se pela não alteração desse domínio (para AGFSS) 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.F e G conforme apontado na issue [#485]./lotecobv/{id} do request e id no response do GET /lotecobv/{id} que semânticamente são o mesmo valor.AGTOT no domínio do campo valor.retirada.troco.modalidadeAgente.AGTOT de 'Agente Outra Espécie de Pessoa Jurídica' para 'Agente Outra Espécie de Pessoa Jurídica ou Correspondente no País'.AGPSS dos domínios dos campos PixValorTroco.troco.modalidadeAgente e CobPayload.valor.retirada.troco.modalidadeAgente.retirada.retirada.troco com AGTOT.modalidadeAgente do Pix Troco para aceitar somente AGTEC.BE08 e FR01.pixCopiaECola [#457].pixCopiaECola (opcional) correspondente às cobranças.componentesValor do objeto Pix 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.descricao nos objetos que tratam de Devoluções.natureza nas Devoluções.retirada como campo opcional do objeto valor nos endpoints de consulta, criação e revisão da cobrança imediata. O campo pode ser preenchido com os atributos saque ou troco exclusivamente, detalhados pelos atributos valor e modalidadeAlteracao. Se apresentarem o campo modalidadeAlteracao 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.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 por tipo e valor.natureza nas devoluções para diferenciamento de devoluções de Pix comuns, ou oriundos de Saque/Troco.retirada como campo opcional do objeto valor nos endpoints de consulta, criação e revisão da cobrança imediata. O campo pode ser preenchido com os atributos saque ou troco exclusivamente, detalhados pelos atributos valor e modalidadeAlteracao. Se apresentarem o campo modalidadeAlteracao 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.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 por tipo e valor.modalidadeAlteracao agora é um campo opcional do objeto valor
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.v2) esteja presente na location.
Não há problema em manter o fragmento; este será considerado como parte integrante da location.yyyy-mm-dd -> YYYY-MM-DD.PUT /pix/{e2eid}/devolucao/{id} na seção de tratamentos de erros./pix/{e2eid}/devolucao/{id}.validadeAposVencimento estava constando como opcional na resposta da criação da cobrança, um efeito colateral da correção correlata ocorrida na release 2.2.1.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.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 para validadeAposVencimento.validadeAposVencimento estava constando como required, 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.{26,35} para {1,35} porque pode haver a presença de pagamentos de QRs
estáticos nesses locais.location estava especificado como int32. 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 objeto lotecobv
se encaixa na mesma situação. Nesse sentido, alteramos de int32 para int64,
o que não deve causar maiores problemas no momento.pixUrlAcessToken deveria estar escrito pixUrlAccessToken.PATCH lotecobv/{id} estava erroneamente induzindo o
leitor a pensar que o lote já estava revisado quando, na verdade, estaria apenas em processamento/lotecobv/{txid}, o que inexiste. O correto é /lotecobv/{id}.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.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 para validadeAposVencimento.{26,35} para {1,35} porque pode haver a presença de pagamentos de QRs
estáticos nesses locais.location estava especificado como int32. 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 objeto lotecobv
se encaixa na mesma situação. Nesse sentido, alteramos de int32 para int64,
o que não deve causar maiores problemas no momento.pixUrlAcessToken deveria estar escrito pixUrlAccessToken.PATCH lotecobv/{id} estava erroneamente induzindo o
leitor a pensar que o lote já estava revisado quando, na verdade, estaria apenas em processamento/lotecobv/{txid}, o que inexiste. O correto é /lotecobv/{id}.