bacen / pix-api-recebimentos

Definição da API de recebimentos PIX
130 stars 8 forks source link

QRCode TEXT e Múltiplos Pagamentos através de um mesmo QRCode Dinâmico #8

Closed llatsch closed 4 years ago

llatsch commented 4 years ago

Observando o Response do POST inicial, entendi que temos apenas um LINK "payloadURL" e não o QRCode TEXT padrão BRCode em sí. Como o lojista irá receber o QRCode e renderizá-lo para apresentação ao cliente pagador? Eles vão precisar montá-lo de acordo com o PAYLOAD da URL?

Outra pergunta, neste modelo, como faremos para iniciar vários pagamentos com um mesmo QRcode dinâmico conforme permitido na documentação abaixo?

https://www.bcb.gov.br/content/estabilidadefinanceira/pix/Regulamento_Pix/II_ManualdePadroesparaIniciacaodoPix-versao1.pdf "Admite-se, a critério do recebedor, que uma mesma URL seja reutilizada para vários pagamentos. A parte efetivamente dinâmica é o conteúdo acessado através da URL (o payload complementar, em formato JSON). Dessa forma, um mesmo QR Code dinâmico poderia ser utilizado para iniciar vários pagamentos com detalhes específicos diferentes, obtidos em diferentes acessos à mesma URL, variando de acordo com determinada lógica de negócio"

ninrod commented 4 years ago

Eles vão precisar montá-lo de acordo com o PAYLOAD da URL?

Sim

https://www.bcb.gov.br/content/estabilidadefinanceira/pix/Regulamento_Pix/II_ManualdePadroesparaIniciacaodoPix-versao1.pdf "Admite-se, a critério do recebedor, que uma mesma URL seja reutilizada para vários pagamentos. A parte efetivamente dinâmica é o conteúdo acessado através da URL (o payload complementar, em formato JSON). Dessa forma, um mesmo QR Code dinâmico poderia ser utilizado para iniciar vários pagamentos com detalhes específicos diferentes, obtidos em diferentes acessos à mesma URL, variando de acordo com determinada lógica de negócio"

Excelente pergunta. Há uma maneira de se fazer isso na API, mas está bem obscura. A versão 2.0.0 colocará em termos mais claros essa possibilidade.

fernandogodoy commented 4 years ago

A resposta da primeira pergunta me deixou confuso.

Dado que os PSPs são obrigados a gerar o qrcode text no padrão Brcode, além da Api de Recebimento. Porque não reutilizar o qrcode text já gerado pelo psp?

Dessa forma quem utiliza a Api de Recebimento já receberia o conteudo para geração delegando a responsabilidade ao PSP, bem como, teria menos complexidade envolvida na construção da integração com tal api.

ninrod commented 4 years ago

Prezado @fernandogodoy ,

Dado que os PSPs são obrigados a gerar o qrcode text no padrão Brcode, além da Api de Recebimento. Porque não reutilizar o qrcode text já gerado pelo psp? Dessa forma quem utiliza a Api de Recebimento já receberia o conteudo para geração delegando a responsabilidade ao PSP, bem como, teria menos complexidade envolvida na construção da integração com tal api.

Não entendi exatamente qual é a questão que você coloca. Poderia reformular?

llatsch commented 4 years ago

Somente para ter certeza, o que temos no Payload URL? Será exatamente o mesmo conteúdo do PAYLOAD URL do QRCode Dinâmico?

ninrod commented 4 years ago

Somente para ter certeza, o que temos no Payload URL? Será exatamente o mesmo conteúdo do PAYLOAD URL do QRCode Dinâmico?

@llatsch , o endpoint payloadURL, localizado no servidor do PSP recebedor, serve um JSON no formato JWT, assinado pelo PSP recebedor, retornado pelo PSP recebedor para o app do PSP pagador no momento que este app obtem a URL contida no QR Code dinâmico após realizado o "scan" do QR Code.

Esse endpoint, payloadURL, é público e não faz parte dos endpoints da API de recebimentos, embora alguns endpoints da API de recebimentos façam referência a esse endpoint.

ninrod commented 4 years ago

@fernandogodoy , vc está sugerindo retornar a string que seria utilizada para montar o QR Code, diretamente via API?

ninrod commented 4 years ago

Prezados, com a iminência da liberação da versão 2.0.0 e a atualização subsequente dos documentos de negócio que serão atualizados em consequência dessa liberação, vou tomar a liberdade de fechar essa issue. Obrigado por terem abordado as questões expostas aqui.