ninrod
commented
3 years ago Dado que as APIs de Recebimento não cumprem essa necessidade (que convenhamos, tem um escopo bastante básico) nós, PSPs, poderíamos então oferecer uma API que cumpra com o objetivo final do usuário e retorne o LINK pro QRCode, já criado? Evitando assim que o usuário Recebedor precise montar o QRCode do lado dele?
@dncosta , boa tarde.
A renderização, ou, em outras palavras, a composição da string específica que pode ser mostrada como um QR Code está fora da esfera definida pela API Pix. Isso vale tanto para o QR Estático quanto para o QR Dinâmico.
Em outras palavras a "montagem" do BR Code pode ser realizada por qualquer elemento de software, inclusive APIs proprietárias.
Atualmente a API de Recebimentos retorna uma série de infomações a partir das quais o QRCode deve ser montado pelo Usuário Recebedor. Ou seja, ela não retorna um LINK com o QRCode já gerado. Partindo do principio que se trata de uma API de Recebimentos, ao meu ver faria sentido que ela incluisse em sua resposta tanto o LINK do QRCODE, como o LINK DE PAGAMENTO, discutido até algumas semanas atrás.
Dado que as APIs de Recebimento não cumprem essa necessidade (que convenhamos, tem um escopo bastante básico) nós, PSPs, poderíamos então oferecer uma API que cumpra com o objetivo final do usuário e retorne o LINK pro QRCode, já criado? Evitando assim que o usuário Recebedor precise montar o QRCode do lado dele?