Qr Code dinâmico no aplicativo

[vivicupola]

Eu tenho uma dúvida relacionada a criação de um Qr code dinâmico via App do PSP, e gostaria de esclarecer: No item - "O txid é criado exclusivamente pelo usuário recebedor e está sob sua responsabilidade. O txid, no contexto de representação de uma cobrança, é único por CPF/CNPJ do usuário recebedor. " No caso de um Qr Code dinâmico gerado no Mobile, posso deixar uma parte do campo de responsabilidade do usuário recebedor, e outra parte dele (por exemplo, as 10 últimas posições) para que o PSP possa garantir a unicidade do campo? Por exemplo, o usuário digita "Churrasco". Seria de responsabilidade deles, no próximo Qr que ele gerar, ele criar um outro txid, ou o PSP pode criar mecanismos internos para que isso fique transparente ao cliente, que mesmo que ele crie novamente "churrasco", este campo continuaria sendo único, de acordo com algum critério interno? Obrigada.

[ninrod]

Prezada @vivicupola .

No caso de um Qr Code dinâmico gerado no Mobile, posso deixar uma parte do campo de responsabilidade do usuário recebedor, e outra parte dele (por exemplo, as 10 últimas posições) para que o PSP possa garantir a unicidade do campo?

Preciso deixar esta questão em aberto apenas para amarrar o entendimento internamente. Peço que aguarde a resposta definitiva.

Por exemplo, o usuário digita "Churrasco". Seria de responsabilidade deles, no próximo Qr que ele gerar, ele criar um outro txid, ou o PSP pode criar mecanismos internos para que isso fique transparente ao cliente, que mesmo que ele crie novamente "churrasco", este campo continuaria sendo único, de acordo com algum critério interno?

Ver resposta acima.

[renatofrota]

Se o txid internamente não será exatamente o que foi estipulado pelo cliente recebedor (que está solicitando a geração da Cobrança), como ele vai saber o txid a utilizar nas consultas posteriores via GET /cob e GET /pix, já que não há qualquer resposta enviada pelo PSP ao cliente no ato da criação da cobrança? E ainda que houvesse, feriria o princípio de idempotência, já debatido em outras issues.

Eu entendo que você poderia associar o txid fornecido pelo cliente (com comprimento de 35 posições) a um complemento (interno) de N posições mas, ainda assim, as Cobranças/Pix associadas devem ser retornadas quando pesquisadas pelo txid (exatamente como fornecido pelo cliente no momento da criação).

Talvez você possa atingir o mesmo objetivo criando um campo adicional (invisível ao cliente) com o valor que bem entender e aí usar chaves compostas (txid + o campo complementar interno). Mas, no meu ponto de vista (não sou dbadmin mas tenho lá o meu conhecimento), os PSP deveriam evitar enxergar o txid com uma chave, de maneira geral, e sim como um campo informativo extra qualquer (que ainda podem ser indexados(!)), pois os valores passados como txid tendem, naturalmente, a se repetir, principalmente para o mesmo cliente (por natureza nos QR Codes estáticos) e, também, ao considerar que há clientes distintos usando os mesmos txid (em todos os tipos de iniciação Pix).

Disclaimer: não estou respondendo oficialmente. Apenas colaborativamente.

[rubenskuhl]

Me parece que o caso de uso em questão é de QR-Code dinâmico no aplicativo do PSP, e não na API. Então a escolha de TxID é feita pelo PSP, mesmo que ela use em sua composição uma string definida pelo cliente.

Por exemplo, o TxID perguntado pelo mobile pode ser sempre de 25 posições que cabem tanto num QR-Code estático quanto num dinâmico, mas se o PSP gerar um dinâmico, complementa as demais posições com algum dos caracteres válidos.

[renatofrota]

Me parece que o caso de uso em questão é de QR-Code dinâmico no aplicativo do PSP, e não na API. Então a escolha de TxID é feita pelo PSP, mesmo que ela use em sua composição uma string definida pelo cliente.

Por exemplo, o TxID perguntado pelo mobile pode ser sempre de 25 posições que cabem tanto num QR-Code estático quanto num dinâmico, mas se o PSP gerar um dinâmico, complementa as demais posições com algum dos caracteres válidos.

Bem observado. Obrigado, Rubens. Como não sou PSP fico toda hora enxergando as questões pelo ponto de vista de quem vai usar a API. Vou me policiar quanto a isso. :stuck_out_tongue_closed_eyes:

Nesse caso, a pesquisa por "Churrasco" vai virar algo como um LIKE 'Churrasco%' (ou até LIKE '%Churrasco%', se a busca quiser casar intencionalmente o termo pesquisado em qualquer ponto do campo, não apenas partindo do início). Realmente, não vejo isso ferindo a Regulamentação do Pix (novamente: meu comentário é apenas curioso / colaborativo).

[vivicupola]

Pessoal, obrigada pelos comentários. @rubenskuhl é exatamente este o caso de uso em questão. Não gostaríamos de deixar o controle da unicidade da informação (para efeito de conciliação de pagamentos) na responsabilidade do cliente.

[ninrod]

@vivicupola , boa tarde.

A resposta oficial é: "O PSP está livre para implementar esta questão específica do txid, no fluxo mobile, da maneira que achar melhor".

[vivicupola]

Obrigada @ninrod :)