Versão API-PIX vs Manual de Iniciação vs Payload

[cryptographix]

Por favor, pode informar:

1. Quando irá sair a versão 2.1 da especificação "Manual de Iniciação do PIX"? Isso é importante, pois há áreas de desenvolvimento que se baseiam na documentação oficial e estão relutantes de mexer na última hora (estamos afinal a poucos dias do soft-opening) sem ter esse documento!

2. Se os novos campos referentes a multa/juros/etc se aplicam somente a escopo do API Pix, ou seja, o valor atualizado dos juros e multa, e consequentemente o valor total, serão calculados pelo PSP ao retornar o JSON assinado, ou se cabe aos Wallets / PSP do pagador calcular o total?

Pergunto isso pelo seguinte: A regra é que só se deve pagar um QR dinâmico dentro do mesmo dia da data de apresentação recebida no payload. Portanto, o PSP do recebedor sempre teria como calcular os juros, multa, desconto e abatimentos do dia corrente e informar os valores calculados e o valor total correto. Aí, o pagador simplesmente utilizará o valor total recebido.

Desta forma, o cálculo será feito sempre pelo recebedor, que, afinal, terá de verificar que o valor recebido pelo SPI está de acordo, possivelmente já no PACS.008.

Por outro lado, se estes campos novos constam no payload, ficará para os 1000+ wallets diferentes efetuar esses cálculos?

3. Se será modificada a versão do payload para 2.1.0, uma vez que há diversas instituições já gerando e processando payloads de acordo com v2.0.0. Será que há tempo ágil para a implementação do 2.1.0 por todos os participantes antes do soft opening?

Obrigado.

[rubenskuhl]

Não me pareceu que o payload tenha mudado entre a 2.0.0 e a 2.1.0-rc2... os campos já existiam no payload e na PACS.008, só não tinham como ser informados via API.

[cryptographix]

@rubenskuhl No 2.0.0, estão como "string". No 2.1.0 pelo YAML, cada campo juros/multo/abatimento virou uma "OneOf" para cálculo { percentual, absoluto } do valor, e o desconto virou um vetor de até dois elementos, contendo data + desconto { percentual, absoluto }.

Eis a minha pergunta, o payload irá ficar igual e o cálculo feito sempre pelo recebedor? Se assim, como informar estas regras (1% ao mês) ao pagador, conforme o manual de UX que já exibe o campo juros desta forma?

[ninrod]

@SeanWykes ,

Quando irá sair a versão 2.1 da especificação "Manual de Iniciação do PIX"? Isso é importante, pois há áreas de desenvolvimento que se baseiam na documentação oficial e estão relutantes de mexer na última hora (estamos afinal a poucos dias do soft-opening) sem ter esse documento!

Entendo a preocupação. Gostaria de ressaltar, entretanto, que não há data estabelecida para implementação da API Pix por parte do PSP recebedor. Em particular, não é obrigatório que, no soft opening, ou no "go live", o PSP recebeder já tenha uma API Pix funcionando e disponível para o mercado.

Isto posto, a versão final e oficial deve sair "em breve", possivelmente esta semana.

Se os novos campos referentes a multa/juros/etc se aplicam somente a escopo do API Pix, ou seja, o valor atualizado dos juros e multa, e consequentemente o valor total, serão calculados pelo PSP ao retornar o JSON assinado, ou se cabe aos Wallets / PSP do pagador calcular o total?

Explicar esse funcionamento é justamente um dos pontos que a nova versão do manual de iniciação agrega. Adiantando por aqui, como de praxe, é o PSP do pagador que seria responsável pelo cálculo final do valor da cobrança em função de seus elementos e em função de uma informação crítica que somente o PSP do pagador possui: o domicílio bancário do pagador, o qual é utilizado como base para cálculo de feriados municipais e estaduais que afetam a PDU (próxima data útil), e, consequentemente, o valor final da cobrança (juros pró rata die, multa por atraso, descontos por antecipação).

Por outro lado, se estes campos novos constam no payload, ficará para os 1000+ wallets diferentes efetuar esses cálculos?

Sim, ficará. Não há outra maneira, dado o arcabouço regulatório vigente que transcende a API. Entretando, a maneira pela qual este cálculo deverá ser executado estará especificada no Manual de Iniciação.

Se será modificada a versão do payload para 2.1.0, uma vez que há diversas instituições já gerando e processando payloads de acordo com v2.0.0. Será que há tempo ágil para a implementação do 2.1.0 por todos os participantes antes do soft opening?

@SeanWykes , estamos falando aqui especificamente da leitura do QR dinâmico do ponto de vista do APP pagador, que, se não me falha a memória, seria obrigatório para o soft opening. Entendo a preocupação colocada. Devido a essa questão da complexidade agregada ao payload por conta da "função vencimento" (juros, multa, PDU, etc...), está se considerando estabelecer um prazo distinto do estático para o dinâmico. Recomendo consultar o DECEM, nos canais apropriados para saber mais sobre esse desenvolvimento.

[grazipellecchia]

@SeanWykes ,

Quando irá sair a versão 2.1 da especificação "Manual de Iniciação do PIX"? Isso é importante, pois há áreas de desenvolvimento que se baseiam na documentação oficial e estão relutantes de mexer na última hora (estamos afinal a poucos dias do soft-opening) sem ter esse documento!

Entendo a preocupação. Gostaria de ressaltar, entretanto, que não há data estabelecida para implementação da API Pix por parte do PSP recebedor. Em particular, não é obrigatório que, no soft opening, ou no "go live", o PSP recebeder já tenha uma API Pix funcionando e disponível para o mercado.

Isto posto, a versão final e oficial deve sair "em breve", possivelmente esta semana.

Se os novos campos referentes a multa/juros/etc se aplicam somente a escopo do API Pix, ou seja, o valor atualizado dos juros e multa, e consequentemente o valor total, serão calculados pelo PSP ao retornar o JSON assinado, ou se cabe aos Wallets / PSP do pagador calcular o total?

Explicar esse funcionamento é justamente um dos pontos que a nova versão do manual de iniciação agrega. Adiantando por aqui, como de praxe, é o PSP do pagador que seria responsável pelo cálculo final do valor da cobrança em função de seus elementos e em função de uma informação crítica que somente o PSP do pagador possui: o domicílio bancário do pagador, o qual é utilizado como base para cálculo de feriados municipais e estaduais que afetam a PDU (próxima data útil), e, consequentemente, o valor final da cobrança (juros pró rata die, multa por atraso, descontos por antecipação).

Por outro lado, se estes campos novos constam no payload, ficará para os 1000+ wallets diferentes efetuar esses cálculos?

Sim, ficará. Não há outra maneira, dado o arcabouço regulatório vigente que transcende a API. Entretando, a maneira pela qual este cálculo deverá ser executado estará especificada no Manual de Iniciação.

Se será modificada a versão do payload para 2.1.0, uma vez que há diversas instituições já gerando e processando payloads de acordo com v2.0.0. Será que há tempo ágil para a implementação do 2.1.0 por todos os participantes antes do soft opening?

@SeanWykes , estamos falando aqui especificamente da leitura do QR dinâmico do ponto de vista do APP pagador, que, se não me falha a memória, seria obrigatório para o soft opening. Entendo a preocupação colocada. Devido a essa questão da complexidade agregada ao payload por conta da "função vencimento" (juros, multa, PDU, etc...), está se considerando estabelecer um prazo distinto do estático para o dinâmico. Recomendo consultar o DECEM, nos canais apropriados para saber mais sobre esse desenvolvimento.

@ninrod BOM DIA, espero que está tudo bem. Entendo a preocupação do colega @SeanWykes realmente como PSP Pagador existe a obrigatoriedade para o soft opening e se cada PSP Recebedor criar o QR Dinâmico de um jeito a experiência do cliente poderá ser ruim. O ideal seria mesmo ter um prazo distinto do estático e dinâmico.

[franciscotfmc]

Bom dia! Compartilho da mesma preocupação. Enviei e-mail ao DECEM mas ainda não obtive resposta.

[cryptographix]

@SeanWykes ,

Quando irá sair a versão 2.1 da especificação "Manual de Iniciação do PIX"? Isso é importante, pois há áreas de desenvolvimento que se baseiam na documentação oficial e estão relutantes de mexer na última hora (estamos afinal a poucos dias do soft-opening) sem ter esse documento!

Entendo a preocupação. Gostaria de ressaltar, entretanto, que não há data estabelecida para implementação da API Pix por parte do PSP recebedor. Em particular, não é obrigatório que, no soft opening, ou no "go live", o PSP recebeder já tenha uma API Pix funcionando e disponível para o mercado. Isto posto, a versão final e oficial deve sair "em breve", possivelmente esta semana.

Se os novos campos referentes a multa/juros/etc se aplicam somente a escopo do API Pix, ou seja, o valor atualizado dos juros e multa, e consequentemente o valor total, serão calculados pelo PSP ao retornar o JSON assinado, ou se cabe aos Wallets / PSP do pagador calcular o total?

Explicar esse funcionamento é justamente um dos pontos que a nova versão do manual de iniciação agrega. Adiantando por aqui, como de praxe, é o PSP do pagador que seria responsável pelo cálculo final do valor da cobrança em função de seus elementos e em função de uma informação crítica que somente o PSP do pagador possui: o domicílio bancário do pagador, o qual é utilizado como base para cálculo de feriados municipais e estaduais que afetam a PDU (próxima data útil), e, consequentemente, o valor final da cobrança (juros pró rata die, multa por atraso, descontos por antecipação).

Por outro lado, se estes campos novos constam no payload, ficará para os 1000+ wallets diferentes efetuar esses cálculos?

Sim, ficará. Não há outra maneira, dado o arcabouço regulatório vigente que transcende a API. Entretando, a maneira pela qual este cálculo deverá ser executado estará especificada no Manual de Iniciação.

Se será modificada a versão do payload para 2.1.0, uma vez que há diversas instituições já gerando e processando payloads de acordo com v2.0.0. Será que há tempo ágil para a implementação do 2.1.0 por todos os participantes antes do soft opening?

@SeanWykes , estamos falando aqui especificamente da leitura do QR dinâmico do ponto de vista do APP pagador, que, se não me falha a memória, seria obrigatório para o soft opening. Entendo a preocupação colocada. Devido a essa questão da complexidade agregada ao payload por conta da "função vencimento" (juros, multa, PDU, etc...), está se considerando estabelecer um prazo distinto do estático para o dinâmico. Recomendo consultar o DECEM, nos canais apropriados para saber mais sobre esse desenvolvimento.

@ninrod BOM DIA, espero que está tudo bem. Entendo a preocupação do colega @SeanWykes realmente como PSP Pagador existe a obrigatoriedade para o soft opening e se cada PSP Recebedor criar o QR Dinâmico de um jeito a experiência do cliente poderá ser ruim. O ideal seria mesmo ter um prazo distinto do estático e dinâmico.

@ninrod A questão aqui é que está prevista a criação de QR Dinâmico por aplicativo e também por sistemas internos que não utilizam o API Pix. Além disso, e reforçando as colocações da @grazipellecchia, a leitura do QR dinâmico já é uma realidade, portanto é preciso pelo menos garantir a consistência e experiência do lado pagador.

Quanto a versão do payload, será de acordo com a versão da especificação? O pagador já terá de conviver com duas versões desde o início?

[ninrod]

@grazipellecchia , bom dia.

@ninrod BOM DIA, espero que está tudo bem. Entendo a preocupação do colega @SeanWykes realmente como PSP Pagador existe a obrigatoriedade para o soft opening e se cada PSP Recebedor criar o QR Dinâmico de um jeito a experiência do cliente poderá ser ruim. O ideal seria mesmo ter um prazo distinto do estático e dinâmico.

Foi repassada ao DECEM esta exata preocupação. Realmente, o canal seria com eles.

[ninrod]

@SeanWykes ,

@ninrod A questão aqui é que está prevista a criação de QR Dinâmico por aplicativo e também por sistemas internos que não utilizam o API Pix. Além disso, e reforçando as colocações da @grazipellecchia, a leitura do QR dinâmico já é uma realidade, portanto é preciso pelo menos garantir a consistência e experiência do lado pagador.

Não entendi o "a leitura do QR dinâmico já é uma realidade". Como assim, especificamente?

é preciso pelo menos garantir a consistência e experiência do lado pagador.

Ponto importante.

[cryptographix]

@SeanWykes ,

@ninrod A questão aqui é que está prevista a criação de QR Dinâmico por aplicativo e também por sistemas internos que não utilizam o API Pix. Além disso, e reforçando as colocações da @grazipellecchia, a leitura do QR dinâmico já é uma realidade, portanto é preciso pelo menos garantir a consistência e experiência do lado pagador.

Não entendi o "a leitura do QR dinâmico já é uma realidade". Como assim, especificamente?

Quero dizer que, até neste exato momento, é obrigatório implementar a leitura do QR Code dinâmico no APP pagador. Neste sentido, já é uma realidade em muitos code-bases por aí, conforme por exemplo, a movimentação do grupo de telegram, embora, claro, ainda não estamos no soft-opening.

A preocupação, além da UX, é se teríamos (como uma comunidade) tempo hábil para mexer neste códigos até a data prevista.

[grazipellecchia]

@grazipellecchia , bom dia.

@ninrod BOM DIA, espero que está tudo bem.

Entendo a preocupação do colega @SeanWykes realmente como PSP Pagador existe a obrigatoriedade para o soft opening e se cada PSP Recebedor criar o QR Dinâmico de um jeito a experiência do cliente poderá ser ruim. O ideal seria mesmo ter um prazo distinto do estático e dinâmico.

Foi repassada ao DECEM esta exata preocupação. Realmente, o canal seria com eles.

@ninrod muito obrigada.

[ninrod]

Quero dizer que, até neste exato momento, é obrigatório implementar a leitura do QR Code dinâmico no APP pagador. Neste sentido, já é uma realidade em muitos code-bases por aí, conforme por exemplo, a movimentação do grupo de telegram, embora, claro, ainda não estamos no soft-opening.

A preocupação, além da UX, é se teríamos (como uma comunidade) tempo hábil para mexer neste códigos até a data prevista.

Perfeito, seria interessante relatar esta situação ao DECEM. Particularmente já o fiz, mas demais questões acerca desta movimentação seriam melhor endereçadas diretamente com eles.

[cryptographix]

@ninrod obrigado! Já acionamos o pessoal para falar com o DECEM.

Fiquei com uma dúvida, vi que o campo "versao" foi removido do payload na v2.0, apenas de ter sido obrigatório na v1.0. Isso procede ou foi removido por engano? Será reencarnado para v2.1 como forma de distinguir principalmente os campos multa e juros que estão incompatíveis (mudança de string para objeto) nesta v2.1.0??

[ninrod]

Fiquei com uma dúvida, vi que o campo "versao" foi removido do payload na v2.0, apenas de ter sido obrigatório na v1.0. Isso procede ou foi removido por engano? Será reencarnado para v2.1 como forma de distinguir principalmente os campos multa e juros que estão incompatíveis (mudança de string para objeto) nesta v2.1.0??

Foi "migrado" para a URL: agora estamos na v2. acompanha o major version.

[cryptographix]

Fiquei com uma dúvida, vi que o campo "versao" foi removido do payload na v2.0, apenas de ter sido obrigatório na v1.0. Isso procede ou foi removido por engano? Será reencarnado para v2.1 como forma de distinguir principalmente os campos multa e juros que estão incompatíveis (mudança de string para objeto) nesta v2.1.0??

Foi "migrado" para a URL: agora estamos na v2. acompanha o major version.

Onde encontro essa informação, no novo manual de iniciação? Não encontrei nada no v2.0 ..

[ninrod]

@SeanWykes fica aqui.

[cryptographix]

@SeanWykes fica aqui.

Valeu. Não tinha visto mesmo. https://{fdqnPSPRecebedor}/{pixEndpoint}/v2

Não sei se isso é uma boa, a versão explícita dentro do payload ficava mais clara e mais fácil de interpretar, pois podem ser feitas as maquiações no baixo nível (ler JSON, validar versão, interpretar e converter conteúdo de acordo), e não vejo que uma versão no URL ajuda muito nisso, mas pode ser que faltou algo na minha leitura.

Entendo que isso faz sentido para a API Pix, onde poderá ter múltiplas versões simultâneas rodando no mesmo servidor, ou onde você pode querer barrar APPs de versões anteriores, mas não sei se fica legal para o payload. Uma de duas, 1) significa que o APP pagador terá de interpretar o final do URL para saber a versão do JSON que irá receber, ou 2) o APP terá de concatenar a versão que entende, e o endpoint eventualmente tratar versões diferentes de acordo com as requisições do APPs.

Pode clarear a semântica desta versão, please ..

[ninrod]

Seria a 1).

[cryptographix]

@ninrod já que foi mexido o url para busca do payload, porque então o pagador não pode incluir parâmetros opcionais na requisição que permitirão ao PSP recebedor calcular o valor final.

Por exemplo, se é questão de feriados no domicílio bancário do pagador, pode incluir no url um "?prox_dia_util=2020-10-27". Além de simplificar o processo do pagador, permitirá ao PSP guardar o "valor final" entregue ao pagador, para futuro batimento contra o valor realmente recebido no PACS.008.

Just an idea!

[ninrod]

@SeanWykes ,

@ninrod já que foi mexido o url para busca do payload, porque então o pagador não pode incluir parâmetros opcionais na requisição que permitirão ao PSP recebedor calcular o valor final.

Por exemplo, se é questão de feriados no domicílio bancário do pagador, pode incluir no url um "?prox_dia_util=2020-10-27". Além de simplificar o processo do pagador, permitirá ao PSP guardar o "valor final" entregue ao pagador, para futuro batimento contra o valor realmente recebido no PACS.008.

Just an idea!

Obrigado pela contribuição, mas peço que aguarde a versão final desta release. Estamos pensando em uma maneira para facilitar o cálculo para o PSP pagador e ainda assim prover alguma flexibilidade para o Usuário recebedor em termos de cenários de vencimento.