renatofrota
commented
3 years ago Baseado em quê? Não sou PSP, não conheço a regulamentação em sua integralidade.
Manual de iniciação do Pix.
Observação: a notificação não se dá via API. É um request que parte deles para o meu sistema. O MP é que está me comunicando algo, não está [nem estariaria] me dando acesso à informações relativas ao sistema Pix por meio de nenhuma API.
É esse request para o seu sistema é uma chamada de API, não há outro nome para isso e o impacto regulatório é claro.
É o PSP acionando uma URL no meu sistema - a API é minha, não do PSP. Totalmente fora do escopo da regulação do Pix. Só vejo como um problema se o BACEN agora resolveu, de uma hora pra outra, proibir que os PSPs ofereçam serviços tecnológicos de quaisquer natureza que não a API Pix. :laughing:
Prezados, a discussão está interessante. É bastante informação, estou tentando acompanhar. Se vocês quiserem que eu responda algo em específico podem me marcar.
Respondendo alguns pontos:
@renatofrota
Podem me ajudar a entender, em detalhe, a proposta? Entendi que a proposta gira em torno de atribuir a uma cobrança uma URL específica para "notificação". Supondo 10M de cobranças, (há usuários recebedores que geram 10milhões de cobranças por mês), potencialmente, do ponto de vista do PSP recebedor, teria-se em mãos 10 milhões de URLs diferentes para notificar, respectivamente, cada uma destas cobranças. Entendi corretamente a proposta?
Se já está previsto um endpoint /webhook responsável por definir qual a URL que deverá ser notificada quando o PSP recebe um pagamento para aquele cliente que configurou o webhook, qual a diferença a URL ser única ou variável a cada cobrança? O número de requisições enviadas não muda.
Perfeito, mas o número de servers diferentes com os quais o PSP recebedor teria que se comunicar muda: de 1 por client_id para 1 por txid. A segurança da comunicação entre o PSP recebedor e estes inúmeros servers me preocupa. Como exatamente seria estabelecida a segurança na comunicação do PSP recebedor com esses N servers, na proposta apresentada aqui?
Eu não estou entendendo onde, exatamente, está a sua dúvida. Se o recebedor disser ao PSP "me avisa aqui nessa URL X quando cair um pagamento para a minha Chave Pix Y" e esta URL é servida via HTTPS, que diferença faz ela ser sempre a mesma, definida de forma completamente limitada por um endpoint específico, ou ela ser uma URL vinculada à Chave Pix ou à Cobrança?
Os requests serem enviados sempre para uma mesma URL, cito: https://sistema-a.recebedor.example.com/pixnotify; ou vezes para esta mas, sob determinadas circunstâncias (cobranças relacionadas às vendas realizadas através de um hotsite de uma campanha que tem uma duração limitada, por exemplo) para uma URL diferente, cito: https://hotsite-natal.recebedor.example.com/pixnotify, não faz a menor diferença do ponto de vista da segurança. Ambas são URLs com o mesmo caráter técnico.
E ressalto: hoje já é previsto o envio de notificações via webhook. Minha sugestão é que continue sendo uma requisição simples, com o único objetivo de notificar o recebedor, não que o PSP recebedor ou o BACEN colete ou processe qualquer informação presente nesta URL de notificação. Ademais, mudar o escopo da URL de webhook de um client_id para Chave Pix (podendo ser sobreposto na Cobrança) não faria qualquer diferença neste aspecto.
E, lembrando, não será necessariamente sempre diferente. O número de URLs diferentes não seria igual ao número de Cobranças, assim como não será necessariamente uma relação 1:1 com um txid. Pode ser, como no exemplo acima, uma URL de uso geral e, em casos pontuais, ser uma URL diferente.
De qualquer forma, explico melhor a intenção: o interesse em ter capacidade de sobrescrever a URL de notificação é para situações onde uma empresa atua em mais de um ramo (perfeitamente comum) e tem mais de um e-commerce e/ou mais de um sistema de cobrança (também muito comum) esta poder definir as URLs de notificação com base no sistema que é responsável pelo controle de liberação de serviços/pedidos sem ter, necessariamente, 2 contas de integração distintas com o PSP (o número de URLs seria, na maior parte das vezes, igual ao número de sistemas compartilhando aquela conta de integração) ou se forçar a ter uma URL única que servirá de "gateway" para encaminhar essas notificações a diferentes sistemas (gerando a necessidade de infra, processamento e requests totalmente desnecessários).
No contexto colocado aqui, versando sobre situações envolvendo empresas com mais de um sistema de cobrança, estabelecer diferentes client_ids par cada sistema de cobrança não resolveria a questão, uma vez que o usuário recebedor poderia estabelecer uma URL diferente por client_id?
No papel é lindo, mas mundo real não é tão simples assim. Seria um processo burocrático (e completamente desnecessário, que não existe em nenhuma parte da cadeia de pagamentos de outros modelos atualmente) gerar um novo par de credenciais (o que dependeria, inclusive, de intervenção manual por parte do PSP, na maioria das vezes) e isso leva tempo. Especialmente se for para um uso pontual como um hotsite promocional que vai ao ar durante um curtíssimo período (blackfriday-cybermonday, natal, semana do dia das mães, etc) e não um processo que vai resultar num uso contínuo, de longo prazo.
Seria muito melhor eu ter autonomia para definir como quero receber as notificações de diferentes Pix, relacionados a diferentes Cobranças/chaves, mediante alterações feitas por um único ator da relação cliente <-> PSP (esse "ator" seria eu mesmo, o cliente).
Isso se daria por meio de um processo 100% padronizado, automatizado e simples. Podendo ser:
- alterar a URL associada à uma Chave Pix, no app/dashboard do PSP; ou
- gerar uma nova Chave Pix para o hotsite, com a nova URL de notificação desejada para aquele caso;
E no caso de estar usando Cobranças e QR Codes dinâmicos:
- informar a URL específica que desejo na hora de gerar a Cobrança
Se é o recebedor que está definindo a URL de notificação que deve ser contatada (na Chave Pix ou na Cobrança), a entropia é praticamente ilimitada. E a URL, mesmo em cenários onde se observa alguma "padronização" (ex: vários recebedores usando o mesmo software e este sendo SaaS e não self-hosted), poderá conter, naturalmente, seus critérios de diferenciação e de autenticação. Um mero ?key=chave-de-validacao nesta URL seria mais do que suficiente para distinguir quem é o recebedor (e se a notificação é válida).
Entendo que é possível implementar um nível de entropia adequado, conforme relatado nesse trecho. Contudo, a preocupação do BACEN é com relação a um piso de segurança mínimo. Veja, se fosse implementado desta maneira, um usuário recebedor descuidado poderia não utilizar "um mero ?key=chave-de-validacao" e, assim, estar exposto a fraudes. Nós aqui sabemos que, em caso de uma fraude que explore esta falha, foi o usuário recebedor que não "implementou uma entropia adequada". Mas a fraude efetivamente aconteceria e até que o BACEN, instituidor do arranjo, conseguisse explicar que na verdade foi o usuário recebedor que foi descuidado, a imagem do arranjo estaria prejudicada. Alguem poderia argumentar que o arranjo apresenta "uma propensão ao erro". E aí poderia haver desdobramentos, certamente: O PSP recebedor arcaria com o prejuízo? O BACEN? o próprio usuário recebedor? De quem seria exatamente a culpa pela falha de segurança que permitiu a fraude? Existe um cenário complexo que teria que ser muito cuidadosamente analisado observando todos estes fatores.
Eu propus uma solução que seria a obrigatoriedade do recebedor informar uma chave de validação junto à própria URL de notificação (o que reforçaria a necessidade por parte de quem está implementado de que aquela chave deverá ser validada ao receber uma notificação).
Se o recebedor tratar o pagamento como baixado com base unicamente na notificação e sem validar a chave, ele estará assumindo o risco da fraude, assim como um vendedor do Mercado Livre que confia num e-mail que veio de uma origem desconhecida dizendo que o seu produto foi vendido e posta o produto nos Correios (sem verificar no sistema do ML que a venda de fato foi concretizada).
O ML é culpado pelos e-mails enviados por terceiros dizendo que um produto foi vendido? Os bancos são responsáveis pelos SMS de phishing que eu recebo toda semana dizendo que eu preciso revalidar meu cadastro nos mais variados bancos? Da mesma forma, o BACEN (ou o PSP recebedor, se este ficar responsável por enviar as notificações) não tem responsabilidade se a validação não for realizada pelo recebedor.
A única alteração proposta que poderia ser considerada mais insegura em relação ao modelo atual é que, para a notificação ser mais relevante a quem não possuir acesso à API Pix e for se valer do uso de QR Codes estáticos + a notificação via webhook (o que vai facilitar de fato a adoção do Pix como efetivo substituto às maquinetas no comércio) é que a notificação contemple algumas informações mínimas, somente as essenciais para distinguir pagadores que possam estar realizando transações ao mesmo tempo dentro do estabelecimento. Informações básicas tais como: o txid (sendo este o único completamente necessário), o valor que foi pago (necessário se não quiser forçar geração de QR Codes estáticos para cada cliente, permitindo o QR Code afixado no caixa, de uso geral) e o horário e/ou o e2eid da transação (para possibilitar identificar e tratar possíveis casos de recebimento da notificação em duplicidade ou fora da ordem em que os pagamentos foram recebidos). Outras informações, como dados pessoais do pagador, eu entendo que o BACEN possa considerar sensíveis demais para serem enviadas diretamente na notificação (talvez possa enviar só o primeiro nome e as outras iniciais?), sendo necessário o uso da API Pix caso o estabelecimento queria obter mais informações para integrações mais completas.
rubenskuhl
ninrod
feinstein
AdamTeodoro
Guihgo
Trazendo uma discussão que foi aberta na issue #9 (mas não era o foco original da issue) e ficou sem resposta por lá, trago para essa issue em forma de sugestão.
Visando oferecer uma experiência mais próxima à do cartão de débito e facilitando a adoção do Pix em pequenos estabelecimentos comerciais, que hoje contam com um comprovante gerado e impresso imediatamente pelas "maquininhas" de cartão, seria interessante que o QR Code utilizado para realizar as cobranças (ou a chave que está vinculada a ele) tivesse um webhook vinculado, para o qual o próprio BACEN (ou o PSP recebedor) enviaria um request (notificação).
Isso facilitaria que desenvolvedores de software oferecessem um serviço que inclua a notificação de pagamentos aos clientes de seus sistemas de ERP/cobrança. O recebedor do Pix receberia uma notificação de novo pagamento diretamente no celular ou em seu sistema de cobrança, sem precisar de um contrato para acesso à PIX API junto ao PSP.
Em 99,9% dos casos o único recurso da API estritamente necessário para um nível mínimo de controle a ser utilizado por pequenos estabelecimentos é esse, que permite uma notificação ou "baixa" de um pagamento. Os demais, são bem mais restritos a empresas de médio e grande porte.
Do ponto de vista da segurança, também é interessante evitar a necessidade de que um desenvolvedor tenha acesso (e armazene) tokens de API dos clientes, especialmente estes sendo pequenos clientes, sem um departamento de desenvolvimento, segurança ou tecnologia de maneira geral e não podendo realizar as integrações necessárias por conta própria.
Não considero isso propriamente como uma "automação" mas como um requisito básico para adoção do Pix em larga escala em muitos negócios de pequeno porte. Sem este tipo de funcionalidade, fica bem inviável o comerciante verificar os pagamentos (o fluxo de uma pequena padaria de bairro já seria suficientemente grande a ponto de inviabilizar a adoção imediata do Pix), enquanto o cartão de débito fornece uma confirmação segura e instantânea que o Pix, sem tal recurso sugerido, não oferece de forma facilitada e acessível.