Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposição de feature + RFC - QRCode Offline Pix #584

Open
scarletquasar opened this issue Jan 22, 2024 · 6 comments
Open

Proposição de feature + RFC - QRCode Offline Pix #584

scarletquasar opened this issue Jan 22, 2024 · 6 comments

Comments

@scarletquasar
Copy link

Sumário

Este repositório contém uma RFC (em inglês) oferecendo uma sugestão de feature para ser arquitetada e adicionada integralmente à API Pix Bacen (seja como parte intrínseca de um monolito ou um microsserviço separado).

Link do repositório: https://github.com/scarletquasar/offline-pix-rfc

@Guihgo
Copy link

Guihgo commented Jan 23, 2024

Interessante a abordagem. Porém utópica e fora de mão quando esta necessita que o usuário pagante precisa antes, com acesso à internet, criar um código com o valor a ser pago. Na prática e no dia dia, ninguém sai de casa já sabendo o valor que vai gastar. Ao meu ponto de vista, vai levar muitos anos para desenvolvermos uma tecnologia que permita uma transação monetária full off-line, na verdade acredito que isso seria o santo graal dos sistemas financeiros. Até lá, vamos ter apenas half off-line, seja por parte do pagante ou do recebedor. Uma persona sempre precisará de acesso à Internet para validar a transação.

Aí você pode lembrar dos cartões de passe de ônibus, funcionam muito bem e totalmente full off-line. Mas são vulneráveis, nenhuma instituição com o mínimo de critério em segurança da informação iria ousar em usar a mesma tecnologia dos passes no sistema financeiro. Seria brecha que pode quebrar o sistema econômico de uma país.

@scarletquasar
Copy link
Author

Interessante a abordagem. Porém utópica e fora de mão quando esta necessita que o usuário pagante precisa antes, com acesso à internet, criar um código com o valor a ser pago. Na prática e no dia dia, ninguém sai de casa já sabendo o valor que vai gastar. Ao meu ponto de vista, vai levar muitos anos para desenvolvermos uma tecnologia que permita uma transação monetária full off-line, na verdade acredito que isso seria o santo graal dos sistemas financeiros. Até lá, vamos ter apenas half off-line, seja por parte do pagante ou do recebedor. Uma persona sempre precisará de acesso à Internet para validar a transação.

Aí você pode lembrar dos cartões de passe de ônibus, funcionam muito bem e totalmente full off-line. Mas são vulneráveis, nenhuma instituição com o mínimo de critério em segurança da informação iria ousar usar a mesma tecnologia dos passes no sistema financeiro. Seria brecha para quebrar o sistema econômico de uma país.

Você não levou em consideração que o RFC descreve uma separação de um valor monetário que pode ser usado em vários lugares, não só uma transação única. Por isso foi descrito que se assemelha com cartões. É a mesma lógica de separar uma nota de 100 reais para sair para fazer compras, você sabe o seu valor limite, mas não exatamente o quanto vai gastar.

Também não levou em consideração que a pessoa que fará o recebimento, terá acesso a internet, na descrição (uma das primeiras linhas descrevendo o problema) eu adicionei que isso vale para problemas onde o pagante não terá internet, mas o recebedor sim (existem diversos casos, eu mesma já estive em uma situação como essa, até em diversos serviços públicos aqui na cidade capital de São Paulo, onde moro).

Além disso, também não levou em consideração, que por ter internet, a pessoa recebedora poderá fazer esse tipo de checagem no agendamento para a transação, via o intermediário que estará no servidor web para o qual a recebedora estará fazendo o request, de forma que checagens de segurança como questão de localização e tempo possam ser feitas, tudo isso está bem descrito explicado nas seções de usabilidade e segurança.

@rubenskuhl
Copy link

Algo que parece inspirado em blockchain são os intermediários validadores... só que isso não funciona num ambiente regulado. Mas assumindo intermediários como as instituições autorizadas pelo Banco Central, e especificamente aquela aonde está depositado o saldo sendo usado, isso não teria óbice.

Um ponto que é bem difícil para fazer o Pix Offline é o de patentes cobrindo o que foi desenvolvido e é usado para pagamentos por aproximação em celulares.

@bolodissenoura
Copy link

Interessante a abordagem. Porém utópica e fora de mão quando esta necessita que o usuário pagante precisa antes, com acesso à internet, criar um código com o valor a ser pago. Na prática e no dia dia, ninguém sai de casa já sabendo o valor que vai gastar. Ao meu ponto de vista, vai levar muitos anos para desenvolvermos uma tecnologia que permita uma transação monetária full off-line, na verdade acredito que isso seria o santo graal dos sistemas financeiros. Até lá, vamos ter apenas half off-line, seja por parte do pagante ou do recebedor. Uma persona sempre precisará de acesso à Internet para validar a transação.
Aí você pode lembrar dos cartões de passe de ônibus, funcionam muito bem e totalmente full off-line. Mas são vulneráveis, nenhuma instituição com o mínimo de critério em segurança da informação iria ousar usar a mesma tecnologia dos passes no sistema financeiro. Seria brecha para quebrar o sistema econômico de uma país.

Você não levou em consideração que o RFC descreve uma separação de um valor monetário que pode ser usado em vários lugares, não só uma transação única. Por isso foi descrito que se assemelha com cartões. É a mesma lógica de separar uma nota de 100 reais para sair para fazer compras, você sabe o seu valor limite, mas não exatamente o quanto vai gastar.

Também não levou em consideração que a pessoa que fará o recebimento, terá acesso a internet, na descrição (uma das primeiras linhas descrevendo o problema) eu adicionei que isso vale para problemas onde o pagante não terá internet, mas o recebedor sim (existem diversos casos, eu mesma já estive em uma situação como essa, até em diversos serviços públicos aqui na cidade capital de São Paulo, onde moro).

Além disso, também não levou em consideração, que por ter internet, a pessoa recebedora poderá fazer esse tipo de checagem no agendamento para a transação, via o intermediário que estará no servidor web para o qual a recebedora estará fazendo o request, de forma que checagens de segurança como questão de localização e tempo possam ser feitas, tudo isso está bem descrito explicado nas seções de usabilidade e segurança.

Isso seria muito legal. O mundo ideal pra mim é uma colaboração dessa feature com um NFC.
Sair de casa com uma nota de cem que aproxima via pix, seria perfeito.
Hoje eu só uso mais o cartão que pix por conta do cartão ser muito mais prático em uma transação Pessoa -> Business.

Parabéns pela abordagem! Sucesso.

@rubenskuhl
Copy link

Isso seria muito legal. O mundo ideal pra mim é uma colaboração dessa feature com um NFC. Sair de casa com uma nota de cem que aproxima via pix, seria perfeito. Hoje eu só uso mais o cartão que pix por conta do cartão ser muito mais prático em uma transação Pessoa -> Business.

Parabéns pela abordagem! Sucesso.

Tanto o pix-offline quanto a iniciação por NFC estão na agenda evolutiva do Pix desde o lançamento... mas não tem conseguido prioridade frente a outros recursos como a cobrança com vencimento, a marcação de fraudes e agora o Pix Automático.

A implementação em si que é a proposta da autora deste tópico.

@jpventura
Copy link

@rubenskuhl a patente que integra NFC e RFID em um único dispositivo mobile foi criada por um brasileiro no centro de inovações da Samsung Brasil.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants