[Nova Funcionalidade] Identificador ou código de autenticidade de pagamento

[renatofrota]

Boa tarde,

Quando da conclusão do envio de um Pix, o pagador terá acesso a algum tipo de identificador ou um código de autenticidade que permita a validação desse pagamento por parte do recebedor, a exemplo de uma transferência de criptomoedas, onde toda transação tem um hash que pode ser consultado diretamente na blockchain?

Compreendo que não é de interesse do BACEN que o histórico de transações das chaves seja público, podendo ser consultado somente via API mediante contrato de acesso à API por meio de um dos PSPs. No entanto, se não há um diretório público de transações (como uma blockchain), não é interessante que o pagador tenha uma comprovação do pagamento?

Um mero screenshot do comprovante da transação não serve de nada. Mesmo que tenha ali um código de autenticação que seja interno do PSP. Atualmente é muito comum as pessoas caírem em golpes por que simplesmente não há meios para um recebedor validar uma TED (se há, eu desconheço).

[rubenskuhl]

O arranjo Pix gera um End-to-End-ID que pode ser usado para conferir uma transação. Só precisa ver se isso é mostrado para o pagador.

[ninrod]

Só precisa ver se isso é mostrado para o pagador.

Sim, tem que ser mostrado. Isso ficará mais claro no manual de UX nas próximas versões.

[renatofrota]

Só precisa ver se isso é mostrado para o pagador.

Sim, tem que ser mostrado. Isso ficará mais claro no manual de UX nas próximas versões.

E como poderá ser verificado?

[ninrod]

E como poderá ser verificado?

Essa é uma questão que foi aventada, mas não há ainda um parecer final sobre o tema.

[rubenskuhl]

Só precisa ver se isso é mostrado para o pagador.

Sim, tem que ser mostrado. Isso ficará mais claro no manual de UX nas próximas versões.

E como poderá ser verificado?

GET /pix/e2eid

Cliente fala para o estabelecimento que pagou e fornecer o E2EID; estabelecimento faz essa transação e confirma.

[renatofrota]

Só precisa ver se isso é mostrado para o pagador.

Sim, tem que ser mostrado. Isso ficará mais claro no manual de UX nas próximas versões.

E como poderá ser verificado?

GET /pix/e2eid

Cliente fala para o estabelecimento que pagou e fornecer o E2EID; estabelecimento faz essa transação e confirma.

Aí caímos num problema: cliente PF não tem acesso à PIX API.

Tendo o ID da transação, um recebedor deveria ter a capacidade de validar essa transação (o que não é possível hoje no TED e abre margem para fraudes, como falei anteriormente). Uma interface do BACEN onde o recebedor informe, além do próprio E2EID da transação, o seu CPF/CNPJ (que não é visível na sua totalidade no comprovante do pagador). O pagador também poderia verificar informando o seu CPF/CNPJ (e, obviamente, este veria apenas parcialmente o CPF do recebedor, em este sendo pessoa física, assim como no próprio comprovante que é emitido no momento da transação).

Vejo utilidade nisto até mesmo em fiscalizações e auditorias. Comprovantes de pagamento seriam, dessa forma, facilmente verificáveis por entidades fiscalizatórias.

[rubenskuhl]

Não há restrição alguma para que recebedor PF tenha acesso à API Pix. Só não imagino que seja de graça. Mas no caso de recebedores sem acesso à API, um método de consulta por E2EID no app ou no Internet Banking endereçaria isso.

Colocar o BACEN como confirmador geral de pagamentos no país me parece scope creep do projeto Pix. Se o BACEN topar ok, mas não vejo isso como caso de uso primordial do arranjo.

[ninrod]

Uma interface do BACEN onde o recebedor informe, além do próprio E2EID da transação, o seu CPF/CNPJ (que não é visível na sua totalidade no comprovante do pagador).

@renatofrota, eu mesmo levantei essa possibilidade de rastreamento do e2eid em um ponto centralizado (análogo a rastrear um pacote no Fedex, mas seria rastrear em que status aquele Pix específico se encontra), ainda em 2018, internamente.

Acontece que o Pix é composto por muitos elementos e existe uma porção de funcionalidades também bastante interessantes. Foi estabelecida uma priorização face a limites de recursos. Então certas features acabaram não entrando em um "go live" que já contém um pacote considerável de funcionalidades entregues em um tempo muito curto.

Sem dúvida é uma funcionalidade interessante: não há como negar a possibilidade de que algo assim seja incorporado no Pix futuramente.

[renatofrota]

Não há restrição alguma para que recebedor PF tenha acesso à API Pix. Só não imagino que seja de graça. Mas no caso de recebedores sem acesso à API, um método de consulta por E2EID no app ou no Internet Banking endereçaria isso.

Colocar o BACEN como confirmador geral de pagamentos no país me parece scope creep do projeto Pix. Se o BACEN topar ok, mas não vejo isso como caso de uso primordial do arranjo.

Poderia haver um app oficial do Pix, como você citou aqui, responsável pela verificação de autenticidade de transações*, por direcionar a abertura de "Link Pix" aos aplicativos dos PSPs e, quem sabe, até mesmo notificar os recebedores (#62).

*Analisando o nível de entropia do identificador de uma transação e2eid, talvez nem fosse preciso uma validação extra como o CPF/CNPJ de uma parte envolvida, bastaria exibi-los de forma parcial para garantir a privacidade em caso de alguém, ainda assim, descobrir um UUID por tentativa e erro.

[renatofrota]

Sem dúvida é uma funcionalidade interessante: não há como negar a possibilidade de que algo assim seja incorporado no Pix futuramente.

Tenho ciência das limitações de tempo. A sugestão é para que a implantação aconteça em algum momento oportuno, para contribuir na minimização de fraudes. Vi que você colocou a tag melhoria.

Abraços.

[feinstein]

Perdão mas eu não entendi bem o caso de uso aqui.

A meu ver o pagador vai ver no App do banco dele que um Pix foi feito, assim como se ve que houve qualquer outro tipo de transferência.

Quanto ao recebedor, ou ele também vê no App do banco dele que houve um recebimento, ou o software da empresa (e.g. PDV) vai consultar os últimos pix com um determinado txid, ou receber isso por webhook.

Isso já não é suficiente para se validar um pagamento?

[renatofrota]

Perdão mas eu não entendi bem o caso de uso aqui.

A meu ver o pagador vai ver no App do banco dele que um Pix foi feito, assim como se ve que houve qualquer outro tipo de transferência.

Quanto ao recebedor, ou ele também vê no App do banco dele que houve um recebimento, ou o software da empresa (e.g. PDV) vai consultar os últimos pix com um determinado txid, ou receber isso por webhook.

Isso já não é suficiente para se validar um pagamento?

Não.

Você está considerando situação específicas:

• transferências PF-PF (onde a própria pessoa verifica no app);
• empresas de médio-grande porte (com um ERP atendendo todo o negócio e a API implantanda e com acesso por meio do PDV).

Uma validação do pagamento por meio de um código de autenticidade atenderia cenários de empresas de pequeno porte, sem um ERP com tal funcionalidade, onde um caixa poderia validar um pagamento por esse código, sem precisar, necessariamente, ter acesso à conta transacional.

Além disso, atenderia muito bem situações de auditoria e fiscalização, que já mencionei anteriormente e você não deve ter visto.

E, adicionalmente, ainda auxiliaria outros processos como conciliações em massa, migrações, etc, provendo uma verificação facilitada de que as transações registradas são válidas.

[feinstein]

Entendo, mas hoje em dia se faz auditorias, fiscalização e etc. com pagamentos de cartão de crédito, boleto, DOC, TED e dinheiro vivo. Até onde eu sei todos eles não possuem métodos de rastreio. Tendo isso no Pix talvez ajude, mas a meu ver a indústria toda já está rodando sem isso.

[renatofrota]

Entendo, mas hoje em dia se faz auditorias, fiscalização e etc. com pagamentos de cartão de crédito, boleto, DOC, TED e dinheiro vivo. Até onde eu sei todos eles não possuem métodos de rastreio. Tendo isso no Pix talvez ajude, mas a meu ver a indústria toda já está rodando sem isso.

Hoje em dia a indústria está rodando sem Pix. Se fôssemos nos prender apenas ao que existe, não existiria o Pix.

O BC levantou essa ideia (ou alguém trouxe pra ele, que acho mais provável), investiu tempo e dinheiro nisso e estamos todos nós aqui debatendo melhorias - inclusive esta que estou propondo.

[ricmf]

Eu acho essa funcionalidade bem interessante. Deveria ser possível comprovar que um pagamento foi feito de acesso apenas da tx-id, numa API aberta tanto para o recebedor quanto para o pagador. Em caso de alguma disputa, o pagador poderia acessar essa API para provar que realizou o pagamento.

[renatofrota]

Eu acho essa funcionalidade bem interessante. Deveria ser possível comprovar que um pagamento foi feito de acesso apenas da tx-id, numa API aberta tanto para o recebedor quanto para o pagador. Em caso de alguma disputa, o pagador poderia acessar essa API para provar que realizou o pagamento.

Sim. Hoje, se um boleto pago, por alguma razão, não for devidamente processado pelo EC recebedor, inicia-se uma celeuma com 4 atores:

• pagador
• recebedor
• PSP do pagador
• PSP do recebedor

e demora-se um tempão pra chegar à conclusão de que foi pago mas aconteceu algo errado em algum ponto do processo, descobrir onde foi o erro e corrigir. Todos os envolvidos perdem tempo, dinheiro e alguns fios de cabelo. E o Pix, um arranjo recém saído do forno, está na mesma situação.

[anarkrypto]

Uma espécie de "hash de verificação" seria de extrema ajuda, em especial podendo ser verificada com segurança por um terceiro, sem burocracias. Isto permitiria, por exemplo, que os intermediários de confiança precisassem apenas verificar a transação e não necessariamente intermediar a troca.

[Nivaldo-Freitas]

Uma empresaria que conheço levou até golpe por causa de um comprovante falso de pix.

[renatofrota]

Uma empresaria que conheço levou até golpe por causa de um comprovante falso de pix.

Essa pessoa que você conhece confiou num comprovante enviado a ela por um terceiro que não o PSP onde ela tem a conta transacional então, teoricamente, poderia confiar num falso comprovante de autenticidade proposto nessa issue, do mesmo jeito. Não é esse problema que o código de autenticidade proposto aqui visa sanar.

Os "golpes do Pix" são os mesmos que sempre existiram em todos os tipos de transação: uma vítima dando dinheiro ou dados pessoais a alguém sem credibilidade, por confiar em uma informação falsa (vinda dessa própria pessoa destinatária do dinheiro ou ainda de um terceiro ator).

A partir do momento que uma pessoa aprender que só deve confiar nas informações vindas diretamente do seu PSP, esse tipo de golpe baseado em engenharia social não será mais aplicável.

[rubenskuhl]

A partir do momento que uma pessoa aprender que só deve confiar nas informações vindas diretamente do seu PSP, esse tipo de golpe baseado em engenharia social não será mais aplicável.

O que ainda requer uma forma de entender o que é uma informação vinda diretamente do PSP com que alguém tenha relacionamento e o que alguém tentando personificar esse PSP. Mas já reduz a superfície de ataque.

Um comprovante de Pix, caso existisse, poderia ter uma forma de ser verificado no site do Banco Central. Isso não atende a varejo por causa de filas de caixa (aí só a API mesmo), mas atenderia cenários do tipo "te mandei um comprovante".

Algo que eu senti falta no caso do golpe do Pix agendado foi dos PSPs explicarem para as pessoas como devolver Pix. Se elas soubessem que devolver era só entrar no app e escolher o Pix recebido para devolver, já teria resolvido esse vetor específico.

[brunoalano]

Alguma atualização sobre essa iniciativa? Através de uma API do PSP, eu posso consultar qualquer e2eid, mesmo que não tenha sido transacionado pelo mesmo?

[rubenskuhl]

Alguma atualização sobre essa iniciativa? Através de uma API do PSP, eu posso consultar qualquer e2eid, mesmo que não tenha sido transacionado pelo mesmo?

Não, você só pode obter informação de um e2eid que tenha quitado uma cobrança desse PSP, e apenas se esta associada à conta que está fazendo a consulta.

[Ferreira-Jefferson]

Só quem está na linha de frente consegue enxegar a real dimensão do problema. Na empresa em que trabalho 5 vendedores recebem pix a todo momento, o financeiro (a dona) não está a todo momento disponível e algumas confirmações atrasam, temos que, em muitos caso, confiar no comprovante que o cliente apresenta.

Um meio de validação simples permitiria a criação de diversas soluções para a confirmação do pagamento por entes não envolvidos diretamente na transação, como o vendedor de uma loja. Mostrar parcialmente os dados do pagador e recebedor,além da hora da transação facilitaria muito a consulta, além de que essas informações não precisariam ficar armazenadas por muito tempo, 1 hora seria mais que o sufienete para auxiliar diversas empresas de todo o país.

Entretanto eu estou na ponta que sofre e não na ponta que pode solucionar este problema.

[rubenskuhl]

Só quem está na linha de frente consegue enxegar a real dimensão do problema. Na empresa em que trabalho 5 vendedores recebem pix a todo momento, o financeiro (a dona) não está a todo momento disponível e algumas confirmações atrasam, temos que, em muitos caso, confiar no comprovante que o cliente apresenta.

Um meio de validação simples permitiria a criação de diversas soluções para a confirmação do pagamento por entes não envolvidos diretamente na transação, como o vendedor de uma loja. Mostrar parcialmente os dados do pagador e recebedor,além da hora da transação facilitaria muito a consulta, além de que essas informações não precisariam ficar armazenadas por muito tempo, 1 hora seria mais que o sufienete para auxiliar diversas empresas de todo o país.

Entretanto eu estou na ponta que sofre e não na ponta que pode solucionar este problema.

Este repositório tem justamente a solução desse problema, a API Pix. Ela é um pouco mais trabalhosa do que seria um eventual comprovante validável como o sugerido neste issue, mas está disponível em vários prestadores, vide #76 .

[aquinoyurii]

Só quem está na linha de frente consegue enxegar a real dimensão do problema. Na empresa em que trabalho 5 vendedores recebem pix a todo momento, o financeiro (a dona) não está a todo momento disponível e algumas confirmações atrasam, temos que, em muitos caso, confiar no comprovante que o cliente apresenta.

Um meio de validação simples permitiria a criação de diversas soluções para a confirmação do pagamento por entes não envolvidos diretamente na transação, como o vendedor de uma loja. Mostrar parcialmente os dados do pagador e recebedor,além da hora da transação facilitaria muito a consulta, além de que essas informações não precisariam ficar armazenadas por muito tempo, 1 hora seria mais que o sufienete para auxiliar diversas empresas de todo o país.

Entretanto eu estou na ponta que sofre e não na ponta que pode solucionar este problema.

Se ainda continuar com este problema consigo te ajudar

[dotterbrasil]

Só quem está na linha de frente consegue enxegar a real dimensão do problema. Na empresa em que trabalho 5 vendedores recebem pix a todo momento, o financeiro (a dona) não está a todo momento disponível e algumas confirmações atrasam, temos que, em muitos caso, confiar no comprovante que o cliente apresenta.

Um meio de validação simples permitiria a criação de diversas soluções para a confirmação do pagamento por entes não envolvidos diretamente na transação, como o vendedor de uma loja. Mostrar parcialmente os dados do pagador e recebedor,além da hora da transação facilitaria muito a consulta, além de que essas informações não precisariam ficar armazenadas por muito tempo, 1 hora seria mais que o sufienete para auxiliar diversas empresas de todo o país.

Entretanto eu estou na ponta que sofre e não na ponta que pode solucionar este problema.

@Ferreira-Jefferson , você tem razão.

Uma forma de simplificar o seu processo é adotar um identificador único de cada transação e inseri-lo o QRCode Pix.

Este identificador aparece no comprovante de quem efetuou o pagamento e simplifica muito a conferência (mesmo offline) do recebimento.

O ideal é utilizar conceitos de serialização de segurança (identificados alfanumérico aleatório com dígito verificador, para dificultar eventuais tentativas de fraude).

Existem soluções de geradores de código QR Pix que fazem isso tudo automaticamente.

[mateusmed]

Olá pessoal, algum progresso sobre isso? Me deparei com esse problema também, se podemos gerar um código de pagamento com base nas chaves, sabemos que quem faz a transferencia são os meios de pagamentos que tem autorização para tal, mas deveria ser um direito conseguir garantir a integridade da transação, pelo menos se o e2e id é valido.

[rubenskuhl]

Olá pessoal, algum progresso sobre isso? Me deparei com esse problema também, se podemos gerar um código de pagamento com base nas chaves, sabemos que quem faz a transferencia são os meios de pagamentos que tem autorização para tal, mas deveria ser um direito conseguir garantir a integridade da transação, pelo menos se o e2e id é valido.

Tudo que é um direito está no regulamento do Pix como requisito, e isso não consta lá.

É possível garantir isso através da API Pix, o que não há é um mecanismo out-of-band para isso.