[PIX Link] - Contribuições técnicas #129
Comments
@felipecn, estamos interessados nesse elemento que você pontuou. Você poderia citar documentação, se possível, oficial da Apple, que confirme esse entendimento? |
|
Há pouca documentação oficial sobre esse ponto, mas em Support Universal Links, há esse trecho
Assim, como o path de todo PIX Link será o mesmo para cada PSP, acho que o iOS usará a ordem no apple-app-site-association para definir qual aplicativo abrir. |
|
Caro @felipecn , apenas para ficar mais claro. Se o Bacen servir um {
"applinks": {
"apps": [],
"details": [
{
"appID": "APP1.com.example",
"paths": [ "qr/"]
},
{
"appID": "APP2.com.example",
"paths": [ "qr/" ]
}
]
}
}Seu entendimento é que o iOS vai abrir a APP1 diretamente, sem permitir que o usuário escolha o APP (assim como acontece com um PDF, por exemplo?) |
|
Exato. Na maioria dos casos o app é aberto automaticamente. Em alguns casos, especialmente quando há um redirect, é exibido um prompt apenas para confirmar se deve direcionar para outro app.
|
|
Certo, e você acredita que o android apresenta um comportamento diferente, que seria o de oferecer ao usuário a possibilidade de escolher o aplicativo? |
|
Eu tinha praticamente certeza que sim, mas estava pensando na experiência de deep links. É falado sobre múltiplos apps associados à paths diferentes, mas não o comportamento de múltiplos apps no mesmo path. |
Sim, é bem difícil obter informações claras sobre esse caso de uso específico nas documentações oficiais. |
Esse trecho indica que o Android trabalharia da maneira como pensávamos, mas de maneira nenhuma deixa clara a experiência do usuário no sentido de poder escolher o app. |
|
@oximer, @felipecn e demais devs que eventualmente cheguem nessa issue, gostaríamos de entender exatamente qual é o comportamento do iOS ao se utilizar universal links. Como exemplo, suponha que o BCB sirva o seguinte arquivo AASA (apple-app-site-association) file em pix.bcb.gov.br/.well-known/apple-app-site-association: {
"applinks": {
"apps": [],
"details": [
{
"appID": "APP1.com.example",
"paths": [ "qr/"]
},
{
"appID": "APP2.com.example",
"paths": [ "qr/" ]
},
{
"appID": "APP3.com.example",
"paths": [ "qr/" ]
}
]
}
}Temos as seguintes perguntas:
|
ninrod
changed the title
Entendo que esse problema é crítico dado que impediria isonomia entre os bancos e fintechs. |
|
https://developer.apple.com/videos/play/wwdc2020/10146/ e https://developer.apple.com/videos/play/wwdc2020/10098/ são relevantes para este tema. |
|
@tfalencar assisti ao conteúdo. Ambos os vídeos são legais, mas não respondem a algumas das questões levantadas. @felipecn essa experiencia de redirect que você mostro no caso do submarino acontece em um muitos casos por causa de analytics. Muitas empresas contratam soluções de marketing e querem fazer tracking da conversão dos links para calcular CAC e ROI de campanhas. Como eu disse redirect pode ser um caminho, prejudicaríamos a experiencia em troca de isonomia. Alguma outra alternativa? |
|
Pessoal estive pensando que o modelo atual de iniciação não permite o pagamento por link no mundo WEB.
Se eu enviar um link de cobrança por email para você, se você tiver no desktop trabalhando, você não consegue pagar sem utilizar um celular. Esse cenário é muito ruim principalmente para PJs. Acredito que a alternativa para esse caso seja realmente o BACEN no site pix.bcb.gov.br criar uma estrutura de redirecionando para o internet banking dos player cadastrados no sistema. O usuário salvaria sua preferência e o BACEN faria o redirect. O BACEN teria que manter um banco de dados com CHAVE/VALOR com o endereço/domínio de internet banking de cada banco/fintech no país. Essa solução trataria até mesmo o problema do PIX link no iOS descrito nessa issue. Evidentemente a usabilidade no mundo iOS ficaria um levemente pior que a experiência no Android. Nesse primeiro momento, o BACEN nem precisaria criar um sistema complexo de login ou identificação. Me preocupa essa indefinição a poucos dias do lançamento dado que essa questão é bastante estrutural. |
|
@oximer , essa situação no desktop está sendo endereçada. Devem sair definições sobre essa questão nas próximas versões do manual de UX. A respeito da questão de isonomia envolvendo links, também está sendo endereçada. Por isso estou deixando a issue em aberto. |
|
Tem previsão de data para essa nova versão? |
|
Não posso relatar nada oficial quanto a isso, mas posso adiantar que deve sair em breve. Já se encontra em estágio de revisão. |
|
@ninrod não seria legal já trazer para discutir na comunidade? |
|
@oximer , nesse sentido, será exposta uma versão para consulta aos participantes em que o mercado terá tempo para apontar problemas e enviar feedbacks, como de praxe. |
|
@ninrod a especificação final do PIX sai no dia 14 de agosto né? |
|
Pessoal, eu gostaria de agradecer por vocês terem levantado essa issue. Ela chegou até os mais altos níveis no BCB e foi seriamente discutida. Entendemos a preocupação com o prazo e isso será levado em consideração. Muito em breve o mercado será informado quanto a providências nesse contexto. |
|
Depois do relatório final ficamos sem a opção de pagamento por link até sentarmos e pensar em uma maneira de tratar esse bug apresentado. É isso? Me coloco a disposição para pensarmos uma solução para o problema. |
|
@oximer , exatamente, o Banco central optou por não apresentar essa funcionalidade no momento devido, em parte, aos problemas apresentados na presente issue. Obrigado a todos que contribuiram aqui. |
|
Pessoal, li essa discussão a partir de um tweet. @ninrod Uma alternativa possível seriam file-types, dado que ambos os OSs oferecem seletores de apps para abertura de arquivos de um mimetype específico e mais de um app pode se registrar para fazer isso. Assim, arquivos .pixtransaction ou qualquer extensão que quiserem podem ser utilizados para esse fim. |
|
@objectivecosta um extensão nova poderia gerar varios problemas, pois não é comum, servidores e-mails poderia considerar esse arquivo como um virus e a visualização desse arquivo no whatsapp também não teria thumbnail. |
Servidores de e-mail já fazem filtros por URLs, então o mesmo poderia ser dito de URLs. Quanto a thumbnail no WhatsApp, acho que isso é um problema que o WhatsApp deveria/não deveria consertar de acordo com eles... |
|
Um solução poderia ser o SDK feito pelo bacen onde todos os PSP implementariam e nele teria a listagem de todos bancos e os respectivos schemas para abertura de deeplink. Então seria um tela comum em todos os Apps que apenas faria routing para o App escolhido, outro ponto é que possivel fazer caching das listas de PSP ficando uma experiencia melhor que abrir uma pagina web. |
|
SDK esbarraria na tecnologia Webapp e na experiência. A idéia de redirect para url-schemes específicos por banco com caching da opção salva com é uma opção. Na live ontem falaram em compartilhar o QRCode como arquivo PDF para ser aberto pelos aplicativos. Temos um problema complexo dado a limitação das plataformas. |
Está prevista a obrigatoriedade (ou autorizada a disponibilização pelos PSPs) de suporte à leitura de QR Codes a partir de uma imagem salva no dispositivo ou da área de transferência? Assim os usuários poderiam copiar a imagem do QR Code ou mesmo "tirar um print da tela" e depois abrir essa imagem (ou colar a imagem QR) com o app para enviar um Pix (adicionalmente à possibilidade já prevista de copiar a string do QR Code)? Pensei nisso hoje ao fazer um pagamento de boleto. Copiei a linha digitável e o app do banco reconheceu automaticamente que o conteúdo da área de transferência era uma LD de boleto, sugerindo o pagamento do mesmo. |
|
bom dia @renatofrota ,
Está prevista sim a obrigatoriedade de implementação, por parte dos PSPs pagadores, da funcionalidade "Pix Copia e Cola". Que seria justamente algo como "a linha digitável". O que é copiado é a string do BR Code. |
bom dia, @ninrod Pois então, na mensagem acima eu citei isso:
Uma imagem do QR Code, poderia ser lida em formato de arquivo (ou da área de transferência) pela mesma lib que avalia a imagem capturada pela câmera do dispositivo. É até relativamente simples fazer com que a string do QR Code seja copiada para a área de transferência com um mero clique, em se tratando dos navegadores mobile (só um comandinho JS e pronto). Mas poder ler diretamente uma imagem em formato de QR Code facilitaria, por exemplo, o pagamento de QR Codes enviados por aplicativos de mensagem ou por e-mail ("mídias" onde a string do QR Code em formato texto vão, muito provavelmente, se quebrar, especialmente quando esta contiver os |
@renatofrota , entendo que este fluxo já estaria endereçado agora para o go live; é assim que funcionaria, bastando, é claro, que os aplicativos em questão implementem esta capacidade de "copiar a string do QR para a área de transferência". Exemplo:
|
Realmente, faz bastante sentido que os aplicativos passem a oferecer a possibilidade de copiar o conteúdo de um QR. Já demorou muito pra isso acontecer, na verdade. Obrigado. |
A questão de linkificação é de Universal Acceptance, problema que foi enfrentado também no programa de novos gTLDs (vide https://uasg.tech/). Como há outros meios de pagamento usando, a tendência é isso se resolver graças a esses outros ao longo do tempo. Mas isso vem depois de que já está sendo usado, se colocar como condicionante, nunca será adotado por plataformas. Por exemplo, se fosse adotado algo como "pix://", ia levar algum tempo até ver isso linkificado... o payto pode ter esse caminho mais curto, mas pela data da RFC ele acabou de ser iniciado. |
Ponto interessante. Novamente, nada impede que o |
Dada a RFC, sugiro o payto mesmo, inclusive colocando o pix como meio de pagamento no IANA registry. A RFC tem apenas a lista inicial do IANA registry de meios de pagamento. |
O Banco Inter tá de olho aqui e implantou minha sugestão de ler imagem salva na galeria e detectar QR Code na imagem. Por outro lado... foi um dos poucos que não implantou o envio de Pix via chave aleatória (que era um método não exigido pelo manual de UX, mas achei relaxo... é basicamente ctrl+c ctrl+v dos demais métodos de envio via chave, muito mais fácil do que implantar a leitura de imagem da galeria). |
Gostei muito da sugestão do @rubenskuhl extender um RFC é dos caminhos mais adeguados na minha opnião Também gosto do padrão HTTP, seguindo dominio do Banco Central |
|
Url-scheme payto://pix/ seria perfeito. Na minha humilde opinião, seria só o BCB definir o padrão e os apps de banco iriam correr para implementar. se a pessoa tiver mais de um banco, tem de ter o cuidado para não deixar como default. Cópia e Cola em celular alternando aplicativo é nível hard para muitas pessoas. Estou implementando aqui na minha plataforma de telemedicina, e sempre nossa preocupação é facilitar a interface para pessoas mais velhas/humildes. Estou acompanhando essa discussão agora. |
|
Eu tenho a sensação de que o mercado e o BC estão apostando no ITP (Iniciador de Transação de Pagamento) para reduzir a necessidade do Copia e Cola, e por isso teriam deixado o PixLink no fundo da pilha do backlog... porque o app link seria do aplicativo do ITP (ex: Mercado Livre), e a conexão via OpenBanking garantiria que foi um ITP autorizado que fez um redirecionamento para o site do banco (onde a senha da conta confirma a transação). Eu gosto mais do payto://pix/, pq é mais Web "raiz"... mas vamos ver no que vai dar o ITP para que o caso de uso possa ser reavaliado. |
|
ITP é o típico "para quê simplificar se dá pra complicar?". payto://pix é
uma solução infinitamente superior.
Em ter, 7 de jun de 2022 22:41, Rubens Kuhl ***@***.***>
escreveu:
… Eu tenho a sensação de que o mercado e o BC estão apostando no ITP
(Iniciador de Transação de Pagamento) para reduzir a necessidade do Copia e
Cola, e por isso teriam deixado o PixLink no fundo da pilha do backlog...
porque o app link seria do aplicativo do ITP (ex: Mercado Livre), e a
conexão via OpenBanking garantiria que foi um ITP autorizado que fez um
redirecionamento para o site do banco (onde a senha da conta confirma a
transação).
Eu gosto mais do payto://pix/, pq é mais Web "raiz"... mas vamos ver no
que vai dar o ITP para que o caso de uso possa ser reavaliado.
—
Reply to this email directly, view it on GitHub
<#129 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAZ2XSV4VD26NI74DDR6KB3VN723PANCNFSM4S7NGEIQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Não entendo muito disso (só li essa thread por alto), mas se o problema é qualquer app poder abrir o link e a intenção é permitir só apps autorizados pelo BCB, não seria só quem gerar o link criptografar a informação usando algum tipo de chave pública do BCB, de modo que só os apps permitidos conseguem de alguma forma descriptografar e entender a informação contida no link? Ex.: |
|
O problema é que não é garantido que o usuário possa escolher o PSP para efetuar o pagamento, seja com app links ou com o payto:// No iOS certamente não pode, e no Android depende de inúmeros fatores (versão do OS, customizações da fabricante etc) |
Se a questão é integridade e não sigilo, poderia ser usada assinatura ao invés de criptografia. Mas o problema dessa idéia é que tanto os merchants quanto os PSPs precisariam de uma API exposta diretamente pelo Banco Central para geração e consumo dos links payto://pix, o que parece não ser o modelo desejado pelo BACEN. |
@rubenskuhl Usando chaves assimétricas, não precisaria de API para geração. Só precisaria saber a chave pública, que não é algo que muda o tempo todo. Ela seria pública mesmo, qualquer um poderia ver na especificação. E imaginei que a criptografia é necessária, pois um app fraudulento que interceptasse o link poderia alterar o recebedor e gerar outro link válido, exatamente por a chave ser pública. Mas como disse, não entendo muito disso e não sei se ajudaria muito a dificultar fraudes - talvez só ele interceptar o link já seja um problema de qualquer forma. |
Considerando que Android tem a maior fatia de mercado (~85.35%) no Brasil, que versões novas do Android são bem mais comuns que antigas (além de que nem todo mundo se encaixa no caso de mais de um PSP), será que requerer o "app redirecionador central" apenas nesses casos não seria uma solução aceitável?
O link vai pra store se ele já não estiver instalado; se está (e não for o padrão) redireciona para ele. Se for o padrão (ex. parâmetro no payto link diz que veio por redirecionamento) não precisa mostrar esse texto. |
Mesmo com chave assimétrica, para gerar algo digitalmente assinado precisa da chave privada. E a interceptação do link depende apenas do método (payto: ou pix:) não depende de nada do conteúdo. |
O BACEN já gongou essa idéia de app central dele. Tem tanto no histórico deste issue quanto nas apresentações do Fórum Pix. |
A intenção não era assinar digitalmente, apenas proteger a info dentro do link de outros apps não reconhecidos pelo BCB. Ao criptografar com a chave pública, apenas a privada pode descriptografar. Apenas os apps PSP reconhecidos poderiam chamar a API do BCB para descriptografar no caso (isso seria só para obter os dados para a transferência, não para realizar, claro).
Sei. Por isso acho que seria mesmo um problema quanto a fraudes.
Isso inclui a solução de link https para um domínio oficial do BCB que redireciona? Me parece a solução que faz mais sentido. |
https://pt.wikipedia.org/wiki/Criptografia_de_chave_p%C3%BAblica
O que iria mais para o lado de não ter PixLink nenhum, que foi a decisão do BACEN até o momento.
Não, essa eu não lembro de já ter sido gongada. Não significa porém que seja bem-vista, apenas que não me recordo de objeção clara. Mas agora imagine o necessário para fazer isso: sabendo o CPF do pagador, o BACEN precisaria fazer pesquisa reversa na base do Registrato para mostrar apenas as instituições onde o pagador tem conta, aleatorizar a ordem e gerar os links para os respectivos apps. Ou então mostrar uma lista de 800 instituições para todo mundo... |
|
Pois é, no próprio link da Wikipédia faz essa distinção que eu falei; eu me referia ao 1o uso e não ao 2o:
Mas, enfim.
Sim, eu penso que seria OK carregar todas as 800 instituições, porém mostrar só uma barrinha pesquisável localmente, e, como já foi sugerido acima, salvar apenas em cache local a(s) escolha(s) do usuário. Basicamente tudo feito no frontend mesmo, sem salvar ou processar nada no backend. Daria até pra permitir o usuário reordenar como quisesse. |
Mas independente de encriptação ou assinatura, pense quem tem a custódia da chave privada e como ela precisaria ser usada, para ver pq isso não dá certo.
Aí necessariamente a apresentação precisaria ser em ordem alfabética, o que quebraria um requisito que o BACEN já comentou sobre o processo de não privilegiar um banco em detrimento de outro. Aí o passo seguinte é alguém abrir o AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA Banco. |
|
É meio discutível essa questão de que aparecer primeiro numa lista que é alfabética seria um privilégio... |
|
Quanto menos esforço o usuário precisa pra escolher uma instituição, maior é a probabilidade dela ser escolhida. |
Quando eu disse "mostrar só uma barrinha pesquisável" eu quis dizer que nenhum resultado apareceria até que o usuário comece a pesquisar. Quando começar a digitar, aí sim lista em uma ordem qualquer, pode até ser alfabética. Já vi várias UX fazendo isso, é normal. Pense "autocompletar tipo o da barra de pesquisa do Google". Se o usuário quiser listar todas (sem digitar nada) em ordem alfabética ou outra ordem qualquer, não tem problema botar um botão pra isso também. Mas não haveria privilégio porque nenhum aparece por padrão, a não ser a lista dos que o user já escolheu anteriormente, salvo em cookie.
Se isso foi gongado, não importa.
|
Nesse caso o efeito de ordem alfabética, apesar de existente, é bem menor. Se menor o suficiente para o BACEN, só o BACEN pode dizer... mas já é menos impactante. E tem precedente, o OpenFinance, onde também há uma tela dessas.
O que foi gongado é um API exposta publicamente fora da RSFN. Tem como adaptar sua proposta para rodar dentro da RSFN, e vou citar como abaixo.
Ok, chave poderia ficar publicada no site do BACEN. Isso pode ter alguma letargia nos roll-over de chave, mas dá para publicar duas chaves iniciando vigência em anos alternados e ir fazendo phase-out das antigas.
Uma adaptação aqui seria a consulta ao DICT, que já é feita via RSFN, ser esse mecanismo. O banco envia via RSFN para o BACEN esse blob criptografado e um e2eid, e o BACEN já na mesma tacada decriptografa, faz look-up da chave no DICT e devolve os dados bancários correspondentes e o BRCode(EMV) do pagamento. Então o app do PSP continua falando apenas com o back-end do PSP, e o back-end do PSP falando com o BACEN. E nem precisaria de uma nova interface no arranjo.
|
Descreva sua dúvida ou problema
Pelo que li nas especificações de iniciação do PIX, entendi que o Banco Central irá registrar o aplicativo de cada PSP para ativar App Links (para Android) e Universal Links (para iOS).
A documentação sempre trabalha com a premissa de que o sistema operacional irá permitir ao usuário escolher a aplicação que irá abrir aquele link (ou definir um padrão) dentre as que tem instalado. O que é válido para o Android.
Porém, no iOS, não é possível escolher o aplicativo aberto por um universal link.
Meu entendimento é que o primeiro aplicativo listado no https://pix.bcb.gov.br/.well-known/apple-app-site-association que o usuário tiver instalado será aberto.
Isso dito, tenho duas dúvidas:
Sistema ou Área
PIX Link
The text was updated successfully, but these errors were encountered: