pix-api
pix-api copied to clipboard
bacen
Errata do Manual de Iniciação PIX v2.2 - Sugestões de melhorias
Acabamos de ler o Manual de Iniciação PIX v2.2 e constatamos algumas pequenas questões/dúvidas. Este issue, caso convém, pode servir para agrupar outras questões levantadas referentes a esse documento.
pg. 9 - QR Dinâmico A redação atual é "Valor .. Identificador da Transação" .. não devem ser preenchidos .. ", e segue com "quando presentes .. deve ser utilizada a semântica do BR Code ... esses campos podem ter os mesmos valores do payload JSON .."
Sugiro fazer um "cleanup" da redação, pois atualmente deixa margem de interpretação, e o leitor precisa digerir as várias notas de rodapé. Por exemplo, pode-se separar as questões recebedor/pagador e assim deixar uma redação mais clara:
** GERAÇÃO - gerar sempre sem VALOR e com TXID = "***".
** USO - sempre desprezar eventuais valores presentes no QR
Idem campos como nome, cidade, etc do QR, deixar claro que devem ser desprezados e sempre utilizados os valores do DICT, e na geração, podem ser preenchidos com "marcadores" ou valores fixos como "PIX", "BR", etc.
Pg. 11 - Revisão A redação indica que a revisão permite a rastreabilidade do payload, no entanto não versa sobre quando deve ser incrementada. A nossa dúvida é se PODE/DEVE ser incrementada a revisão a cada vez que é calculado o valor final com base em variações de multa/juros incorridas por datas "DPP" diferentes, por exemplo.
Pg. 19 - Exemplo do QR Dinâmico O QR possui um TXID no 62:05 contrariando a questão de TXID > 25 para dinâmico, e induzindo o leitor desatento a erros.
O manual de padrões de iniciação continua sugerindo informações conflitantes.
Página 8 (pág. 12 do PDF)
Por que não manter apenas o primeiro parágrafo?
-
valor(TransactionAmount) e otxidnão devem estar presentes no QR Code dinâmico; - se estiverem presentes, o PSP pagador deve ignorar seu conteúdo;
Todo o restante,é desnecessário e está levando aos mais diversos erros de implementação, inclusive a recusa do QR na ausência do campo 62 (que é opcional), abertura do campo de valor para edição por parte do pagador (quando campo valor ausente ou igual a 0.00 - situações esperadas especialmente para QR dinâmicos com reuso de location), etc. Todas falhas graves.
Inclusive o exemplo de QR Code nas páginas 18 e 19 do manual (22 e 23 do PDF) incluem um txid no campo 62-05 que não é o da cobrança, pois cobranças não podem ter txid com comprimento inferior a 26 caracteres (mínimo 26 e máximo 35, conforme página 13 do próprio manual (pág. 17 do PDF)) - e o limite do campo 62-05 no EMV / BRCode é justamente 25 caracteres.
Página 5 (pág. 9 do PDF)
Há uma menção a "3-infoAdicionais" onde deveria ser "3-infoAdicional" (no singular).
Nota de rodapé 23 diz:
Conforme EMV QRCPS–MPM QR Codes for Payment Systems – Merchant Presented Mode, seção 4.8.1.2: “If present, the content of the data object value for IDs "01" to "08" shall be either
***or a value defined by the merchant. The presence of***indicates that the mobile application is responsible for obtaining the necessary information”. Conclui-se que, se o gerador do QR optar por não utilizar um transactionID, o valor***deverá ser usado para indicar essa escolha.
Tradução do EMV QRCPS-MPM QR Codes for Payment Systems - Merchant Present Mode:
Se presente, o conteúdo do objeto de dados para os IDs "01" a "08" devem ser, alternativamente,
***OU um valor definido pelo comerciante. A presença de***indica que o aplicativo é responsável por obter essa informação necessária.
Então, na minha interpretação, para os QR Codes estáticos, a presença ou omissão do campo txid (62-05) representaria:
- omitido (admitido pelo EMV e pelo BR Code): transação sem txid;
- presente com valor
***: o aplicativo deve obter essa informação e ela é necessária (o pagador teria que digitar um txid!); - presente diferente de
***: o valor informado é o txid efetivo (e não modificável).
Para os QR Codes dinâmicos, a presença ou omissão do campo txid (62-05) representaria:
- omitido (omissão admitida pelo EMV e pelo BR Code): txid vem do payload, de qualquer forma;
- presente com valor
***: o aplicativo deve obter essa informação e ela é necessária (obtido do payload); - presente diferente de
***: deve ser ignorado pois o campo é limitado a 25 caracteres e cobranças tem txid de comprimento {26,35} (txid é obtido do payload);
Concordo plenamente com a análise e proposta de redação do @renatofrota .. está na hora de clarear esse assunto para todos os desenvolvedores do PIX, ainda estamos vendo QRs (e também payloads) emitidos com diversas divergências do esperado.
Sugiro criarmos um texto semelhante para o payload, para clarear questões como geração com campos (tipo data e string) ausentes, com valor nulo ou com valor "" (string vazia) - todos devem ser tratados como se fosse ausente o campo, campos da seção "valor:" como numéricos ou string "V.nn", os mesmos ausentes ou com valor "0", etc.
Caros(-as), segue link para manual do BACEN .. Lista de Verificação para Geração de Validação de QR Codes .. bastante esclarecedor.
https://www.bcb.gov.br/content/estabilidadefinanceira/pix/ListadeverificacaoparageracaoevalidacaodeQRCodes.pdf
@SeanWykes ,
com esse documento, entendo que o BACEN está decidido na questão do Pix exigir o campo 62-05 (conforme manual br code). Sendo assim, parte das sugestões que dei acima sobre txid não são aceitáveis (omissão do txid).
Porém, a nota de rodapé do manual de padrões de iniciação pix, que ainda cita a "dedução" dessa exigência com base na tradução incorreta da especificação EMV, deveria ser totalmente descartada. A razão é unicamente a aderência ao manual br code do próprio BACEN, que tornou o campo obrigatório.
As demais coisas que pontuei acima também permanecem relevantes.
Mas agora a dúvida que surgiu com esse documento: o uso de caracteres acentuados. O BR Code explicitamente excluiu essa restrição em 25/05 (v2.0.0) e permanece assim na 2.0.1. Agora esse novo documento reforça a necessidade de adequação ao character set ANS do padrão EMV. 🙄
Ainda fiquei insatifeito com a redação que diz para preferir a informação do payload à do QR Code "quando divergentes".
Acaso é possível a existência de payload sem chave (com a qual se obtém dados do recebedor no DICT) ou sem txid? Entendo que não. Então permanece a ausência de uma orientação direta e clara: os dados do recebedor e o txid devem ser os obtidos do payload e do DICT, descartando-se os dados eventualmente presentes no QR Code.
Melhor ainda se fosse inadmitida a presença desses dados no QR Code dinâmico, pra garantir que tudo virá do payload.
Ainda fiquei insatifeito com a redação que diz para preferir a informação do payload à do QR Code "quando divergentes".
Acaso é possível a existência de payload sem chave (com a qual se obtém dados do recebedor no DICT) ou sem txid? Entendo que não. Então permanece a ausência de uma orientação direta e clara: os dados do recebedor e o txid devem ser os obtidos do payload e do DICT, descartando-se os dados eventualmente presentes no QR Code.
Melhor ainda se fosse inadmitida a presença desses dados no QR Code dinâmico, pra garantir que tudo virá do payload.
@renatofrota penso que neste caso, o padrão está permitindo convivência com outros arranjos de pagamento, por exemplo, os QR Codes das bandeiras de crédito e de adquirentes (Cielo, Vero, ...) que possam utilizar estes campos do EMV para fins próprios. Aí não tem como inadmití-los.
No entanto, poderia ser isso explicitado, tipo .. "em se tratanto de um QR Code puramente PIX (com um único arranjo), estes campos não devem ser presentes .." etc.
Já a obrigatóriedade do TXID com "***" não é cabível por nenhuma ótica que consigo ver, a não mera exigência do BR Code por motivos nada claros.
Saudações ..
Tem razão, @SeanWykes . Não teria como conviver sem essas informações.
Porém, a redação "no caso de conflito" ainda faz entender que o conteúdo destes campos no QR code deve ser avaliado e comparado com o payload (pra quê?). Muito mais eficiente seria dizer que estes campos, ainda que presentes por força da documentação BR Code para outros arranjos, devem ser ignorados [sempre].
Mas enfim. O documento é, sim, esclarecedor em vários pontos. A equipe envolvida na criação e desenvolvimento do Pix merece congratulações. Só sugiro mudanças com a intenção de melhorar ainda mais, de acordo com o meu ponto de vista.
Caros(-as), segue link para manual do BACEN .. Lista de Verificação para Geração de Validação de QR Codes .. bastante esclarecedor.
https://www.bcb.gov.br/content/estabilidadefinanceira/pix/ListadeverificacaoparageracaoevalidacaodeQRCodes.pdf
É um guia/auxílio, mas nada ali substitui ou modifica nenhuma definição dos manuais. Particularmente, em nenhum momento foi definido que *** é obrigatório em um BRCode. De fato, se tiver que preencher o 62.05, mas não há nenhum txid (porque não, porque o recebedor não quer, e não é obrigatório), então a alternativa apontada foi o ***. Basta remover a obrigatoriedade de 62.05 no BRCode (@renatofrota sugeriu isso enfaticamente em outra thread, com razão), "limpar" o Manual de Iniciação, e vamos em frente. Como isso soa para os senhores?
Bom dia,
Particularmente, em nenhum momento foi definido que *** é obrigatório em um BRCode.
É verdade que no manual do BR Code não consta o *** como obrigatório, mas o 62-05 é campo mandatório (pg 10)
https://www.bcb.gov.br/content/estabilidadefinanceira/spb_docs/ManualBRCode.pdf
De fato, se tiver que preencher o 62.05, mas não há nenhum txid (porque não, porque o recebedor não quer, e não é obrigatório), então a alternativa apontada foi o ***
O *** vem do EMV, a nota de rodapé 23 dá uma breve explicação em
https://www.bcb.gov.br/content/estabilidadefinanceira/pix/Regulamento_Pix/II-ManualdePadroesparaIniciacaodoPix.pdf
Conforme EMV QRCPS–MPM QR Codes for Payment Systems – Merchant Presented Mode, seção 4.8.1.2: “If present, the content of the data object value for IDs "01" to "08" shall be either "***" or a value defined by the merchant. The presence of "***" indicates that the mobile application is responsible for obtaining the necessary information”. Conclui-se que, se o gerador do QR optar por não utilizar um transactionID, o valor ‘***’ deverá ser usado para indicar essa escolha.
Sim @dev-gto, este é o ponto. O padrão EMV não obriga o 62. Fizemos isso no BRCode (e podemos desfazê-lo). Citar literalmente o padrão EMV na nota de rodapé não ajudou muito na confusão dos '***', parece. A frase final deveria ser "poderá ser usado para indicar essa escolha se o Pix for o único trilho de pagamento" (porque esse identificador poderia ser de outro meio de pagamento). E também por isso alertei que a "Lista de verificação" é explicativa, e não normativa. E como apontado pelo @renatofrota, explicar demais pode também gerar confusão: "no caso de conflito", por exemplo... O Manual de Iniciação já indica que sempre prevalece o payload jws.