bacen / pix-api

API Pix: a API do Arranjo de Pagamentos Instantâneos Brasileiro, Pix, criado pelo Banco Central do Brasil.
https://bacen.github.io/pix-api
2.31k stars 262 forks source link

TXId - Número de Caracteres #77

Closed llatsch closed 3 years ago

llatsch commented 3 years ago

O campo TXId tem um limite de caracteres diferente dependendo do tipo QRCode mesmo? Se estático 25 caracteres, se dinâmico, 35 caracteres?

Trechos do Manual de Iniciação: https://www.bcb.gov.br/content/estabilidadefinanceira/pix/Regulamento_Pix/II.ManualdePadroesparaIniciacaodoPix-versao2.0.pdf

1.5.2. Identificador de transação: txid no QR Code estático O objeto primitivo EMV 62-05 Reference Label, conforme especificado no manual do BR Code, é limitado a 25 caracteres e, quando em efeito23, deve ser utilizado para conciliar pagamentos. Trata-se de um identificador de transação que deve ser retransmitido intacto pelo PSP do pagador ao gerar a ordem de pagamento. Essa informação permitirá ao recebedor identificar e correlacionar a transferência, quando recebida, com a apresentação das instruções ao pagador. Os caracteres permitidos no contexto do Pix para o campo txId são: • Letras minúsculas, de ‘a’ a ‘z’ • Letras maiúsculas, de ‘A’ a ‘Z’

1.6.12. O campo 6: txid O campo txid, obrigatório, determina o identificador da transação. O objetivo desse campo é ser um elemento que possibilite ao PSP do recebedor apresentar ao usuário recebedor a funcionalidade de conciliação de pagamentos. Na pacs.008, é referenciado como TransactionIdentification ou idConciliacaoRecebedor. O preenchimento do campo txid é limitado a 35 caracteres na pacs.008.

ninrod commented 3 years ago

O campo TXId tem um limite de caracteres diferente dependendo do tipo QRCode mesmo? Se estático 25 caracteres, se dinâmico, 35 caracteres?

Sim. O Estático, por um limitação do campo 62-05 da SPEC EMV para QRs (merchant presented mode) , base do BR Code, admite 25 chars.

O dinâmico tem seu limite estabelecido pela ISO 20.022, PACS.008 campo TransactionIdentification<txid>, limitado a 35 chars,

regex: [A-Za-z0-9] nos dois casos.

cryptographix commented 3 years ago

@ninrod gostaria de verificar o regex que citou, pois no .yaml v2.0.0, está pattern: "[A-Z0-9-]{1,35}"

por outro lado, nesta mesma versão do yaml, há exemplos que possuem txid na forma de um UUID, ou seja, alfanuméricos minúsculos e separador "-", vide "retorno1" linha 472

Pergunto: Qual a regex correto para QR dinâmico? Ainda, caso for o valor que citou acima, qual a lógica em restringir os TxID desta forma, considerando que no dinâmico, em muitos casos, serão gerados por sistemas backend nos quais o uso de caracteres separadores "-" ou "." é comum, como nos próprios exemplos do yaml.

Ainda, pode confirmar que é vetado uso de espaços em branco? Se é um campo fornecido pelo usuário recebedor por APP, no caso do QR estático, não seria usado como lembrete do tipo "Churrasco da chacara, no 10/10"?

Obrigado

franciscotfmc commented 3 years ago

@SeanWykes tenho essa mesma preocupação. Por hora, no app não estamos permitindo espaços em branco e isso compromete um pouco a experiência. Por outro lado, me parece problemático aceitar espaços no txid.

ninrod commented 3 years ago

@ninrod gostaria de verificar o regex que citou, pois no .yaml v2.0.0, está pattern: "[A-Z0-9-]{1,35}"

Hoje está assim, depois da 2.1.0, [A-Za-z0-9]{26,35} para o dinâmico que [A-Za-z0-9]{1,25} para o estático.

por outro lado, nesta mesma versão do yaml, há exemplos que possuem txid na forma de um UUID, ou seja, alfanuméricos minúsculos e separador "-", vide "retorno1" linha 472

Obrigado pelo reporte, exemplos consertados para a 2.1.0.

Ainda, pode confirmar que é vetado uso de espaços em branco?

vetado, ver regex acima.

Se é um campo fornecido pelo usuário recebedor por APP, no caso do QR estático, não seria usado como lembrete do tipo "Churrasco da chacara, no 10/10"?

No mobile nós não estamos especificamos esta experiência em detalhe. Você como PSP está livre para tratar o "identificador" do QR como você quiser e achar melhor.

Dito isso, cabe ressaltar que o QR dinâmico e tbm o estático apresentam o campo "infoAdicionais" que seria um campo mais apropriado para atribuir "frases" ou informações com espaço.

cryptographix commented 3 years ago

@franciscotfmc

@SeanWykes tenho essa mesma preocupação. Por hora, no app não estamos permitindo espaços em branco e isso compromete um pouco a experiência. Por outro lado, me parece problemático aceitar espaços no txid.

Pois é .. desde o início, tenho tido a impressão de que o TXID no estático possuía um propósito diferente do txid no dinâmico. Me pergunto quem é o usuário de APP que irá saber colocar um "Identificador" alfanumérico maiúsculo sem espaços nem símbolos e tampouco acentos. Os exemplos do UX - "CHURRASCO" - não auxiliam muito neste respeito.

Como não tem na mensageria indicação do uso de estático ou dinâmico, sempre há a possibilidade de alguém criar um estático com TXID que coincide com o TXID de um dinâmico pendente. Aí há margem para erros, enganos e/ou uso malicioso.

ninrod commented 3 years ago

Como não tem na mensageria indicação do uso de estático ou dinâmico, sempre há a possibilidade de alguém criar um estático com TXID que coincide com o TXID de um dinâmico pendente.

haverá uma distinção, agora: estático tem um tamanho diferente do dinâmico, então você conseguiria distinguir usando esta característica.

cryptographix commented 3 years ago

Como não tem na mensageria indicação do uso de estático ou dinâmico, sempre há a possibilidade de alguém criar um @ninrod haverá uma distinção, agora: estático tem um tamanho diferente do dinâmico, então você conseguiria distinguir usando esta característica.

Legal! Tem data prevista para o lançamento da 2.1.0? Temos sistemas já gerando TXID incompatível com a "futura" regra, e iremos precisar isso antes de entrar em produção e também gostaríamos de implementar essa distinção entre estático e dinâmico, para reduzir acessos à base de QRs. O prazo está ficando curto ;(

Por curiosidade, a equipe do PIX considerou a inclusão de algum campo nas mensagens para distinguir a forma de entrada do PIX (manual/QR estático/QR dinâmico), a exemplo do "POS Entry Mode" nas mensagens ISO 8583 das redes de adquirência? Não seria isso uma forma mais "clean" de resolver a questão?

ninrod commented 3 years ago

@SeanWykes

Legal! Tem data prevista para o lançamento da 2.1.0?

"Tem". Sendo bastante transparente, estou trabalhando com a data de hoje. Vamos ver se conseguimos.

Por curiosidade, a equipe do PIX considerou a inclusão de algum campo nas mensagens para distinguir a forma de entrada do PIX (manual/QR estático/QR dinâmico), a exemplo do "POS Entry Mode" nas mensagens ISO 8583 das redes de adquirência? Não seria isso uma forma mais "clean" de resolver a questão?

Sim, em uma outra issue que eu respondi aqui e não consigo encontrar falei sobre isso. Eu tentei inserir essa informação, mas é bem difícil depois de um certo ponto realizar alterações no catálogo de mensagens. Acredito que no futuro esta será uma informação importante e poderá constar no catálogo.