-
Notifications
You must be signed in to change notification settings - Fork 272
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
Comments
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. |
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. |
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. |
Isso seria muito legal. O mundo ideal pra mim é uma colaboração dessa feature com um NFC. 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. |
@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. |
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
The text was updated successfully, but these errors were encountered: