[Sugestão] Confirmar pagamento de QR Code Estático sem depender de um PSP

[josimarcordeiro]

Muitas instituições financeiras ainda não disponibilizaram API PIX para seus clientes. Tenho dúvidas se algumas delas realmente querem disponibilizar ou se querem forçar seus clientes a utilizar outras soluções que seriam mais rentáveis (por exemplo, PIX na maquinha de cartão com cobrança de um % sobre a transação).

O Banco Central deveria criar uma forma do usuário recebedor realizar sua conciliação bancária via API sem depender de um PSP.

Exemplo: Cliente recebedor utiliza sua chave PIX para criar um QR Code estático com um txId único. O Banco central disponibiliza uma consulta via API diretamente sua base (https://br.gov.bcb.pix) onde o cliente recebedor irá informar na requisição a chave PIX e o txId e o BC irá retornar apenas "true" ou "false" para essa consulta. Uma solução desse tipo iria permitir o desenvolvimento de Softwares de conciliação bancária mais fáceis dos usuários (recebedores) utilizar pois esses usuários não iriam depender de credenciais fornecidas por um PSP.

O fato é que o Banco Central não pode deixar os clientes reféns dos PSP's para funcionalidades básicas.

[rubenskuhl]

O mercado já é limitado aos PSPs, pois só estes podem abrir contas para terceiros. Mas especificamente do que você propõe, mesmo que o BC entenda que deva ofertar isso, há alguns problemas:

• Um QR-Code estático pode ser pago n vezes. A qual dos pagamentos aplicar a consulta ?
• Pq a informação de pagamento pode ser respondida para quem consultou ? O que diz ao BC que quem solicitou a informação é de fato o dono dessa chave Pix ?
• Se o PSP do pagador e do receber forem o mesmo, a transação não passa pelo SPI do BC. O BC não tem como saber se isso foi ou não pago.
• Se a resposta é apenas true/false, fica difícil pesquisar algum problema relatado por cliente, pois não se tem o E2EID da transação.

Há PSPs que tem ofertas de API Pix sólidas e econômicas, sugiro procurar um que tenha boas condições entre os listados em #76 .

[josimarcordeiro]

@rubenskuhl obrigado por contribuir com esse tópico!

A forma como sugeri foi apenas para iniciar a discursão. Com certeza o fluxo precisa ser melhorado. O ponto central aqui é a dependência que atualmente um usuário recebedor tem de um PSP para realizar uma simples conciliação.

Minha sugestão se baseia no seguinte caso de uso (que acredito ser um dos principais):

1- O consumidor vai em uma padaria (por exemplo) e compra vários itens (pão, leite, pão de queijo, etc), cujo valor total fica de R$ 25,78. 2- Ao chegar no caixa o consumidor informa que vai pagar via PIX. Neste momento o Software do estabelecimento gera um QR Estático com valor definido de 25,78 e configura o txId que, dentre outros elementos vai conter: data, hora (incluindo segundos) e valor da transação. 3- O consumidor realiza o pagamento via leitura do QR Code Gerado e informa o funcionário da padaria que concluiu o pagamento. 4- O funcionário então clica em um botão "Confirmar Pagamento" para aquele QR Específico Gerado apenas naquela ocasião. A requisição enviada ao servidor do Banco Central irá conter: Chave Pix do Recebedor e txId. O Banco Central retorna TRUE ou FALSE.

com base no caso de uso acima teríamos as seguintes respostas para suas considerações:

Um QR-Code estático pode ser pago n vezes. A qual dos pagamentos aplicar a consulta ?

Dificilmente o QR Code seria pagamento mais de uma vez, pois ele foi criado especificamente para aquela transação. Isso também ficaria por responsabilidade do Software e o cliente receber.

Pq a informação de pagamento pode ser respondida para quem consultou ? O que diz ao BC que quem solicitou a informação é de fato o dono dessa chave Pix ?

Acho muito difícil um usuário (software) realizar uma requisição para confirmar uma transação que não te pertence informando a chave PIX utilizada e uma string (txId) de 25 caracteres que foi gerada com base na data, hora, minutos, segundos e valor da transação. Mesmo se isso acontecer, como o retorno será apenas "true" ou "false" não haveria problemas (pelo menos não consegui pensar em um até agora).

Se o PSP do pagador e do receber forem o mesmo, a transação não passa pelo SPI do BC. O BC não tem como saber se isso foi ou não pago.

Isso eu não sabia. Mas, se for do interesse do Banco Central, com certeza ele consegue resolver isso determinando que todas as transações passem pelo SPI.

Se a resposta é apenas true/false, fica difícil pesquisar algum problema relatado por cliente, pois não se tem o E2EID da transação.

Para o caso de uso relatado acima, retornar "true" ou "false" já é suficiente.

Há PSPs que tem ofertas de API Pix sólidas e econômicas, sugiro procurar um que tenha boas condições entre os listados em #76

Sim, há muitos, mas ainda o software ficaria refém de terceiros. Minha proposta visa também trazer maior competitividade no mercado incentivando desenvolvedores a criar soluções ainda mais baratas sem depender de terceiros. Porque um software de conciliação bancária, para transações via PIX, deve ficar refém de um PSP?

A utilização de QR Estático como sugeri acima seria uma forma do Banco Central trazer maior competitividade para o mercado sem realizar grandes investimentos na infraestrutura.

[rubenskuhl]

Um QR-Code estático pode ser pago n vezes. A qual dos pagamentos aplicar a consulta ?

Dificilmente o QR Code seria pagamento mais de uma vez, pois ele foi criado especificamente para aquela transação. Isso também ficaria por responsabilidade do Software e o cliente receber.

"Dificilmente" não funciona quando se fala de dinheiro. Muitas detalhes da API Pix foram pensados para garantir idempotência, que é mesmo que uma transação seja repetida, ela só gere efeito uma vez... e não dá para fazer isso com QR-Code estático, especialmente que se identifica como único mas na verdade é de repetição infinita.

Pq a informação de pagamento pode ser respondida para quem consultou ? O que diz ao BC que quem solicitou a informação é de fato o dono dessa chave Pix ?

Acho muito difícil um usuário (software) realizar uma requisição para confirmar uma transação que não te pertence informando a chave PIX utilizada e uma string (txId) de 25 caracteres que foi gerada com base na data, hora, minutos, segundos e valor da transação. Mesmo se isso acontecer, como o retorno será apenas "true" ou "false" não haveria problemas (pelo menos não consegui pensar em um até agora).

"Muito difícil" também não atende quando se fala de sigilo bancário. E esse formato permite um claro método de enumeração para se descobrir todas as vendas de uma empresa, então nem muito difícil seria.

Se o PSP do pagador e do receber forem o mesmo, a transação não passa pelo SPI do BC. O BC não tem como saber se isso foi ou não pago.

Isso eu não sabia. Mas, se for do interesse do Banco Central, com certeza ele consegue resolver isso determinando que todas as transações passem pelo SPI.

Diminuir a escalabilidade e confiabilidade do ecossistema todo ? Está cada vez mais difícil para o BC se interessar por isso...

Se a resposta é apenas true/false, fica difícil pesquisar algum problema relatado por cliente, pois não se tem o E2EID da transação.

Para o caso de uso relatado acima, retornar "true" ou "false" já é suficiente.

Nope, não é. Ter como resolver divergências é exigência básica do arcabouço legal das relações de consumo, e atar as mãos dos comerciantes nessa hora só garante que todo mundo que reclame, ganhe. E aí o meio de pagamento deixaria de ter a confiança do comerciante.

Há PSPs que tem ofertas de API Pix sólidas e econômicas, sugiro procurar um que tenha boas condições entre os listados em #76

Sim, há muitos, mas ainda o software ficaria refém de terceiros. Minha proposta visa também trazer maior competitividade no mercado incentivando desenvolvedores a criar soluções ainda mais baratas sem depender de terceiros. Porque um software de conciliação bancária, para transações via PIX, deve ficar refém de um PSP?

Você fala refém como se não houvesse uma utilidade para o PSP... diferente de um corretor de seguros/imóveis, o PSP agrega fatores muito relevantes para o funcionamento do arranjo. O BC tanto tem um papel pequeno no operacional do arranjo que cobra um valor irrisório pelas transações (R$ 0,001 para recebimento, R$ 0 para pagamento).

A utilização de QR Estático como sugeri acima seria uma forma do Banco Central trazer maior competitividade para o mercado sem realizar grandes investimentos na infraestrutura.

Só que perdendo muitas características importantes do arranjo, e introduzindo risco operacional significativo. A competitividade no mercado está baixa de fato, então o que viesse para aumentá-la sem comprometer o Pix seria ótimo. Mas essa proposta está muito longe disso, IMHO.

[josimarcordeiro]

Pelo menos você concordou comigo que a competitividade está baixa... rsrs :)

Você fala refém como se não houvesse uma utilidade para o PSP... diferente de um corretor de seguros/imóveis, o PSP agrega fatores muito relevantes para o funcionamento do arranjo. O BC tanto tem um papel pequeno no operacional do arranjo que cobra um valor irrisório pelas transações (R 0 para pagamento).

Não estou falando que o PSP não tem utilidade. Só estou falando que a maioria deles estão mais preocupados em oferecer soluções que tornam os clientes dependentes deles e que tragam lucros exorbitantes. Quer uma prova disso?... Você mesmo informou acima que o BC cobra um valor irrisório pelas transações (R0,01 para recebimento, R 0 para pagamento). A solução PIX na maquinha de cartão tem cobrado em média 1% sobre cada transação (mais caro até que cartão de débito em algumas ocasiões). A maioria dos estabelecimentos estão optando por essas soluções pois é forma mais prática e rápida de confirmar os pagamentos via PIX (tem como base o caso de uso que relatei). Qual interesse dos grandes PSP's em fornecer uma API para facilitar a conciliação bancária? Basta olhar na lista PSP's ... não está faltando grandes player do mercado? Muitos que lançaram não foram não obedientes à API Pix padrão? Porque?

Qual seria sua sugestão para trazer maior competitividade para o mercado? Como permitir uma conciliação bancária sem depender do PSP?

[rubenskuhl]

Pelo menos você concordou comigo que a competitividade está baixa... rsrs :)

Esse é um dado de realidade, infelizmente. A lista de PSPs que tento manter atualizada teve como base exatamente a minha busca por um PSP para o meu empregador, e nela fica nítido uma oferta bem menor do que a de APIs de cobrança via boleto, que era o mecanismo mais próximo do mercado financeiro ao PIX Cobrança.

Você fala refém como se não houvesse uma utilidade para o PSP... diferente de um corretor de seguros/imóveis, o PSP agrega fatores muito relevantes para o funcionamento do arranjo. O BC tanto tem um papel pequeno no operacional do arranjo que cobra um valor irrisório pelas transações (R 0 para pagamento).

Não estou falando que o PSP não tem utilidade. Só estou falando que a maioria deles estão mais preocupados em oferecer soluções que tornam os clientes dependentes deles e que tragam lucros exorbitantes. Quer uma prova disso?... Você mesmo informou acima que o BC cobra um valor irrisório pelas transações (R0,01 para recebimento, R 0 para pagamento). A solução PIX na maquinha de cartão tem cobrado em média 1% sobre cada transação (mais caro até que cartão de débito em algumas ocasiões). A maioria dos estabelecimentos estão optando por essas soluções pois é forma mais prática e rápida de confirmar os pagamentos via PIX (tem como base o caso de uso que relatei). Qual interesse dos grandes PSP's em fornecer uma API para facilitar a conciliação bancária? Basta olhar na lista PSP's ... não está faltando grandes player do mercado? Muitos que lançaram não foram não obedientes à API Pix padrão? Porque?

Exceto os bancos cooperativos, que aliás são bem citados em termos de API Pix mais recentemente, todos os outros PSPs são instituições com fins lucrativos. Assim, é esperável que eles busquem lucro... agora, tornar dependentes é algo que o BC quer impedir ao estabelecer uma API padrão.

O custo irrisório do SPI é uma mostra de como o BC montou a arquitetura para depender muito mais das pontas do que do núcleo... que é um modelo que se sabe que escala, pois é como funciona a Internet. Então não dá para usar o custo do BC como parâmetro para o que deve ser um preço pelo serviço da API Pix.

A remuneração do recebimento Pix como percentual é algo que me causa estranheza, e curiosamente copia o modelo do cartão de débito, não do boleto. Mas ela tem vantagem para o cliente com recebimentos de valor pequeno(<R$ 100) em receber Pix pagando pouco, além de mitigar o ataque dos centavos, um problema que descrevi em #25 . Então eu entendo pq o BC não quis interferir no modelo de cobrança, dado o prejuízo para esses recebedores.

Quanto aos grandes players do mercado, depende de qual mercado... de contas correntes para PJ ou de recebimentos via API ? Não são o mesmo. Mas há pelo menos um na lista que é grande nos dois, o Itaú... e que apesar de alguns desvios da API padrão, são leves o suficiente para uma migração com baixo esforço. E num sinal de que há alguma competitividade, não foi com o Itaú que fechamos, exatamente por conseguirmos um outro PSP com API sólida, padrão e no custo que nos agradou.

Sobre os não obedientes ao padrão, aqui eu entendo como culpa do BC. Em comunicados ao mercado eles eram incisivos, mas até hoje os dentes não apareceram para morder os que não seguem o padrão. Eu faço denúncias regulares de PSPs fora do regramento para o BC, e em apenas um deles deu para perceber uma mudança de atitude (mas que não levou ao compliance total, apenas a algumas correções).

Qual seria sua sugestão para trazer maior competitividade para o mercado? Como permitir uma conciliação bancária sem depender do PSP?

Eu acho que o caminho é a ligação direta entre software houses que atendem o varejo e PSTIs como Matera, JD e C&M para que os clientes nem precisem se preocupar em quem é o PSP e já recebem soluções de automação que de prateleira já vem com Pix. Buscar um PSP é opção para quem desenvolve sua própria automação/integração, que já é um patamar onde há profissionais que vão acabar encontrando listas como a que eu publico ou montando suas próprias listas para tomada de decisão.

Um mecanismo que permitiria conciliação sem depender do PSP seria o de assinar digitalmente as transações, dando a elas não apenas um E2EID mas também um "carimbo". Essa assinatura seria colocada pelo SPI no caso de transações entre PSPs ou pelo PSP se ele mesmo inicia e termina a transação. Eu já aventei essa idéia aqui no GH do BC, mas não teve muita tração com o pessoal do BC não... mas reconheço que isso deixaria a mensagem "Você recebeu um Pix" muito maior do que é hoje, tanto na atualidade quanto especialmente quando tivermos que usar algoritmos post-quantum de assinatura digital.

E o que já pode ser feito hoje com vários PSPs é processar os e-mails e/ou SMS de aviso de Pix para fazer essa conciliação. Algo como uma "Poor man's API".

[rdgsouza]

A questão que @josimarcordeiro esta abordado aqui é muito importante! Estou precisando no sistema da confirmação pix paga por um qr code estático sem depender de um PSP e não existe uma solução pra isso. :(

[rubenskuhl]

A questão que @josimarcordeiro esta abordado aqui é muito importante! Estou precisando no sistema da confirmação pix paga por um qr code estático sem depender de um PSP e não existe uma solução pra isso. :(

Pq não é um bug, é um feature...

[rdgsouza]

Tomara que desenvolvam essa feature : /

[leandrovip]

Tomara que desenvolvam essa feature : /

Infelizmente, acho pouco provável.

[matosagencia]

O pix é uma jaula digital, pelo que li.

[rubenskuhl]

O pix é uma jaula digital, pelo que li.

Em que sentido ? Diferente dos outros arranjos de pagamento, o PIX tem API padronizada. Boleto e cartões tem dificuldades significativas de mudança de prestador, tem que escrever tudo do zero.

[Guihgo]

O pix é uma jaula digital, pelo que li.

Em que sentido ? Diferente dos outros arranjos de pagamento, o PIX tem API padronizada. Boleto e cartões tem dificuldades significativas de mudança de prestador, tem que escrever tudo do zero.

exato, em comparação a outros arranjos de pagamento tradicionais, o PIX evolui e revolucionou o setor aqui no Brasil. No entanto, pode se considerar uma jaula quando se compara às criptomoedas e isso não é culpa do PIX, é do sistema fiduciário....

[rubenskuhl]

O pix é uma jaula digital, pelo que li.

Em que sentido ? Diferente dos outros arranjos de pagamento, o PIX tem API padronizada. Boleto e cartões tem dificuldades significativas de mudança de prestador, tem que escrever tudo do zero.

exato, em comparação a outros arranjos de pagamento tradicionais, o PIX evolui e revolucionou o setor aqui no Brasil. No entanto, pode se considerar uma jaula quando se compara às criptomoedas e isso não é culpa do PIX, é do sistema fiduciário....

Só que ainda não temos, e não sabemos se será possível ter, criptomoedas computacionalmente eficientes para que possamos ancorar volumes transacionais significativos. Toda permissionless block ledger criada até o momento tem volumes muito limitados de transações... Ethereum - que é usado por grande parte das altcoins de hoje - permite só 30 transações por segundo na rede toda. Bitcoin é menos do que isso.

Há tentativas de centralização mínima (sistemas centralizados em pools e esses usam um permissionless ledger só para clearance) mas que eu acho que são tipo ornitorrinco: nadam e correm mas não fazem bem nenhuma das coisas.

A oportunidade para quem conseguir criar um permissionless ledger eficiente é gigante, mas esse tem grande chances de ser um problema insolúvel, similar ao P x NP.

[matosagencia]

e a lightning network? permite micropagamentos como uma segunda camada no bitcoin, hoje as transacoes pix fluem para o bc a uma taxa X e isso poderia ser feito em lotes, a instituicao por exemplo poderia emitir sinteticos e esses "trocados por reais" e depois lançados para o bc como uma unica transacao pix entre bancos. esquece, o bc quer o controle absoluto da moeda..

[rubenskuhl]

e a lightning network? permite micropagamentos como uma segunda camada no bitcoin, hoje as transacoes pix fluem para o bc a uma taxa X e isso poderia ser feito em lotes, a instituicao por exemplo poderia emitir sinteticos e esses "trocados por reais" e depois lançados para o bc como uma unica transacao pix entre bancos. esquece, o bc quer o controle absoluto da moeda..

Não vou falar pelo BC pq não sei o que ele quer, mas eu citei exatamente esse tipo de sistema como a Lightning Network quando mencionei "Há tentativas de centralização mínima (sistemas centralizados em pools e esses usam um permissionless ledger só para clearance) mas que eu acho que são tipo ornitorrinco: nadam e correm mas não fazem bem nenhuma das coisas."

[renatofrota]

e a lightning network? permite micropagamentos como uma segunda camada no bitcoin, hoje as transacoes pix fluem para o bc a uma taxa X e isso poderia ser feito em lotes, a instituicao por exemplo poderia emitir sinteticos e esses "trocados por reais" e depois lançados para o bc como uma unica transacao pix entre bancos. esquece, o bc quer o controle absoluto da moeda..

Se a sua expectativa é essa, espera sentado. Uma organização do Estado jamais vai abrir mão de um controle que ela já tem. Vide #62 que eu abri para tratar do mesmo assunto exposto aqui, antes do Pix entrar em operação e o BC deu resposta negativa.

[matosagencia]

O efeito prático disso sera uma debandada para a LN, onde o Real será apenas uma unidade de conta como o metro e o litro.

[rubenskuhl]

O efeito prático disso sera uma debandada para a LN, onde o Real será apenas uma unidade de conta como o metro e o litro.

Nenhuma cripto tem hoje a aceitação que permita ser chamada de moeda, inclusive a LN (que mesmo entre criptos é pouquíssimo conhecida). E achar que isso no futuro será diferente é muito "wishful thinking", pois ainda não temos nenhuma base racional para que esse seja um cenário factível. Agora, uma possível solução computacionalmente eficiente (e não um ornitorrinco) teria ao menos chance, pois aí ficariam apenas as questões sociais e políticas.

[sostenesapollo]

Como gerar o pixUrlAccessToken ?

[sostenesapollo]

Alguem sabe alugma api open source para emitir nota fiscal ?

[josimarcordeiro]

Bom dia!

Na agenda futura de novas funcionalidades do PIX, disponível no link https://www.bcb.gov.br/estabilidadefinanceira/pix, está prevista duas funcionalidades:

• API de Pagamentos
• Ferramenta para consulta de transações liquidadas no SPI

No caso da "API de Pagamentos" será que o Banco Central vai disponibilizar uma API direto com BACEN para que uma software house, por exemplo, não dependa mais de um PSP?

Já a "Ferramenta para consulta de transações liquidadas no SPI" iria permitir consultas via API, direto com o BACEN, para confirmar o pagamento de um QRCode Estático ou Dinâmico por meio do txId?

@ninrod , @rubenskuhl ou alguém tem mais informações sobre essas duas funcionalidades que serão criadas?

Desde já agradeço a atenção.

[rubenskuhl]

Bom dia!

Na agenda futura de novas funcionalidades do PIX, disponível no link https://www.bcb.gov.br/estabilidadefinanceira/pix, está prevista duas funcionalidades:

O que preciso comentar na experiência de acompanhar a agenda futura desde 3 anos atrás é que se há muitos itens nela, isso significa que muitos desses itens nunca irão sair. Outro ponto que já me aconteceu com um outro recurso foi tentar preencher o cenário a partir do nome, e na verdade era algo muito diferente do que eu tinha pensado.

Notar que eu não sou do BACEN...

[felipemmasan]

em resumo, existe no pix, alguma forma de receber uma notificação de um QRCode Estático foi pago?

[rubenskuhl]

em resumo, existe no pix, alguma forma de receber uma notificação de um QRCode Estático foi pago?

Se o QR-Code estático tem txid, a API Pix padrão especifica que seja acionado o webhook.

[Ilusinusmate]

@rubenskuhl obrigado por contribuir com esse tópico!

A forma como sugeri foi apenas para iniciar a discursão. Com certeza o fluxo precisa ser melhorado. O ponto central aqui é a dependência que atualmente um usuário recebedor tem de um PSP para realizar uma simples conciliação.

Minha sugestão se baseia no seguinte caso de uso (que acredito ser um dos principais):

1- O consumidor vai em uma padaria (por exemplo) e compra vários itens (pão, leite, pão de queijo, etc), cujo valor total fica de R$ 25,78. 2- Ao chegar no caixa o consumidor informa que vai pagar via PIX. Neste momento o Software do estabelecimento gera um QR Estático com valor definido de 25,78 e configura o txId que, dentre outros elementos vai conter: data, hora (incluindo segundos) e valor da transação. 3- O consumidor realiza o pagamento via leitura do QR Code Gerado e informa o funcionário da padaria que concluiu o pagamento. 4- O funcionário então clica em um botão "Confirmar Pagamento" para aquele QR Específico Gerado apenas naquela ocasião. A requisição enviada ao servidor do Banco Central irá conter: Chave Pix do Recebedor e txId. O Banco Central retorna TRUE ou FALSE.

com base no caso de uso acima teríamos as seguintes respostas para suas considerações:

Um QR-Code estático pode ser pago n vezes. A qual dos pagamentos aplicar a consulta ?

Dificilmente o QR Code seria pagamento mais de uma vez, pois ele foi criado especificamente para aquela transação. Isso também ficaria por responsabilidade do Software e o cliente receber.

Pq a informação de pagamento pode ser respondida para quem consultou ? O que diz ao BC que quem solicitou a informação é de fato o dono dessa chave Pix ?

Acho muito difícil um usuário (software) realizar uma requisição para confirmar uma transação que não te pertence informando a chave PIX utilizada e uma string (txId) de 25 caracteres que foi gerada com base na data, hora, minutos, segundos e valor da transação. Mesmo se isso acontecer, como o retorno será apenas "true" ou "false" não haveria problemas (pelo menos não consegui pensar em um até agora).

Se o PSP do pagador e do receber forem o mesmo, a transação não passa pelo SPI do BC. O BC não tem como saber se isso foi ou não pago.

Isso eu não sabia. Mas, se for do interesse do Banco Central, com certeza ele consegue resolver isso determinando que todas as transações passem pelo SPI.

Se a resposta é apenas true/false, fica difícil pesquisar algum problema relatado por cliente, pois não se tem o E2EID da transação.

Para o caso de uso relatado acima, retornar "true" ou "false" já é suficiente.

Há PSPs que tem ofertas de API Pix sólidas e econômicas, sugiro procurar um que tenha boas condições entre os listados em #76

Sim, há muitos, mas ainda o software ficaria refém de terceiros. Minha proposta visa também trazer maior competitividade no mercado incentivando desenvolvedores a criar soluções ainda mais baratas sem depender de terceiros. Porque um software de conciliação bancária, para transações via PIX, deve ficar refém de um PSP?

A utilização de QR Estático como sugeri acima seria uma forma do Banco Central trazer maior competitividade para o mercado sem realizar grandes investimentos na infraestrutura.

A ideia em questão é completamente válida, eu mesmo ando sofrendo com a implementação de um sistema complexo que visa exatamente este fluxograma, enquanto poderia ser bem mais simples, caso houvesse uma facilitação por meio do Banco Central. Ótima colocação @rubenskuhl

[rubenskuhl]

@rubenskuhl obrigado por contribuir com esse tópico! A forma como sugeri foi apenas para iniciar a discursão. Com certeza o fluxo precisa ser melhorado. O ponto central aqui é a dependência que atualmente um usuário recebedor tem de um PSP para realizar uma simples conciliação. Minha sugestão se baseia no seguinte caso de uso (que acredito ser um dos principais): 1- O consumidor vai em uma padaria (por exemplo) e compra vários itens (pão, leite, pão de queijo, etc), cujo valor total fica de R$ 25,78. 2- Ao chegar no caixa o consumidor informa que vai pagar via PIX. Neste momento o Software do estabelecimento gera um QR Estático com valor definido de 25,78 e configura o txId que, dentre outros elementos vai conter: data, hora (incluindo segundos) e valor da transação. 3- O consumidor realiza o pagamento via leitura do QR Code Gerado e informa o funcionário da padaria que concluiu o pagamento. 4- O funcionário então clica em um botão "Confirmar Pagamento" para aquele QR Específico Gerado apenas naquela ocasião. A requisição enviada ao servidor do Banco Central irá conter: Chave Pix do Recebedor e txId. O Banco Central retorna TRUE ou FALSE. com base no caso de uso acima teríamos as seguintes respostas para suas considerações:

Um QR-Code estático pode ser pago n vezes. A qual dos pagamentos aplicar a consulta ?

Dificilmente o QR Code seria pagamento mais de uma vez, pois ele foi criado especificamente para aquela transação. Isso também ficaria por responsabilidade do Software e o cliente receber.

"Dificilmente" é um adjetivo que não funciona em sistemas de pagamento. As pessoas querem saber exatamente se pagaram em duplicidade por algo não, e não uma probabilidade quântica.

Pq a informação de pagamento pode ser respondida para quem consultou ? O que diz ao BC que quem solicitou a informação é de fato o dono dessa chave Pix ?

Acho muito difícil um usuário (software) realizar uma requisição para confirmar uma transação que não te pertence informando a chave PIX utilizada e uma string (txId) de 25 caracteres que foi gerada com base na data, hora, minutos, segundos e valor da transação. Mesmo se isso acontecer, como o retorno será apenas "true" ou "false" não haveria problemas (pelo menos não consegui pensar em um até agora).

Privacidade também é um ramo aonde "é muito difícil" não atende às expectativas das pessoas, e neste caso também não atende à LGPD.

Se o PSP do pagador e do receber forem o mesmo, a transação não passa pelo SPI do BC. O BC não tem como saber se isso foi ou não pago.

Isso eu não sabia. Mas, se for do interesse do Banco Central, com certeza ele consegue resolver isso determinando que todas as transações passem pelo SPI.

Ou seja, introduzir uma maior carga no SPI e um ponto de falha hoje não existente ? O interesse do Banco Central vai ser o contrário...

Se a resposta é apenas true/false, fica difícil pesquisar algum problema relatado por cliente, pois não se tem o E2EID da transação.

Para o caso de uso relatado acima, retornar "true" ou "false" já é suficiente.

Não, não é. Pagamentos precisam de ferramentas de conciliação, e você irá encontrar uma forma de conciliação em todo documento impresso (ex: boleta de maquininha de cartão) ou eletrônico (ex: transação em Internet Banking) exatamente por isso.

Há PSPs que tem ofertas de API Pix sólidas e econômicas, sugiro procurar um que tenha boas condições entre os listados em #76

Sim, há muitos, mas ainda o software ficaria refém de terceiros. Minha proposta visa também trazer maior competitividade no mercado incentivando desenvolvedores a criar soluções ainda mais baratas sem depender de terceiros. Porque um software de conciliação bancária, para transações via PIX, deve ficar refém de um PSP?

O destinatário sempre precisa de um PSP, pois as pessoas tem contas nos PSPs, não no Banco Central. Então o destinatário é sempre refém de um PSP... só o que pode ser diferente é ele mudar de PSP para um que atenda um determinado nível de expectativa.

A lista de PSPs do BACEN já passa de 1000 PSPs... difícil dizer que as pessoas não tem opção.

A utilização de QR Estático como sugeri acima seria uma forma do Banco Central trazer maior competitividade para o mercado sem realizar grandes investimentos na infraestrutura.

Não é sem investimento, vide ponto do SPI acima.

A ideia em questão é completamente válida, eu mesmo ando sofrendo com a implementação de um sistema complexo que visa exatamente este fluxograma, enquanto poderia ser bem mais simples, caso houvesse uma facilitação por meio do Banco Central. Ótima colocação @rubenskuhl

Me parece que você quer mudanças na realidade para permitir que um determinado modelo de negócios funcione... e não é papel do Banco Central fazer isso.