Hiperlink's para pagamentos

[hiagodotme]

Boa tarde pessoal. Não sei se aqui é o local ideal para dar essa sugestão.

O PIX é moderno e já tá se popularizando, uma coisa que me incomodou bastante foi eu ter que "copiar" e "colar" o código da transação para fazer uma compra online.

Imagina que lindo o processo abaixo:

• Você entra no website pelo celular
• Faz a sua compra
• Após isso escolhe em "pagar com pix".
• Aparece duas opções (Clique para Pagar) ou (Copiar)
• O SO do celular mostra todos os apps que podem abrir o hiperlink.

Seria algo de simples implementação, bastaria os apps de bancos registrarem o hiperlink pix:CONTEUDO_DO_QRCODE ai quando clicar eu iria escolher qual banco utilizar. Claro que tem as exceções exemplo:

Ter o app de três instituições instalados e ter a chave registrada apenas em um deles, mas acredito que o próprio app poderia controlar isso.

Pensem com carinho, seria bem mais prático para todos =)

[felipesalomao]

Excelente sugestão. Vinha pensando exatamente nisso há um tempo.

O processo de compra no computador já é bem pratico, basta apontar a câmera do celular para código qr e pronto. Porém a forma como está implementado, a experiência em celulares (foco, já que representa mais de 80% do tráfego) está prejudicada. A pessoa tem que copiar código da transação e manualmente procurar e abrir app do banco para ir na opção pix, pagamento colar código. É um processo longo, e que nem todos sabem fazer, facilitaria demais um hyperlink padronizado, no qual só os apps compatíveis e aptos a pagar seriam mostrados como opções ao clicar no botão de fazer pagamento diretamente no checkout no site/app mobile. Irá agilizar e facilitar 100% a experiência de compra!

[renatofrota]

Já debatido aqui.

[rubenskuhl]

O @ninrod vai ter que pinnar os tópicos onde isso já foi discutido... ;-) Resumo: o plano original era usar PixLink, por exemplo pix.br/EMV . Mas isso não atendeu aos requisitos de segurança e competição do BACEN. As alternativas apontadas com protocolo e extensão de arquivo deram na mesma. Eu ainda acho que não haverá outra alternativa menos pior do que payto:pix (https://tools.ietf.org/html/rfc8905), e que o copia e cola tem as mesmas vulnerabilidades através de interceptação e alteração da área de transferência.

[hiagodotme]

@rubenskuhl eu acabei de ver a discussão, bacana que já tenham pensado em algo assim. O problema ref a segurança é válido, mas como dito por você nada impede que o mesmo ocorra com os meios atuais. É que realmente eu como usuário do PIX e desenvolvedor na hora que usei o recurso já pensei nos hiperlinks.

[renatofrota]

Eu concordo 100% com o @rubenskuhl.

Ou melhor, 99%. Pois acho que o uso da área de transferência é ainda mais vulnerável do que o uso do pix/payto.

Talvez 98%, já que é possível associar pix: (a RFC propõe payto: mas não é Standards em vigor) e eu preferiria pix:.

[hiagodotme]

@renatofrota eu também preferiria o pix: rss... Mas já que existe um padrão, melhor seguir ele né.

Só uma dúvida sobre a UX: Ainda no caso do payto: imagine ele sendo utilizado por um PayPal? Eles não fornecem conta corrente, então acredito eu que nem iriam implementar o PIX.

Acho estranho o app deles ser exibido junto aos apps de nossas instituições.

[rubenskuhl]

@renatofrota eu também preferiria o pix: rss... Mas já que existe um padrão, melhor seguir ele né.

Só uma dúvida sobre a UX: Ainda no caso do payto: imagine ele sendo utilizado por um PayPal? Eles não fornecem conta corrente, então acredito eu que nem iriam implementar o PIX.

Acho estranho o app deles ser exibido junto aos apps de nossas instituições.

Paypal é sim obrigado a implementar Pix. Eles tem mais de 4 milhões de contas transacionais, e toda instituição com mais de 500 mil contas é obrigada. Tem já ? Não. Já abri reclamação lá e RDR no BACEN por causa disso.

[hiagodotme]

@rubenskuhl sério? Achei que não poderiam, mas usei como um exemplo.

[renatofrota]

@renatofrota eu também preferiria o pix: rss... Mas já que existe um padrão, melhor seguir ele né.

Não existe um padrão. É uma propositura. Pode nem vingar.

E já não existe bitcoin: que se consolidou pelo uso? Só pra citar um exemplo (tem vários outros).

Só uma dúvida sobre a UX: Ainda no caso do payto: imagine ele sendo utilizado por um PayPal? Eles não fornecem conta corrente, então acredito eu que nem iriam implementar o PIX.

Não sei se entendi bem a questão. Eles acabaram de adotar o Bitcoin, por exemplo. Provavelmente vão registrar no app ao bitcoin:, se não o fizeram. E o mesmo fariam com payto: ou pix: (ou ambos) caso se consolidem.

Acho estranho o app deles ser exibidos junto aos apps das nossas instituições.

O PayPal oferece uma conta transacional, eles podem muito bem suportar Pix (pra receber e pra enviar). Não são apenas contas "correntes" que podem trabalhar com Pix. edit: não só podem como já deveriam estar aceitando, pelo que o @rubenskuhl acabou de mencionar acima.

[hiagodotme]

@renatofrota entendi.

[hiagodotme]

Bom pessoal, só queria trazer essa sugestão. Mas pelo que vi, já foi discutido. Obrigado a atenção e as explicações.

[renatofrota]

Bom pessoal, só queria trazer essa sugestão. Mas pelo que vi, já foi discutido. Obrigado a atenção e as explicações.

Acho pertinente. Acho que o #129 foi fechado pois estávamos prestes ao Go Live e em meio à definição do que seria suportado à ocasião.

Como o @ninrod falou lá mesmo (link):

Ponto interessante. Novamente, nada impede que o payto ou o pix sejam incorporados no roadmap.

Então, para o roadmap, essa issue é pertinente.

Eu só mencionei que foi discutido no passado para que você ficasse ciente de tudo "o quê" - especificamente - já foi discutido. Não quis dizer que essa issue deveria ser fechada. 😉

[rubenskuhl]

@rubenskuhl sério? Achei que não poderiam, mas usei como um exemplo.

E o PayPal alega que vai sim suportar. Só que ele já precisaria estar desde Outubro no DICT e desde Novembro no SPI... com o adiamento de multas eles conseguiram uns meses para terminar de integrar.

[renatofrota]

@rubenskuhl sério? Achei que não poderiam, mas usei como um exemplo.

O nível da sua surpresa tem certa relação com o tamanho do impacto do Pix na vida dos brasileiros. Mais uma razão para eu defender pix:. rsrs...

[felipesalomao]

Bom pessoal, só queria trazer essa sugestão. Mas pelo que vi, já foi discutido. Obrigado a atenção e as explicações.

Acho pertinente. Acho que o #129 foi fechado pois estávamos prestes ao Go Live e em meio à definição do que seria suportado à ocasião.

Como o @ninrod falou lá mesmo (link):

Ponto interessante. Novamente, nada impede que o payto ou o pix sejam incorporados no roadmap.

Então, para o roadmap, essa issue é pertinente.

Eu só mencionei que foi discutido no passado para que você ficasse ciente de tudo "o quê" - especificamente - já foi discutido. Não quis dizer que essa issue deveria ser fechada. 😉

Concordo total, até pq no tópico original estavam com receio de demorar para haver uma padronização e isso atrapalhar a adoção. Agora que passado a fase inicial, com milhares de apps já integrados. Realmente é muito Pertinente entrar no roadmap. É uma evolução de vital importância!

[katriellucas]

Nubank meio que está tentando, infelizmente só funciona de nubank para nubank, e quando você abre em um browser precisa copiar o código mas eu acredito que é um progresso comparado com os outros:

https://nubank.com.br/pagar/1fzqcg/nZKx87EkOT

[renatofrota]

Nubank meio que está tentando, infelizmente só funciona de nubank para nubank, e quando você abre em um browser precisa copiar o código mas eu acredito que é um progresso comparado com os outros:

https://nubank.com.br/pagar/1fzqcg/nZKx87EkOT

Isso aí já funciona pra pagar a partir de qualquer banco (que tenha implantando tudo direito).

E dá pra criar esse tipo de link de pagamento com ferramentas externas, também (ex: Pix.ae)

[katriellucas]

Nubank meio que está tentando, infelizmente só funciona de nubank para nubank, e quando você abre em um browser precisa copiar o código mas eu acredito que é um progresso comparado com os outros: https://nubank.com.br/pagar/1fzqcg/nZKx87EkOT

Isso aí já funciona pra pagar a partir de qualquer banco (que tenha implantando tudo direito).

E dá pra criar esse tipo de link de pagamento com ferramentas externas, também (ex: Pix.ae)

Não foi isso que eu quis dizer, observe, quando acessamos o link do nubank ou do pix.ae (não sabia da ferramenta, obrigado por apresentar) o link deveria abrir com todos bancos compatíveis, certo? Mas isso não acontece pq é apenas uma página na web, mas como tem https://nubank.com.br no link, o nubank (e os browsers) aparece como opção para o abrir o link, mesmo tendo outros bancos compatíveis com o pix.

No caso do pix.ae, só aparece os browsers pq é só isso que tem de compatibilidade. Sei que dá para mudar para "abrir links com esse app" mas isso é algo deveria ser implementado de forma nativa e não algo que o usuário precise mudar para funcionar.

Observe, ao abrir o link, sendo que tenho o Inter e Sofisa, todos bancos compatíveis:

[renatofrota]

O app do NuBank tá associado a links do domínio nubank.com.br - coisa que outros bancos não estão.

Qualquer banco pode fazer isso pra reconhecer links dos seus próprios domínios mas acho que não faria sentido catalogarem domínios de todos os outros bancos como compatíveis, visto que precisariam trabalhar no "parse" dos dados e as páginas podem ser modificadas, domínios podem ficar de fora - e o apps não são atualizados com tanta frequência, etc.

Esse tipo de interoperabilidade precisa ser implantado com algum domínio neutro (não mantido por um PSP particular), ex: pix.br ou com um url scheme do tipo payto: ou pix: e ter um formato padrão que todos deveriam seguir, como vem sendo discutido aqui.

O Pix.ae é similar a esse link do NuBank, mas é agnóstico em relação a qual PSP recebedor e pagador usam, só precisa eles seguirem a especificação do BACEN que já funcionaria (o que não é o caso do... cof, cof... Itaú).

Fica a dica aos desenvolvedores dos PSPs que queiram se integrar: o Pix.ae disponibiliza o BR Code no header x-pix-brcode.

$ curl -sIX GET https://pix.ae/renatofrota@gmail.com | grep x-pix-brcode
x-pix-brcode: 00020126550014br.gov.bcb.pix0121renatofrota@gmail.com0208[Pix.ae]5204000053039865802BR5903Pix6003Pix62070503***6304E92E

É só informar suporte a links do domínio pix.ae em seus apps e, quando o usuário clicar em um link, o app pode ler o BR Code desse header e tratar como uma inserção de "Pix Copia e Cola".

Se o cliente quiser escolher o app do PSP como padrão para abertura de links Pix.ae, melhor para o PSP (e o cliente tem opção de limpar/trocar a preferência a qualquer tempo nas configurações do dispositivo).

[hmaesta]

Em que estágio está essa discussão?

Estamos experimentando uma série de atritos com os pagamentos "copia e cola".

• O formato ainda é muito estranho ao usuário, que identifica o "amontado de caracteres" como um "código de erro" ou... golpe.
• Nos casos do código conter espaço, acontece do usuário acabar copiando somente a primeira parte, até o primeiro espaço.
• Há muitos bancos e cada um tem sua interface. Algumas mais fáceis e outras mais difíceis de encontrar a opção certa para realizar o pagamento. O time de suporte até consegue ajudar nos bancos mais populares, mas mesmo assim é um processo desgastante, que acaba frustrando o cliente final e acabamos perdendo a venda.
• Alguns usuários que já enviaram dinheiro para outra pessoa via Pix entendem que a única forma de pagamento é inserindo uma chave como telefone, CPF ou email. É difícil "ensinar" que para pagamentos de compras online o processo é ligeiramente diferente e com um código "abstrato".

Notei que há várias issues sobre o assunto, mas não parece haver uma resposta clara se o hiperlink padronizado verá a luz do dia. Há uma indicação de que haverá uma página para consultar "cobranças pendentes" dentro do aplicativo do banco – e, apesar de isso ajudar, ainda não me parece ser a solução mais fluida, ainda mais nos casos do nome fantasia ser completamente diferente da razão social.

Entendo a dificuldade técnica de fazer um link universal, mas não existe possibilidade de cada banco ter sua própria solução de forma temporária usando URL Scheme/Universal Links?

Por exemplo:

• https://bb.com.br/pix?code=0002012...
• itau://pix?code=0002012...

A intenção aqui não é ter uma página centralizada do BC com todos os bancos, mas sim criar uma recomendação às instituições para que elas ofereçam esse link com o intuito de fidelizar clientes pela comodidade – ou seja, exibir ou não os botões –e em qual ordem– fica a critério do lojista em sua página de pagamento.

Há o lado negativo de que seria necessário mostrar um botão para cada banco –ou um <select>– e aguardar interação do usuário para leva-lo até o link correspondente, mas, ainda assim, me parece ser "menos pior" do que perder vendas simplesmente pela dificuldade de UX no "copia e cola".

[rubenskuhl]

Não dá para ser de cada banco, pois o e-commerce não sabe qual banco o cliente tem. https://tools.ietf.org/html/rfc8905 ainda me parece o caminho, ou restrito a *.pix.br ou não.

Edit: mas seria legal o BACEN já registrar pix em https://git.gnunet.org/gana.git/diff/payto-payment-target-types/ .

[rubenskuhl]

Notei que há várias issues sobre o assunto, mas não parece haver uma resposta clara se o hiperlink padronizado verá a luz do dia. Há uma indicação de que haverá uma página para consultar "cobranças pendentes" dentro do aplicativo do banco – e, apesar de isso ajudar,

ainda não me parece ser a solução mais fluida, ainda mais nos casos do nome fantasia ser completamente diferente da razão social.

Isso está na agenda evolutiva como Pix débito, discussão no Q4 deste ano e implantação só em 2022. Meio longe. Mas sobre razão social x nome fantasia, a norma é clara da preferência ao nome fantasia. Falta só o BACEN cobrar isso mais decisivamente dos bancos.

[ninrod]

Em que estágio está essa discussão?

Por enquanto, sem notícias. Recomendo fazerem chegar essas questões de negócio ao DECEM.

[joelemanoel]

O app do NuBank tá associado a links do domínio nubank.com.br - coisa que outros bancos não estão. Qualquer banco pode fazer isso pra reconhecer links dos seus próprios domínios mas acho que não faria sentido catalogarem domínios de todos os outros bancos como compatíveis, visto que precisariam trabalhar no "parse" dos dados e as páginas podem ser modificadas, domínios podem ficar de fora - e o apps não são atualizados com tanta frequência, etc. Esse tipo de interoperabilidade precisa ser implantado com algum domínio neutro (não mantido por um PSP particular), ex: pix.br ou com um url scheme do tipo payto: ou pix: e ter um formato padrão que todos deveriam seguir, como vem sendo discutido aqui. O Pix.ae é similar a esse link do NuBank, mas é agnóstico em relação a qual PSP recebedor e pagador usam, só precisa eles seguirem a especificação do BACEN que já funcionaria (o que não é o caso do... cof, cof... Itaú). Fica a dica aos desenvolvedores dos PSPs que queiram se integrar: o Pix.ae disponibiliza o BR Code no header x-pix-brcode.

$ curl -sIX GET https://pix.ae/renatofrota@gmail.com | grep x-pix-brcode
x-pix-brcode: 00020126550014br.gov.bcb.pix0121renatofrota@gmail.com0208[Pix.ae]5204000053039865802BR5903Pix6003Pix62070503***6304E92E

É só informar suporte a links do domínio pix.ae em seus apps e, quando o usuário clicar em um link, o app pode ler o BR Code desse header e tratar como uma inserção de "Pix Copia e Cola". Se o cliente quiser escolher o app do PSP como padrão para abertura de links Pix.ae, melhor para o PSP (e o cliente tem opção de limpar/trocar a preferência a qualquer tempo nas configurações do dispositivo).

Baseado nesse projeto pix.ae criei esse em python, gratuito e open-source se me permitem o link é:

https://github.com/cleitonleonel/pypix.git # projeto python puro

https://github.com/cleitonleonel/pix-code.git # projeto web python

https://pix-code.herokuapp.com/qrcode # deploy heroku

Discordo do que você fez, o @renatofrota é o idealizador do Pix.ae e simplesmente copiar um produto assim pra mim não faz sentido, creio que no mínimo deveria ter solicitado ao mesmo, já que como falado anteriormente é um produto.

Edit: Se era a necessidade de uma API o próprio pix.ae já dispõe de uma API para ser consumida só verificar lá em "Funcionalidades" na lateral...

[renatofrota]

Pensei que o projeto fechado era apenas o backend deles, porque o frontend está visível a qualquer um, como eu disse apenas fiz algo "baseado" no frontend deles, apenas para fins didáticos...já tinha um projeto rodando desde 2020 pypix servindo só o backend em python, só subi no git com esse frontend, porque achei legal compartilhar...mas já vou deletando aqui...obrigado pelo toque...

@cleitonleonel , não precisa deletar. Como você falou, você só fez algo "baseado" no frontend do Pix.ae (é o "mal" do HTML e CSS, dá pra copiar sem pedir autorização, fazer o quê). Não que eu não fosse dar autorização se me pedisse, de qualquer forma. Não tem nada de mais haver outros projetos similares. Basta estudar a documentação do Pix (ou juntar peças de backend e frontend por aí). Você só facilitou ainda mais pra quem quiser fazer algo parecido. Só transforme a menção ao Pix.ae no readme em backlink e tudo certo. O mundo segue girando.

Só estou rindo desse "baseado" entre aspas.

[joelemanoel]

@cleitonleonel discordo do seu ponto de que "não são totalmente iguais" garanto que 99% do código é igual, desde validações e etc. De qualquer forma é uma recomendação do futuro para sempre pedir autorização.

[renatofrota]

@cleitonleonel discordo do seu ponto de que "não são totalmente iguais" garanto que 99% do código é igual, desde validações e etc. De qualquer forma é uma recomendação do futuro para sempre pedir autorização.

@joelemanoel , não precisa pegar no pé do cara. kkk 😝

da mesma forma deixarei lá no git em letras garrafais a menção a seu excelente projeto, não me passou pela cabeça atrapalhar teu trabalho, apenas contribuir, pois não vi aqui códigos em python...

@cleitonleonel sim, eu compreendo. Não precisa colocar nada em letras garrafais, meu caro. Eu só pedi um backlink, só isso. E eu também não disse em momento nenhum que está atrapalhando. Relaxa 😁

[renatofrota]

O app do NuBank tá associado a links do domínio nubank.com.br - coisa que outros bancos não estão.

Qualquer banco pode fazer isso pra reconhecer links dos seus próprios domínios mas acho que não faria sentido catalogarem domínios de todos os outros bancos como compatíveis, visto que precisariam trabalhar no "parse" dos dados e as páginas podem ser modificadas, domínios podem ficar de fora - e o apps não são atualizados com tanta frequência, etc.

Esse tipo de interoperabilidade precisa ser implantado com algum domínio neutro (não mantido por um PSP particular), ex: pix.br ou com um url scheme do tipo payto: ou pix: e ter um formato padrão que todos deveriam seguir, como vem sendo discutido aqui.

O Pix.ae é similar a esse link do NuBank, mas é agnóstico em relação a qual PSP recebedor e pagador usam, só precisa eles seguirem a especificação do BACEN que já funcionaria (o que não é o caso do... cof, cof... Itaú).

Fica a dica aos desenvolvedores dos PSPs que queiram se integrar: o Pix.ae disponibiliza o BR Code no header x-pix-brcode.

$ curl -sIX GET https://pix.ae/renatofrota@gmail.com | grep x-pix-brcode
x-pix-brcode: 00020126550014br.gov.bcb.pix0121renatofrota@gmail.com0208[Pix.ae]5204000053039865802BR5903Pix6003Pix62070503***6304E92E

É só informar suporte a links do domínio pix.ae em seus apps e, quando o usuário clicar em um link, o app pode ler o BR Code desse header e tratar como uma inserção de "Pix Copia e Cola".

Se o cliente quiser escolher o app do PSP como padrão para abertura de links Pix.ae, melhor para o PSP (e o cliente tem opção de limpar/trocar a preferência a qualquer tempo nas configurações do dispositivo).

Citando meu post anterior para retormar o foco dessa issue - hyperlinks Pix!.

[hmaesta]

@ninrod Poderia esconder os comentários acima? Não acrescentam na discussão dessa issue.

[hiagodotme]

Em que estágio está essa discussão?

Por enquanto, sem notícias. Recomendo fazerem chegar essas questões de negócio ao DECEM.

Eu acabei de abrir um NUP, acredito que já ajude. O número é o 18600.061629/2021-65.

[diegoleme]

Tivemos alguma evolução aqui?

[rubenskuhl]

Tivemos alguma evolução aqui?

Nada disso reapareceu na agenda evolutiva... então imagina-se que não. E mesmo a agenda evolutiva prevista para 2022 está mais lenta devido à greve de funcionários do BACEN.

[leonelsr]

Acho que li todas as discussões, em todos os lugares que encontrei pesquisando por palavras-chave como pix URI, pix URL, pix URI scheme, link pix etc.

E essa daqui realmente parece ser a discussão mais completa (ainda que concisa) e bem direcionada sobre o assunto.

Ainda assim, 2 anos e 4 meses passados, ainda não temos nada melhor que o "copia e cola" para transações de apps e web apps/sites??? Ou deixei passar alguma coisa?

Como usuário e também programador full stack, me parece muito óbvio que o melhor caminho a ser seguido é esse aqui: a criação (por parte do Bacen) de um URI scheme estilo pix://... (ou até adoção do payto://pix/...). Isso pode até mesmo funcionar com o mesmo conteúdo do "copia e cola"!

Assim cada app de pagamentos que suporte pix, pode subscrever-se ao scheme junto ao SO (ou até browser, no caso do desktop), e pronto!

Apesar de ser tão simples, parecer tão óbvio, por que será que ainda não houve progresso?

[hiagodotme]

Boa tarde @leonelsr, pelo que notei agora existe a opção de utilizar o OpenFinance para iniciar o pagamento PIX. O efeito seria o mesmo, sua aplicação redireciona o usuário para o banco dele e ele só confirma.

A Efi já tem documentações para se integrar, o único ponto ruim é que não consegue fazer isso com um PIX estático. Então fica dependente de utilizar um PSP pra iniciar o procedimento.

Ainda assim, acho válido estudarem o uso de hiperlinks para PIX estáticos e dinâmicos.

[rubenskuhl]

Boa tarde @leonelsr, pelo que notei agora existe a opção de utilizar o OpenFinance para iniciar o pagamento PIX. O efeito seria o mesmo, sua aplicação redireciona o usuário para o banco dele e ele só confirma.

A Efi já tem documentações para se integrar, o único ponto ruim é que não consegue fazer isso com um PIX estático. Então fica dependente de utilizar um PSP pra iniciar o procedimento.

Ainda assim, acho válido estudarem o uso de hiperlinks para PIX estáticos e dinâmicos.

No OpenFinance já tinha transferência Pix, e agora já tem pagamento de QR-Code. Mas uma transferência Pix e um QR-Code estático são bem similares em que nenhum dos dois precisa de API Pix no lado recebedor, apenas API OpenFinance no Iniciador de Pagamento.

E sim, o OpenFinance diminuiu a premência desse recurso... que eu ainda vejo utilidade e acho que um link padrão RFC8905 faria sentido. Mas com OF já dá para ter uma experiência de pagamento Pix mais fluida em mobile.

[andreptcosta]

Excelente

[hiagodotme]

E sim, o OpenFinance diminuiu a premência desse recurso... que eu ainda vejo utilidade e acho que um link padrão RFC8905 faria sentido. Mas com OF já dá para ter uma experiência de pagamento Pix mais fluida em mobile.

@rubenskuhl sim, com certeza. O QrCode estático é muito útil, mesmo sem a confirmação automática e o OF obriga o fornecedor a integrar-se com uma IP. Atualmente existem alguns plugins para o Wordpress que implementam processos para empresas menores que não desejam aderir a API PIX com PSP's pois tem PIX gratuito em seu IP. Então esses plugins geram o QRCode estático e fornecem um ambiente para pessoa fazer upload do comprovante. O RFC8905 ajudaria e muito pequenos comércios que não dependem da confirmação automática, porém que desejam fornecer uma boa experiência ao seu cliente.

[cleitonleonel]

E sim, o OpenFinance diminuiu a premência desse recurso... que eu ainda vejo utilidade e acho que um link padrão RFC8905 faria sentido. Mas com OF já dá para ter uma experiência de pagamento Pix mais fluida em mobile.

@rubenskuhl sim, com certeza. O QrCode estático é muito útil, mesmo sem a confirmação automática e o OF obriga o fornecedor a integrar-se com uma IP. Atualmente existem alguns plugins para o Wordpress que implementam processos para empresas menores que não desejam aderir a API PIX com PSP's pois tem PIX gratuito em seu IP. Então esses plugins geram o QRCode estático e fornecem um ambiente para pessoa fazer upload do comprovante. O RFC8905 ajudaria e muito pequenos comércios que não dependem da confirmação automática, porém que desejam fornecer uma boa experiência ao seu cliente.

A API Pix do mercado pago não seria interessante MercadoPago Pix ???

[hiagodotme]

@cleitonleonel essa issue como um todo, trata do caso de abrir o aplicativo do banco com o conteúdo de um BRCode. Seja ele estático ou dinâmico, a questão de confirmação já é um problema resolvido pelas próprias definições do PIX. Com a API Pix.

Para o PIX dinâmico eu uso e indico a Efí, nunca tive problemas com eles.

[cleitonleonel]

@cleitonleonel essa issue como um todo, trata do caso de abrir o aplicativo do banco com o conteúdo de um BRCode. Seja ele estático ou dinâmico, a questão de confirmação já é um problema resolvido pelas próprias definições do PIX. Com a API Pix.

Para o PIX dinâmico eu uso e indico a Efí, nunca tive problemas com eles.

Ah claro !!! a referência era sobre "plugins geram o QRCode estático e fornecem um ambiente para pessoa fazer upload do comprovante", e sobre utilizar o OpenFinance para iniciar o pagamento PIX parece ser a única opção até agora né, como disse @leonelsr Apesar de ser tão simples, parecer tão óbvio, por que será que ainda não houve progresso?

[rubenskuhl]

E sim, o OpenFinance diminuiu a premência desse recurso... que eu ainda vejo utilidade e acho que um link padrão RFC8905 faria sentido. Mas com OF já dá para ter uma experiência de pagamento Pix mais fluida em mobile.

@rubenskuhl sim, com certeza. O QrCode estático é muito útil, mesmo sem a confirmação automática e o OF obriga o fornecedor a integrar-se com uma IP. Atualmente existem alguns plugins para o Wordpress que implementam processos para empresas menores que não desejam aderir a API PIX com PSP's pois tem PIX gratuito em seu IP. Então esses plugins geram o QRCode estático e fornecem um ambiente para pessoa fazer upload do comprovante. O RFC8905 ajudaria e muito pequenos comércios que não dependem da confirmação automática, porém que desejam fornecer uma boa experiência ao seu cliente.

A API Pix do mercado pago não seria interessante MercadoPago Pix ???

A API Pix do Mercado Pago não segue o padrão do BACEN, por isso apesar de listada em #76 , é na seção de PSPs não aderentes.

[rubenskuhl]

@cleitonleonel essa issue como um todo, trata do caso de abrir o aplicativo do banco com o conteúdo de um BRCode. Seja ele estático ou dinâmico, a questão de confirmação já é um problema resolvido pelas próprias definições do PIX. Com a API Pix. Para o PIX dinâmico eu uso e indico a Efí, nunca tive problemas com eles.

Ah claro !!! a referência era sobre "plugins geram o QRCode estático e fornecem um ambiente para pessoa fazer upload do comprovante", e sobre utilizar o OpenFinance para iniciar o pagamento PIX parece ser a única opção até agora né, como disse @leonelsr Apesar de ser tão simples, parecer tão óbvio, por que será que ainda não houve progresso?

O comprovante é um objeto não padronizado emitido pelo PSP, focado em consumo "humano" pelos clientes do PSP... mas o QR-Code estático permite sim sinalização de webhook da API Pix, bastando que o QR-Code tenha um txid.

[hiagodotme]

@ninrod será que isso não vai ser possível? Aparentemente é algo simples para ser definido e regulado no arranjo.