Closed llatsch closed 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.
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.
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?
Somente para ter certeza, o que temos no Payload URL? Será exatamente o mesmo conteúdo do PAYLOAD URL do QRCode Dinâmico?
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.
@fernandogodoy , vc está sugerindo retornar a string que seria utilizada para montar o QR Code, diretamente via API?
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.
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"