[Dúvida] no [LGPD] - Como fica o Pix com a LGPD?

[feinstein]

Segundo a LGPD não podemos armazenar os dados dos clientes sem o consentimento deles.

Pela API Pix, ao receber os dados de um Pix, recebemos o nome completo e o CPF de um cliente.

A transação Pix com a loja já seria considerada como um "aceite", onde o usuário entende que está entregando esses dados pessoais a serem armazenados em algum sistema de rastreamento de transações financeiras da loja?

Me refiro mais a lojas físicas, restaurantes e etc. Onde não há um fluxo de cadastro para se pagar o produto.

[ninrod]

@feinstein , já era uma questão mapeada, estamos ajustando para a próxima release.

[feinstein]

Você pode me dar um preview do que vai ser? Apenas para eu poder modelar meu banco de dados de acordo.

[ninrod]

o pix.pagador seria removido.

[rubenskuhl]

o pix.pagador seria removido.

Sempre ou só no caso de pagamentos não ligados a cobranças ?

[rturk]

@ninrod em uma primeira análise discordo com remoção do Pix.Pagador. Me parece que isto tornaria o Pix inferior ao padrão que já existe com TED, DOC.

Importante considerar que a LGPD tem dispositivos bem claros sobre para transações financeiras e para pagamentos. Nestas é permitido conhecer os dados da outra parte, até porque estes dados são importantes para atender outras obrigações como exemplo obrigações fiscais.

Em suma recomendo que temas envolvendo LGPD devem ter um embasamento jurídico, considerando que o padrão Pix não deveria ser inferior ao que já existe com por exemplo TED, DOC.

[rturk]

@feinstein

Segundo a LGPD não podemos armazenar os dados dos clientes sem o consentimento deles.

Correto porém incompleto, você é obrigado a armazenar os dados de clientes ao emitir Nfes e pagamentos, inclusive empresas são obrigadas a armazenar estes dados. Por exemplo para atender SPED fiscal. Neste contexto à luz da LGPD estes dados possivelmente são esperados.

Recomendo que este tema seja analisado com o devido embasamento jurídico.

[feinstein]

@rturk excelente. Realmente eu desconheço a LGPD em profundidade. Se realmente possui embasamento jurídico então não vejo porque remover. No máximo poderia se manter com uma máscaras ***.123.456-**, assim como no manual do DICT, mas sendo previsto na LGPD então não vejo razão para a remoção e deve ser transmitido em sua integralidade, sem máscara.

[ninrod]

Ok Pessoal. Vamos levar em consideração as informações colocadas aqui.

[ninrod]

Sempre ou só no caso de pagamentos não ligados a cobranças ?

Sempre.

Qual seria o problema de negócio? @rubenskuhl

[rubenskuhl]

Sempre ou só no caso de pagamentos não ligados a cobranças ?

Sempre.

Qual seria o problema de negócio? @rubenskuhl

Impedir reconhecimento do pagador para transferências iniciadas pelo pagador com valor escolhido por ele, por exemplo em recarga de sistemas pré-pagos. Há sistemas que hoje sem que o pagador precise acessar qualquer site ou aplicativo, ele faz uma transferência e isso já lhe dá créditos (de valor não pré-determinado, à escolha do pagador) num determinado sistema associado a essa conta destino. Como já comentado, a TED tem hoje esse recurso, e ele é usado por exemplo nas corretoras para só permitir depósitos a partir de contas do titular da carteira de investimento.

Fora o fato de que a LGPD não impede o envio da informação, o que mais preocupa é remover a possibilidade de envio da informação. Há pessoas que prefeririam não enviar, há aquelas que não veem problema desde que isso tenha uma finalidade.

[ninrod]

Impedir reconhecimento do pagador para transferências iniciadas pelo pagador com valor escolhido por ele, por exemplo em recarga de sistemas pré-pagos. Há sistemas que hoje sem que o pagador precise acessar qualquer site ou aplicativo, ele faz uma transferência e isso já lhe dá créditos (de valor não pré-determinado, à escolha do pagador) num determinado sistema associado a essa conta destino. Como já comentado, a TED tem hoje esse recurso, e ele é usado por exemplo nas corretoras para só permitir depósitos a partir de contas do titular da carteira de investimento.

Você não consegue emitir uma cobrança atrelada a um txid e associar o pagamento eventual à conta pré-paga específica?

[rturk]

Você não consegue emitir uma cobrança atrelada a um txid e associar o pagamento eventual à conta pré-paga específica?

@ninrod Não recomendo, pode ser uma porta para lavagem de dinheiro exemplo:

Gero um QRCode com uma transação que eu espero que será cobrado da pessoa A, mas quem paga é B. Eu como recebedor vou assumir que quem pagou foi A quando na verdade foi B.

Lembrando que empresas são obrigadas (através de outros dispositivos legais) a saber as origem dos recursos e poder rastrear estes recursos. Isto vale em várias regulamentações, como na esfera fiscal ou até mesmo KYC.

Vou recomendar adicionar outro stakeholder nesta discussão, além do jurídico, já citado acima. Acredito ser importante time de prevenção à fraudes também ser consultado. Menos dados, tradicionalmente implica em mais ambiguidade e maior margem para erros ou fraudes.

Conforme já mencionei antes, parece prematuro reduzir dados de transações, quando estes são fundamentais para outras esferas fiscais, contábeis, segurança do sistema financeiro, prevenção à fraude, etc

[rubenskuhl]

Impedir reconhecimento do pagador para transferências iniciadas pelo pagador com valor escolhido por ele, por exemplo em recarga de sistemas pré-pagos. Há sistemas que hoje sem que o pagador precise acessar qualquer site ou aplicativo, ele faz uma transferência e isso já lhe dá créditos (de valor não pré-determinado, à escolha do pagador) num determinado sistema associado a essa conta destino. Como já comentado, a TED tem hoje esse recurso, e ele é usado por exemplo nas corretoras para só permitir depósitos a partir de contas do titular da carteira de investimento.

Você não consegue emitir uma cobrança atrelada a um txid e associar o pagamento eventual à conta pré-paga específica?

Uma cobrança tem valor específico, e nesse caso não se sabe o valor a priori. O quanto o usuário quiser carregar no pré-pago, ele pode. O mesmo vale para corretoras (que poderiam estar no Pix como correntista, como participante se houver um banco no grupo).

[dmkamers]

@rubenskuhl a conciliação feita com base no nome e CPF significa que o recebedor já tem a priori essa informação. Ele pode fazer, sem problema, seja consultando com base no CPF, seja usando a forma que já existe (onde consulta se ocorreu um pagamento via TED por exemplo - e que certamente envolve um acordo com o banco que fornece a informação).

@rturk o recebedor (titular da conta que recebeu o deposito) sabe quem depositou. Não se trata de excluir a informação do fluxo. Ao contrário, o fluxo permanece absolutamente inalterado. Não abre nenhuma possibilidade de 'lavagem' por exemplo.

Nos atendo especificamente à duvida do @feinstein, que é muito pertinente, o 'cliente' da API Pix estaria recebendo uma informação que não pediu, e teria a responsabilidade de garantir que ela será devidamente descartada, ou arcar com as consequências de ocorrer vazamento ou uso indevido, por exemplo.

[dmkamers]

@feinstein

Segundo a LGPD não podemos armazenar os dados dos clientes sem o consentimento deles.

Correto porém incompleto, você é obrigado a armazenar os dados de clientes ao emitir Nfes e pagamentos, inclusive empresas são obrigadas a armazenar estes dados. Por exemplo para atender SPED fiscal. Neste contexto à luz da LGPD estes dados possivelmente são esperados.

Recomendo que este tema seja analisado com o devido embasamento jurídico.

@rturk quais informações as empresas são obrigadas a guardar? Quais desses dados os clientes são obrigados a fornecer? E, se são obrigados a fornecer, fazem isso sem consentimento (de forma 'automática')?

[feinstein]

@dmkamers mas nem sempre o recebedor sabe quem depositou, pense numa caixa de supermercado por exemplo, ou o garçom de um bar.

[dmkamers]

@dmkamers mas nem sempre o recebedor sabe quem depositou, pense numa caixa de supermercado por exemplo, ou o garçom de um bar.

Exato, nem nunca, eu diria. Ele não sabe, e nem deve saber. Podes desenvolver melhor? Note, ele vai conciliar, sem problemas. Nada muda. Inclusive o lojista pode pesquisar pelo pagamento específico, SE o cliente fornecer o CPF e pedir por isso (o que por si só não autoriza o lojista a 'guardar' essa informação - mas, se o fizer, será por decisão própria).

[dmkamers]

Sempre ou só no caso de pagamentos não ligados a cobranças ?

Sempre. Qual seria o problema de negócio? @rubenskuhl

Impedir reconhecimento do pagador para transferências iniciadas pelo pagador com valor escolhido por ele, por exemplo em recarga de sistemas pré-pagos. Há sistemas que hoje sem que o pagador precise acessar qualquer site ou aplicativo, ele faz uma transferência e isso já lhe dá créditos (de valor não pré-determinado, à escolha do pagador) num determinado sistema associado a essa conta destino. Como já comentado, a TED tem hoje esse recurso, e ele é usado por exemplo nas corretoras para só permitir depósitos a partir de contas do titular da carteira de investimento.

Fora o fato de que a LGPD não impede o envio da informação, o que mais preocupa é remover a possibilidade de envio da informação. Há pessoas que prefeririam não enviar, há aquelas que não veem problema desde que isso tenha uma finalidade.

@rubenskuhl nos casos em que o pagador precisa informar algo (ou isso convém ao recebedor), já existe provisão na API. Neste caso, supostamente o recebedor informa o pagador a priori da necessidade, propósito, e escopo dessa informação. Ele pode gerar a cobrança usando o campo 'solicitacaoPagador', e receber a informação no campo 'infoPagador'.

[rubenskuhl]

@rubenskuhl a conciliação feita com base no nome e CPF significa que o recebedor já tem a priori essa informação. Ele pode fazer, sem problema, seja consultando com base no CPF, seja usando a forma que já existe (onde consulta se ocorreu um pagamento via TED por exemplo - e que certamente envolve um acordo com o banco que fornece a informação).

Se isso estiver especificado na API Pix para que, se fornecida, seja dessa forma, parece razoável. Quem tem uso para essa informação pode pedir para o PSP que envie tal informação, e assume a gestão do ciclo de vida da informação fornecida. O que não acho bom seria ter essa informação apenas através de outra API proprietária.

[rubenskuhl]

@rubenskuhl nos casos em que o pagador precisa informar algo (ou isso convém ao recebedor), já existe provisão na API. Neste caso, supostamente o recebedor informa o pagador a priori da necessidade, propósito, e escopo dessa informação. Ele pode gerar a cobrança usando o campo 'solicitacaoPagador', e receber a informação no campo 'infoPagador'.

Uma informação preenchida pelo pagador não atende a muitos desses casos de uso. Só o que efetivamente atende é que seja a informação validada pela IF/IP como parte do KYC.

[dmkamers]

@rubenskuhl a conciliação feita com base no nome e CPF significa que o recebedor já tem a priori essa informação. Ele pode fazer, sem problema, seja consultando com base no CPF, seja usando a forma que já existe (onde consulta se ocorreu um pagamento via TED por exemplo - e que certamente envolve um acordo com o banco que fornece a informação).

Se isso estiver especificado na API Pix para que, se fornecida, seja dessa forma, parece razoável. Quem tem uso para essa informação pode pedir para o PSP que envie tal informação, e assume a gestão do ciclo de vida da informação fornecida. O que não acho bom seria ter essa informação apenas através de outra API proprietária.

Está sim. A solicitacaoPagador é indicada na cobrança. A infoPagador deve ser colhida pelo PSP pagador e transita na mensagem de pagamento, até o PSP recebedor. Esta informação está disponível no Pix recebido.

[rubenskuhl]

@rubenskuhl a conciliação feita com base no nome e CPF significa que o recebedor já tem a priori essa informação. Ele pode fazer, sem problema, seja consultando com base no CPF, seja usando a forma que já existe (onde consulta se ocorreu um pagamento via TED por exemplo - e que certamente envolve um acordo com o banco que fornece a informação).

Se isso estiver especificado na API Pix para que, se fornecida, seja dessa forma, parece razoável. Quem tem uso para essa informação pode pedir para o PSP que envie tal informação, e assume a gestão do ciclo de vida da informação fornecida. O que não acho bom seria ter essa informação apenas através de outra API proprietária.

Está sim. A solicitacaoPagador é indicada na cobrança. A infoPagador deve ser colhida pelo PSP pagador e transita na mensagem de pagamento, até o PSP recebedor. Esta informação está disponível no Pix recebido.

Como eu disse acima, isso não atende. Não pode ser informação que o pagador tem arbitrariedade de preenchimento.

[feinstein]

@dmkamers bom, eu não sou especialista em combate a lavagem de dinheiro, mas o argumento do @rturk me pareceu bem pertinente.

[dmkamers]

@dmkamers bom, eu não sou especialista em combate a lavagem de dinheiro, mas o argumento do @rturk me pareceu bem pertinente.

O pagador está identificado, não há problema algum.

[feinstein]

Não em um QR Code estático.

[dmkamers]

@rubenskuhl a conciliação feita com base no nome e CPF significa que o recebedor já tem a priori essa informação. Ele pode fazer, sem problema, seja consultando com base no CPF, seja usando a forma que já existe (onde consulta se ocorreu um pagamento via TED por exemplo - e que certamente envolve um acordo com o banco que fornece a informação).

Se isso estiver especificado na API Pix para que, se fornecida, seja dessa forma, parece razoável. Quem tem uso para essa informação pode pedir para o PSP que envie tal informação, e assume a gestão do ciclo de vida da informação fornecida. O que não acho bom seria ter essa informação apenas através de outra API proprietária.

Está sim. A solicitacaoPagador é indicada na cobrança. A infoPagador deve ser colhida pelo PSP pagador e transita na mensagem de pagamento, até o PSP recebedor. Esta informação está disponível no Pix recebido.

Como eu disse acima, isso não atende. Não pode ser informação que o pagador tem arbitrariedade de preenchimento.

@rubenskuhl a unica informação nesta linha é o 'endToEndId', de conhecimento do PSP recebedor. Se há necessidade de correlacionar esta informação com um pagador em particular, certamente isso só se faz com um propósito e escopo previamente estabelecido entre quem acessa e o PSP recebedor. Note: o dono da conta pode ter acesso ao nome e CPF de quem depositou, não há problema algum aí. O que não existe é uma forma automatizada e irrestrita de obter essa informação. Se quiser detalhar algum caso de uso específico, se avalia. Se for o caso, se trataria de uma autorização específica na API, com este escopo. Algo entre a corretora e o PSP (pegando o seu exemplo), em que foi previamente estabelecido que pagamentos recebidos neste contexto pressupõe o fornecimento (e concordância) de determinadas informações pelos pagadores.

[dmkamers]

Não em um QR Code estático.

Sim, continua identificado. Quem recebe, sabe, sempre, quem pagou. Não entendi bem sua dúvida.

[dmkamers]

@rubenskuhl nos casos em que o pagador precisa informar algo (ou isso convém ao recebedor), já existe provisão na API. Neste caso, supostamente o recebedor informa o pagador a priori da necessidade, propósito, e escopo dessa informação. Ele pode gerar a cobrança usando o campo 'solicitacaoPagador', e receber a informação no campo 'infoPagador'.

Uma informação preenchida pelo pagador não atende a muitos desses casos de uso. Só o que efetivamente atende é que seja a informação validada pela IF/IP como parte do KYC.

Rubens, me parece que este caso de uso se trata de uma tentativa de 'autenticação baseada em pagamento'. Seja qual for o propósito desta autenticação, ela tem que estar previamente comunicada e estabelecida, por acordo, com o pagador eventual. Neste caso específico, para ser implementado via Pix, a solução é o pagador informar o endToEndId do pagamento, dando condições para que o recebedor verifique e concilie no respectivo recebimento. Se o recebedor já sabe 'de quem' está esperando o pagamento, ele já sabe nome e CPF e nada do que foi discutido aqui importa. Esteja à vontade para descrever um caso de uso em particular, específico, e se avalia. Deve passar por algum tipo de acordo ou autorização específica na API para que a informação seja obtida. Em nenhum caso se vislumbra a 'autorização automática' mencionada pelo @feinstein nesta issue, pelo simples fato de efetivar um Pix.

[feinstein]

A meu ver num QR Code estático, na frente de um caixa de supermercado, numa máquina de refrigerante automática, ou para acionar uma máquina de lavar em um lavanderia (pun intended) várias pessoas podem usar o mesmo QR Code, com ou sem txid. Logo, o dono do estabelecimento não tem como saber quem é que fez uma transação.

Imagino um estabelecimento com QR Codes estáticos em volta de um produto com preço fixo, fica ainda mais difícil controlar quais clientes pagaram e quais não pagaram pelo produto, para o caixa liberar a saída do cliente com o produto. Mas se tiver um CPF, a loja pode facilmente cruzar as informações dos Pix com os clientes dentro da loja, seja vendo a carteira de motorista, ou vendo o App da loja.

Portanto, se realmente a LGPD contempla o caso de armazenamento de CPF e Nome para fins financeiros, eu vejo validade em se manter isso para ajudar no uso de QR Codes estáticos.

[dmkamers]

A meu ver num QR Code estático, na frente de um caixa de supermercado, numa máquina de refrigerante automática, ou para acionar uma máquina de lavar em um lavanderia (pun intended) várias pessoas podem usar o mesmo QR Code, com ou sem txid. Logo, o dono do estabelecimento não tem como saber quem é que fez uma transação.

Imagino um estabelecimento com QR Codes estáticos em volta de um produto com preço fixo, fica ainda mais difícil controlar quais clientes pagaram e quais não pagaram pelo produto, para o caixa liberar a saída do cliente com o produto. Mas se tiver um CPF, a loja pode facilmente cruzar as informações dos Pix com os clientes dentro da loja, seja vendo a carteira de motorista, ou vendo o App da loja.

@feinstein e como comprador, se eu me recusar a apresentar a carteira de motorista ou informar meu CPF, serei impedido de adquirir a mercadoria? Para operar com QRs estáticos, estamos falando em pequenos volumes, não se trata de API Pix. A conciliação é pelo txId. Identificado um recebimento com este txId, o cliente tem que ser liberado. Não há requisito de 'autenticação' do cliente.

[rubenskuhl]

@rubenskuhl nos casos em que o pagador precisa informar algo (ou isso convém ao recebedor), já existe provisão na API. Neste caso, supostamente o recebedor informa o pagador a priori da necessidade, propósito, e escopo dessa informação. Ele pode gerar a cobrança usando o campo 'solicitacaoPagador', e receber a informação no campo 'infoPagador'.

Uma informação preenchida pelo pagador não atende a muitos desses casos de uso. Só o que efetivamente atende é que seja a informação validada pela IF/IP como parte do KYC.

Rubens, me parece que este caso de uso se trata de uma tentativa de 'autenticação baseada em pagamento'. Seja qual for o propósito desta autenticação, ela tem que estar previamente comunicada e estabelecida, por acordo, com o pagador eventual.

Mas se a informação não chegar, não tem como um acordo com o pagador eventual ser honrado. No mínimo o pagador precisar ter no app do PSP pagador a opção de fornecer a identificação ao destinatário do Pix; aí se o Pix chegar sem identificação requerida, ou se a identificação não for de um cliente que possa fazer isso, o EC pode devolver o Pix. (Em alguns casos ele seria obrigado por outras regulações a fazer isso, como no caso de corretoras)

[rubenskuhl]

Para operar com QRs estáticos, estamos falando em pequenos volumes, não se trata de API Pix. A conciliação é pelo txId. Identificado um recebimento com este txId, o cliente tem que ser liberado. Não há requisito de 'autenticação' do cliente.

QR-Code estáticos e API Pix não são excludentes. A API Pix tem informação de estáticos com TxID, tanto via webhook quanto via GET, e de estáticos sem TxID, aí só via GET.

[feinstein]

@feinstein e como comprador, se eu me recusar a apresentar a carteira de motorista ou informar meu CPF, serei impedido de adquirir a mercadoria? Para operar com QRs estáticos, estamos falando em pequenos volumes, não se trata de API Pix. A conciliação é pelo txId. Identificado um recebimento com este txId, o cliente tem que ser liberado. Não há requisito de 'autenticação' do cliente.

Mas um QR Code estático impresso num papel vai ter o mesmo txid para centenas de clientes. O txid ajuda a falar que um refrigerante foi vendido, mas não pra qual cliente.

Imagine um supermercado automatizado, cada produto tem um QR Code, o cliente entra e paga tudo e sai da loja. Pode haver um funcionário do supermercado que verifica se tudo na sacola do cliente está de acordo com o sistema e nada foi roubado. Se o webhook transmitir o CPF, o App do supermercado pode cruzar a informação dos itens que o cliente comprou. Sem o CPF o supermercado não tem como saber se o que ta naquela bolsa é o que o cliente comprou ou se ele está levando algo sem pagar.

[dmkamers]

@rubenskuhl nos casos em que o pagador precisa informar algo (ou isso convém ao recebedor), já existe provisão na API. Neste caso, supostamente o recebedor informa o pagador a priori da necessidade, propósito, e escopo dessa informação. Ele pode gerar a cobrança usando o campo 'solicitacaoPagador', e receber a informação no campo 'infoPagador'.

Uma informação preenchida pelo pagador não atende a muitos desses casos de uso. Só o que efetivamente atende é que seja a informação validada pela IF/IP como parte do KYC.

Rubens, me parece que este caso de uso se trata de uma tentativa de 'autenticação baseada em pagamento'. Seja qual for o propósito desta autenticação, ela tem que estar previamente comunicada e estabelecida, por acordo, com o pagador eventual.

Mas se a informação não chegar, não tem como um acordo com o pagador eventual ser honrado. No mínimo o pagador precisar ter no app do PSP pagador a opção de fornecer a identificação ao destinatário do Pix; aí se o Pix chegar sem identificação requerida, ou se a identificação não for de um cliente que possa fazer isso, o EC pode devolver o Pix. (Em alguns casos ele seria obrigado por outras regulações a fazer isso, como no caso de corretoras)

@rubenskuhl o recebedor sempre tem a 'identificação' do pagador. Para tê-la via API Pix, o 'cliente da API' tem que ter estabelecido um propósito, e isto é entre ele 'cliente da API Pix' e o PSP recebedor. Novamente, mesmo via API ele 'cliente da API' continua sabendo se um determinado pagador efetivou um Pix ou não, se ele conhece o CPF deste pagador. Não entendi o problema. Comentei antes: se este for um cenário (autenticação via pagamento), certamente será uma feature a ser incluída, com autorização específica (escopo), e não por default.

[dmkamers]

@feinstein e como comprador, se eu me recusar a apresentar a carteira de motorista ou informar meu CPF, serei impedido de adquirir a mercadoria? Para operar com QRs estáticos, estamos falando em pequenos volumes, não se trata de API Pix. A conciliação é pelo txId. Identificado um recebimento com este txId, o cliente tem que ser liberado. Não há requisito de 'autenticação' do cliente.

Mas um QR Code estático impresso num papel vai ter o mesmo txid para centenas de clientes. O txid ajuda a falar que um refrigerante foi vendido, mas não pra qual cliente.

Imagine um supermercado automatizado, cada produto tem um QR Code, o cliente entra e paga tudo e sai da loja. Pode haver um funcionário do supermercado que verifica se tudo na sacola do cliente está de acordo com o sistema e nada foi roubado. Se o webhook transmitir o CPF, o App do supermercado pode cruzar a informação dos itens que o cliente comprou. Sem o CPF o supermercado não tem como saber se o que ta naquela bolsa é o que o cliente comprou ou se ele está levando algo sem pagar.

@feinstein neste caso o mercado deve colocar um aviso apropriado na porta de que só vende mercadorias a compradores identificados por nome e CPF, e na conferência, ao obter nome e CPF da pessoa, pode consultar a API Pix (pelo CPF, que já foi fornecido pelo comprador) e confirmar que ocorreu um pagamento, de determinado valor (ou n pagamentos, que totalizam o mesmo numero de itens e valor aproximado da sacola).

[feinstein]

Sim, mas fica mais burocrático, se a LGPD não vê problema nisso, eu acho uma informação válida a ser transmitida a cada Pix.

[rubenskuhl]

@rubenskuhl o recebedor sempre tem a 'identificação' do pagador. Para tê-la via API Pix, o 'cliente da API' tem que ter estabelecido um propósito, e isto é entre ele 'cliente da API Pix' e o PSP recebedor. Novamente, mesmo via API ele 'cliente da API' continua sabendo se um determinado pagador efetivou um Pix ou não, se ele conhece o CPF deste pagador. Não entendi o problema. Comentei antes: se este for um cenário (autenticação via pagamento), certamente será uma feature a ser incluída, com autorização específica (escopo), e não por default.

Eu acredito que haja tanto o caso de autenticação via pagamento quanto o de pagamento que requer que o efetivo pagador seja determinada pessoa ou empresa. Me parece que eles sejam parecidos o suficiente para que seja um único caso de uso na API.

[rubenskuhl]

Imagine um supermercado automatizado, cada produto tem um QR Code, o cliente entra e paga tudo e sai da loja. Pode @feinstein neste caso o mercado deve colocar um aviso apropriado na porta de que só vende mercadorias a compradores identificados por nome e CPF, e na conferência, ao obter nome e CPF da pessoa, pode consultar a API Pix (pelo CPF, que já foi fornecido pelo comprador) e confirmar que ocorreu um pagamento, de determinado valor (ou n pagamentos, que totalizam o mesmo numero de itens e valor aproximado da sacola).

Se eu entendi direito, isso significa que um GET na API com filtro de CPF só pode retornar um Pix se o efetivo pagador for mesmo o CPF em questão, e tem que retornar inexistente se o efetivo pagador não for o CPF em questão ? Se sim, isso permite validar se quem pagou era quem era esperado que pagasse, e isso permite fazer a checagem apesar da ausência do parâmetro na informação do Pix recebido. (Notar que não estamos falando do CPF na cobrança)

[dmkamers]

Sim, mas fica mais burocrático, se a LGPD não vê problema nisso, eu acho uma informação válida a ser transmitida a cada Pix.

@feinstein exigir nome e CPF como condicionante para uma venda é ilegal, exceto em casos específicos. Meu exemplo foi uma 'redução ao absurdo' apenas para tornar o argumento evidente. Nem tem relação com a LGPD, mas se quiser entrar nesta linha, o que alguns colegas sugeriram é que haveria 'brechas' na LGPD para permitir que um recebedor obtenha estes dados 'para fins financeiros'. Desconheço e, se houverem, tem que ser tratadas em cenário específico da API (e não 'por default').

[dmkamers]

@rubenskuhl o recebedor sempre tem a 'identificação' do pagador. Para tê-la via API Pix, o 'cliente da API' tem que ter estabelecido um propósito, e isto é entre ele 'cliente da API Pix' e o PSP recebedor. Novamente, mesmo via API ele 'cliente da API' continua sabendo se um determinado pagador efetivou um Pix ou não, se ele conhece o CPF deste pagador. Não entendi o problema. Comentei antes: se este for um cenário (autenticação via pagamento), certamente será uma feature a ser incluída, com autorização específica (escopo), e não por default.

Eu acredito que haja tanto o caso de autenticação via pagamento quanto o de pagamento que requer que o efetivo pagador seja determinada pessoa ou empresa. Me parece que eles sejam parecidos o suficiente para que seja um único caso de uso na API.

Perfeito, ambos são possíveis. Ambos requerem identificação prévia do pagador (e consentimento), portanto a consulta é possível via API, com base em algo que o recebedor já conhece (identificação), que antecede a autenticação. Se o recebedor receber neste contexto um Pix para o qual desconhece a identificação, ele deveria devolver.

[dmkamers]

Imagine um supermercado automatizado, cada produto tem um QR Code, o cliente entra e paga tudo e sai da loja. Pode @feinstein neste caso o mercado deve colocar um aviso apropriado na porta de que só vende mercadorias a compradores identificados por nome e CPF, e na conferência, ao obter nome e CPF da pessoa, pode consultar a API Pix (pelo CPF, que já foi fornecido pelo comprador) e confirmar que ocorreu um pagamento, de determinado valor (ou n pagamentos, que totalizam o mesmo numero de itens e valor aproximado da sacola).

Se eu entendi direito, isso significa que um GET na API com filtro de CPF só pode retornar um Pix se o efetivo pagador for mesmo o CPF em questão, e tem que retornar inexistente se o efetivo pagador não for o CPF em questão ? Se sim, isso permite validar se quem pagou era quem era esperado que pagasse, e isso permite fazer a checagem apesar da ausência do parâmetro na informação do Pix recebido. (Notar que não estamos falando do CPF na cobrança)

Exato, um GET de Pix por CPF 'do pagador' volta todos os Pix que 'batem' com este CPF de pagador, logicamente. Isso já era assim, e continua assim. Se você já sabe o CPF, não há problema algum. Mas, de fato, a documentação não deixa claro que o CPF da consulta é do efetivo pagador. Se fosse do 'devedor' (pagador 'esperado') teria que ser uma consulta por cobranças, mas acredito que vale a pena esclarecer, e até incluir a opção se for o caso.

EDIT: não parece fazer sentido pesquisar por 'devedor' (em /pix); então, sim, o CPF/CNPJ é do efetivo pagador, neste GET. Não existe um 'devedor esperado' em um Pix recebido. Aliás, colocar esta informação no próprio txId em um QR estático não deixa de ser uma possibilidade (mas é por conta e risco de quem o fizer).

[rubenskuhl]

Imagine um supermercado automatizado, cada produto tem um QR Code, o cliente entra e paga tudo e sai da loja. Pode @feinstein neste caso o mercado deve colocar um aviso apropriado na porta de que só vende mercadorias a compradores identificados por nome e CPF, e na conferência, ao obter nome e CPF da pessoa, pode consultar a API Pix (pelo CPF, que já foi fornecido pelo comprador) e confirmar que ocorreu um pagamento, de determinado valor (ou n pagamentos, que totalizam o mesmo numero de itens e valor aproximado da sacola).

Se eu entendi direito, isso significa que um GET na API com filtro de CPF só pode retornar um Pix se o efetivo pagador for mesmo o CPF em questão, e tem que retornar inexistente se o efetivo pagador não for o CPF em questão ? Se sim, isso permite validar se quem pagou era quem era esperado que pagasse, e isso permite fazer a checagem apesar da ausência do parâmetro na informação do Pix recebido. (Notar que não estamos falando do CPF na cobrança)

Exato, um GET de Pix por CPF 'do pagador' volta todos os Pix que 'batem' com este CPF de pagador, logicamente. Isso já era assim, e continua assim. Se você já sabe o CPF, não há problema algum. Mas, de fato, a documentação não deixa claro que o CPF da consulta é do efetivo pagador. Se fosse do 'devedor' (pagador 'esperado') teria que ser uma consulta por cobranças, mas acredito que vale a pena esclarecer, e até incluir a opção se for o caso.

Isso resolve um dos casos que é do pagamento solicitado que deva ser feito pela própria entidade. Mas no caso que citei de uma corretora, ela precisaria fazer uma requisição para cada um de seus clientes ciclicamente para saber se houve algum Pix de algum cliente para depositar na conta da corretora. O mesmo vale para um sistema pré-pago. Ambos precisariam de um botão "Fiz um Pix, reconheça por favor", coisa que a TED hoje não precisa. Então o Pix precisa sim em sua agenda evolutiva de um caminho fim-a-fim para essa informação. Ainda me parece uma pena que isso seja removido da versão de lançamento, ampliando o feature gap para outros meios de pagamento ao invés de diminuir, mas é uma escolha.

[dmkamers]

Imagine um supermercado automatizado, cada produto tem um QR Code, o cliente entra e paga tudo e sai da loja. Pode @feinstein neste caso o mercado deve colocar um aviso apropriado na porta de que só vende mercadorias a compradores identificados por nome e CPF, e na conferência, ao obter nome e CPF da pessoa, pode consultar a API Pix (pelo CPF, que já foi fornecido pelo comprador) e confirmar que ocorreu um pagamento, de determinado valor (ou n pagamentos, que totalizam o mesmo numero de itens e valor aproximado da sacola).

Se eu entendi direito, isso significa que um GET na API com filtro de CPF só pode retornar um Pix se o efetivo pagador for mesmo o CPF em questão, e tem que retornar inexistente se o efetivo pagador não for o CPF em questão ? Se sim, isso permite validar se quem pagou era quem era esperado que pagasse, e isso permite fazer a checagem apesar da ausência do parâmetro na informação do Pix recebido. (Notar que não estamos falando do CPF na cobrança)

Exato, um GET de Pix por CPF 'do pagador' volta todos os Pix que 'batem' com este CPF de pagador, logicamente. Isso já era assim, e continua assim. Se você já sabe o CPF, não há problema algum. Mas, de fato, a documentação não deixa claro que o CPF da consulta é do efetivo pagador. Se fosse do 'devedor' (pagador 'esperado') teria que ser uma consulta por cobranças, mas acredito que vale a pena esclarecer, e até incluir a opção se for o caso.

Isso resolve um dos casos que é do pagamento solicitado que deva ser feito pela própria entidade. Mas no caso que citei de uma corretora, ela precisaria fazer uma requisição para cada um de seus clientes ciclicamente para saber se houve algum Pix de algum cliente para depositar na conta da corretora. O mesmo vale para um sistema pré-pago. Ambos precisariam de um botão "Fiz um Pix, reconheça por favor", coisa que a TED hoje não precisa. Então o Pix precisa sim em sua agenda evolutiva de um caminho fim-a-fim para essa informação. Ainda me parece uma pena que isso seja removido da versão de lançamento, ampliando o feature gap para outros meios de pagamento ao invés de diminuir, mas é uma escolha.

@rubenskuhl entendo o seu ponto. De fato, 'fiz um pix, me identifique' não existe aqui (por enquanto), e é algo que não existe na TED também (não para um terceiro). Existe para o titular da conta. Se existir via API, e a corretora certamente obtém estes dados via API, ela concordou em recebê-los (e o banco em fornecê-los) em contexto específico. Na API Pix, não é que seria algo impossível, mas teria que, no mínimo, ter o mesmo 'estabelecimento de contexto'. Então não é algo para ser entregue 'por default', muito menos para um pequeno integrador que não pediu essa informação (por exemplo). O eventual 'gap' é muito pequeno, mas exige alguma análise. Não justifica o risco para o recebedor 'normal'.

[feinstein]

Eu confesso já tinha esquematizado um sistema de fidelização, onde só por fazer um Pix o cliente do restaurante já estava cadastrado. Assim o garçom pode falar "essa é sua décima compra, está aqui uma sobremesa grátis". Sem a necessidade de se baixar um App do restaurante, escanear nota fiscal, nada.

Com essa remoção eu vejo uma perda para soluções inovadoras. Entendo o sentido, mas gostaria que fosse reconsiderado.

[dmkamers]

Eu confesso já tinha esquematizado um sistema de fidelização, onde só por fazer um Pix o cliente do restaurante já estava cadastrado. Assim o garçom pode falar "essa é sua décima compra, está aqui uma sobremesa grátis". Sem a necessidade de se baixar um App do restaurante, escanear nota fiscal, nada.

Com essa remoção eu vejo uma perda para soluções inovadoras. Entendo o sentido, mas gostaria que fosse reconsiderado.

@feinstein isso seria um 'cookie' de pagador. :) Cookies são indesejáveis por default. Perceba, exatamente pela LGPD, quem tem juízo já está avisando que usa cookies e obtendo consentimento do usuário.

[rubenskuhl]

@rubenskuhl entendo o seu ponto. De fato, 'fiz um pix, me identifique' não existe aqui (por enquanto), e é algo que não existe na TED também (não para um terceiro). Existe para o titular da conta. Se existir via API, e a corretora certamente obtém estes dados via API, ela concordou em recebê-los (e o banco em fornecê-los) em contexto específico.

Na API Pix, não é que seria algo impossível, mas teria que, no mínimo, ter o mesmo 'estabelecimento de contexto'. Então não é algo para ser entregue 'por default', muito menos para um pequeno integrador que não pediu essa informação (por exemplo). O eventual 'gap' é muito pequeno, mas exige alguma análise. Não justifica o risco para o recebedor 'normal'.

Aqui ainda estamos falando de client credential flow, então a informação que é fornecida, ou não fornecida, é para o EC. Se há um integrador, ele recebeu credenciais para representar o cliente como se tivesse uma procuração, não como um prestador de serviço.

O que existe na TED acontece tanto no extrato quanto via API, e como funcionário de uma empresa que faz isso várias vezes por dia com seus canais de venda e não via API, eu adianto que isso é prática comum de mercado na TED. E sim, a retirada disso vai manter vantagens da TED sobre o Pix e diminuir o potencial do Pix, ao menos neste momento.

[dmkamers]

@rubenskuhl nao entendi a relação com oauth. Sim, ele recebe autorização do EC pra operar na API Pix, isso não significa autorização dos pagadores para receber e armazenar qualquer dado pessoal. Eu devo ter me expressado mal antes, vamos deixar esse ponto pra lá, acredito que não é relevante. Sim, quando for possível via API (o 'pagamento autenticador'), está tudo certo, seja o EC diretamente, ou um terceiro autorizado (e aí o problema é entre eles).

Falando de TED: via 'extrato', ok, é sua conta (mesmo cenário aqui). Via API: o banco te dá a possibilidade de elencar todos os nomes e CPFs que já te pagaram alguma coisa em algum momento, mesmo aqueles que você sequer conhecia previamente? Ele faz isso por default, sem nenhuma contrapartida, limite, ou condição? Os pagadores estão cientes disso? Se alguma dessas respostas for sim, e quiseres compartilhar a fundamentação jurídica e porque isso não fere a LGDP (que é um cenário novo) podemos avaliar se é aplicável a pagamentos de varejo.

Por hora, me parece que há um 'caso de uso' claro que, sim, pode ser contemplado (não 'por default') na API Pix, que é o 'autenticação por pagamento' (sem 'identificação' prévia). Neste caso, certamente os pagadores deverão estar cientes das condições em que vão efetuar a operação (como ocorre em compras online, por exemplo). Infelizmente, parece ser um caso de uso 'contemplado' por acaso, até o momento (note que o pix.pagador é opcional). Como comentei, não ser o 'default' não significa que não pode ser facilmente implementado, após as análises devidas. Acho que a comunidade pode fundamentar e encaminhar às áreas de negócio a necessidade. Não é uma decisão a ser tomada no commit.

[feinstein]

@feinstein isso seria um 'cookie' de pagador. :) Cookies são indesejáveis por default. Perceba, exatamente pela LGPD, quem tem juízo já está avisando que usa cookies e obtendo consentimento do usuário.

Sim, eu ia pedir autorização por SMS durante o primeiro uso. O garçom perguntaria se o cliente quer se cadastrar, ele dá o número do celular e recebe um SMS com um link de confirmação. Eu ia ter permissão, mas agora nem adianta pq não tenho mais o dado.

[dmkamers]

@feinstein isso seria um 'cookie' de pagador. :) Cookies são indesejáveis por default. Perceba, exatamente pela LGPD, quem tem juízo já está avisando que usa cookies e obtendo consentimento do usuário.

Sim, eu ia pedir autorização por SMS durante o primeiro uso. O garçom perguntaria se o cliente quer se cadastrar, ele dá o número do celular e recebe um SMS com um link de confirmação. Eu ia ter permissão, mas agora nem adianta pq não tenho mais o dado.

Perfeito, com essa autorização, de alguma forma, a API Pix poderá prover essa funcionalidade. Se ele, já que está autorizando, informar o CPF, está tudo resolvido, você tem o dado. Tinha entendido que no cenário ias fazer isso 'sem pedir', automaticamente.

[feinstein]

Como seria essa "de alguma forma"?