Hiperlink's para pagamentos #251
Comments
|
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! |
|
Já debatido aqui. |
|
O @ninrod vai ter que pinnar os tópicos onde isso já foi discutido... ;-) |
|
@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. |
|
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 |
|
@renatofrota eu também preferiria o Só uma dúvida sobre a UX: Ainda no caso do 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. |
|
@rubenskuhl sério? Achei que não poderiam, mas usei como um exemplo. |
Não existe um padrão. É uma propositura. Pode nem vingar. E já não existe
Não sei se entendi bem a questão. Eles acabaram de adotar o Bitcoin, por exemplo. Provavelmente vão registrar no app ao
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. |
|
@renatofrota entendi. |
|
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):
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. 😉 |
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. |
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 |
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! |
ninrod
added
funcionalidade-nova
|
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: |
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:
|
|
O app do NuBank tá associado a links do domínio 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: 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 É 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). |
|
Em que estágio está essa discussão? Estamos experimentando uma série de atritos com os pagamentos "copia e cola".
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:
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 |
|
Não dá para ser de cada banco, pois o e-commerce não sabe qual banco o cliente tem. Edit: mas seria legal o BACEN já registrar pix em https://git.gnunet.org/gana.git/diff/payto-payment-target-types/ . |
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. |
Por enquanto, sem notícias. Recomendo fazerem chegar essas questões de negócio ao DECEM. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Citando meu post anterior para retormar o foco dessa issue - hyperlinks Pix!. |
This comment has been minimized.
This comment has been minimized.
Eu acabei de abrir um NUP, acredito que já ajude. O número é o 18600.061629/2021-65. |
|
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. |
|
Acho que li todas as discussões, em todos os lugares que encontrei pesquisando por palavras-chave como 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 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? |
|
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. |
|
Excelente |
@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 ??? |
|
@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? |
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. |
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. |
|
@ninrod será que isso não vai ser possível? Aparentemente é algo simples para ser definido e regulado no arranjo. |
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:
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 =)
The text was updated successfully, but these errors were encountered: