[Nova Funcionalidade] Notificação de pagamentos

[renatofrota]

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.

[rubenskuhl]

Me parece que há dois casos aqui: os que precisam dos recursos do QR-Code dinâmico, e os que podem funcionar com os recursos do QR-Code estático. Para o QR-Code dinâmico eu não vejo outra alternativa que não a API Pix.

Agora, para QR-Code estático poderia haver algum tipo de push notification, ao estilo Firebase ou Firehose. Cada fornecedor de automação poderia ter um endereço na plataforma (ex: 0xAB312BF3) e o cliente configuraria no seu banco (via autenticação já existente) algo como "notificar recebimentos da chave X para 0xAB312BF3".

A pergunta de 1 milhão de notas de R$200 é se isso é cost-effective o suficiente para permitir que varejos de ticket médio menor e com fornecedores de automação que cobram preços acessíveis usufruam disso.

[renatofrota]

Agora, para QR-Code estático poderia haver algum tipo de push notification, ao estilo Firebase ou Firehose. Cada fornecedor de automação poderia ter um endereço na plataforma (ex: 0xAB312BF3) e o cliente configuraria no seu banco (via autenticação já existente) algo como "notificar recebimentos da chave X para 0xAB312BF3".

Na verdade eu pensei em algo muito mais simples do que isso.

O MercadoPago (assim como o PayPal, PagSeguro e outros intermediadores e gateways), permitem que o cliente configure no painel da sua conta qual é a URL que receberá as notificações de pagamento. Todo pagamento é notificado para aquela URL, não importa se foi um envio de dinheiro de outra pessoa (espontâneo), um pagamento solicitado (seja diretamente ou por recursos como o "rachar contas"), por um link de pagamento, por uma venda do catálogo interno de produtos, por uma transação iniciada via API de cobrança, por um redirecionamento ao sistema de checkout em um e-commerce, etc, etc... todo dinheiro recebido é sempre notificado para aquela URL (exceto em casos onde uma cobrança criada via API especifique que os pagamentos oriundos daquela cobrança em particular devem ser notificados a uma URL específica, ou seja, é possível "sobrescrever" a URL configurada na conta do recebedor).

Isso dá uma abertura gigantesca para integrações super facilitadas, bastando o fornecedor de soluções orientar ao seu cliente "vá no painel da sua conta e coloque essa URL X para receber as notificações de pagamento". Elas nem precisam ser criadas via API(!) e o cliente poderá fazer uso de diversas soluções de gerenciamento de pedidos/cobranças e até traçar métricas/B.I. em cima dessas notificações, sem que essa ferramenta seja a encarregada de criar as cobranças. E ainda permite, inclusive, que a mesma conta seja utilizada em múltiplas integrações mais avançadas, bastando que as cobranças tenham uma URL de notificação definida no momento da sua criação (no campo específico da API para tal).

[rubenskuhl]

Isso seria um problema de segurança, pois se poderia forçar qualquer PSP a fazer requisições a pontos não confiáveis da Internet ou mesmo a confiáveis tentando se parecer como um ataque. Por exemplo, www.presidencia.gov.br/etc/passwd (não é bem isso mas não vou documentar formas de ataque, mas entendedores entenderão). Por isso a idéia de usar um sistema de mensageria pública já estabelecido.

O que você descreveu é o WebHook disponível na API Pix, mas lá há um procedimento de mútua autenticação que faz com que nenhuma requisição HTTP seja enviada antes do estabelecimento de uma sessão TLS onde as duas partes sabem suas contra-partes. E esse tipo de setup de autenticação faz falta na hora em que se deixa o cliente entrar qualquer coisa.

[renatofrota]

Isso seria um problema de segurança, pois se poderia forçar qualquer PSP a fazer requisições a pontos não confiáveis da Internet ou mesmo a confiáveis tentando se parecer como um ataque.

Acho que você forçou a barra absurdamente nessa interpretação. Um request disparado somente no evento de um pagamento recebido, mesmo considerando um custo mínimo de R$ 0,01 por Pix enviado para disparar esse gatilho, seria extremamente custoso e ineficiente. Qualquer pessoa interessada em fazer um ataque de requisições certamente não usaria esse método.

Além disso, o PSP (ou o BACEN) vai ignorar completamente qualquer retorno que essa URL prover, não executá-lo.

[feinstein]

Esse issue é EXATAMENTE o meu caso.

Eu queria desenvolver um App para pequenos comerciantes poderem verificar em tempo real os Pix que foram pagos, sem precisar deixar o App do Banco deles aberto no caixa.

Seria perfeito se pudesse colocar um URL a ser chamado no fim de uma transação que informasse todos os dados do QR Code, tanto para estáticos quanto dinâmicos, bem como se houve erro ou não na operação.

O PSP do pagador teria que chamar esse URL no fim do pagamento, já que é ele que viu o QR Code e detém a URL do webhook, mas fica super difícil falar de cobrança disso, já que o PSP do pagador não é vinculado em nada com o recebedor, logo deveria ser de graça esse serviço. Em outras palavras, como eu vou pagar para o PSP do pagador por essa informação? Eu teria que assinar contrato com todos os PSPs do Brasil.

O quanto possível é isso nesse momento? Quais são os impedimentos?

O fluxo que eu vejo é:

1. Usuário pagador lê o QR Code (estático ou dinâmico).
2. O PSP do pagador faz a transferência do dinheiro pela API Pix.
3. O PSP do recebedor recebe o dinheiro da transferência Pix.
4. O meu servidor (que não é um PSP nem nada, só um App) recebe uma call com as informações da operação Pix que acabou de se concluir.
5. Meu App pode mostrar ao caixa que a operação foi feita com sucesso e nota fiscal pode ser impressa.

[renatofrota]

@feinstein esse é exatamente o cenário que eu vejo. Será essencial para a maioria das pessoas que querem, efetivamente, adotar o Pix como meio principal de pagamento em seus estabelecimentos comerciais, receber as notificações de pagamento (e poder escolher o endereço de forma simplificada). Isso poderia estar vinculado à própria chave, no meu ponto de vista. Recebeu um Pix na chave X -> manda uma notificação no webhook dela.

É um processo tão previsível, simples e óbvio (análogo ao que acontece nas maquininhas de cartão) que me surpreende que não tenha sido levantada essa discussão ainda. Como trabalhar com o Pix de forma segura e prática, sem ter que ficar abrindo o app do banco pra verificar se um pagamento caiu? Só consigo pensar nessa forma e "vincular" o acesso a esse recurso aos demais recursos oferecidos pela API Pix (que, convenhamos, não será assim tão simples, prática e - financeiramente - acessível) me parece bastante estranho.

[feinstein]

Pois é.... Gostaria muito de saber quais são os impedimentos pra isso, se sequer existe algum e se tiver, como contornar.

[felipedelima19]

Seria excelente se dentro dos payloads dos recursos /cob e /pix tivéssemos o parâmetro url de notificação, para enviar, a cada transação, em qual url aquela transação deve ser notificada.

Isso eliminaria os 3 endpoints de webhooks e daria muito mais flexibilidade para as integrações.

[renatofrota]

Seria excelente se dentro dos payloads dos recursos /cob e /pix tivéssemos o parâmetro url de notificação, para enviar, a cada transação, em qual url aquela transação deve ser notificada.

Isso eliminaria os 3 endpoints de webhooks e daria muito mais flexibilidade para as integrações.

Entendo que a URL de notificação poderia ser vinculada à chave Pix e o PSP recebedor (ou o próprio BACEN) simplesmente enviaria um request para essa URL notificando que um pagamento foi recebido. Um request informando meramente o txid + o valor recebido seria suficiente para validação dos pagamentos num cenário onde o Pix esteja substituindo o cartão de débito num comércio presencial.

O terminal de caixa pode ficar em comunicação com um sistema [que pode ser externo e] que fica recebendo essas notificações de pagamento continuamente e exibindo sempre a última transação recebida [para o seu txid predeterminado].

O mesmo modelo também resolveria cenários de integração mais básicos para e-commerces, usando unicamente QR Codes estáticos, cujos txid seriam referências diretas ao número do pedido, por exemplo.

A definição de uma URL de notificação para uma cobrança especifica poderia substituir ou ser adicional (de forma configurável) à URL de notificação definida para a chave Pix.

[feinstein]

@ninrod continuando a discussão do #98:

Desde que seja muito bem fundamentado, há chance. Ainda não entendi este caso de uso específico. Em particular, essa funcionalidade abriria a possibilidade de haver, do ponto de visto do PSP recebedor, uma infinidade de URLs diferentes para que notificações sejam efetivadas. Problemas de segurança também me ocorrem: como garantir que cada uma dessas urls esteja inserida em um contexto de segurança adequado?

Você pode explicar melhor quais são as suas dúvidas? Estou entendendo haver várias, talvez não explicamos bem o nosso problema e como isso viria a ser uma solução.

Quanto as que você já definiu acima:

• ... essa funcionalidade abriria a possibilidade de haver, do ponto de visto do PSP recebedor, uma infinidade de URLs diferentes para que notificações sejam efetivadas.

Por que? As especificações do Pix podem impor um limite a isso. Por exemplo: "Um QR Code só pode ter no máximo 3 URLs. Se tiver mais que isso o PSP não é obrigado a chamar nenhuma URL que venha depois das 3 primeiras" (na realidade eu só vejo necessidade de 1 URL, mas coloquei 3 por ser algo razoável a meu ver para alguma funcionalidade futura desconhecida agora).

• ... como garantir que cada uma dessas urls esteja inserida em um contexto de segurança adequado?

O que seria "um contexto de segurança adequado"? HTTPS não é suficiente? Ou você está falando de outra coisa?

Eu vi alguém mencionando a possibilidade de DDoS, mas eu honestamente não consegui ver como isso seria viável. Estaríamos falando de 1 request por pagamento, seria um DDoS bem lerdo e bem caro. Qual seria o cenário onde isso aconteceria? Hackear uma loja web e introduzir um URL no QR Code da loja pra a cada venda ter um disparo ao alvo do DDoS?

[ninrod]

@feinstein ,

você pode explicar melhor quais são as suas dúvidas? Estou entendendo haver várias, talvez não explicamos bem o nosso problema e como isso viria a ser uma solução.

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?

Hackear uma loja web e introduzir um URL no QR Code da loja pra a cada venda ter um disparo ao alvo do DDoS?

Pensando rapidamente, vejo um problema que seria forjar notificações Pix. Veja que é fácil obter o txid dinâmico referente a uma cobrança. Se um hacker sabe que o usuário recebedor utiliza este "esquema de notificações", e se o endpoint servido pelo web sever do usuário recebedor não possui uma camada de segurança adequada, seria possível forjar notificações que estabeleçam que a cobrança foi liquidada, lesando o usuário recebedor por meio de, por exemplo, levá-lo a liberar uma mercadoria tendo em vista este recebimento fake.

[rubenskuhl]

Eu vi alguém mencionando a possibilidade de DDoS, mas eu honestamente não consegui ver como isso seria viável. Estaríamos falando de 1 request por pagamento, seria um DDoS bem lerdo e bem caro. Qual seria o cenário onde isso aconteceria? Hackear uma loja web e introduzir um URL no QR Code da loja pra a cada venda ter um disparo ao alvo do DDoS?

A menção não era a DDoS, mas a requisições maliciosas que causariam problemas para o PSP, onde o PSP ficaria parecendo como culpado de um ataque. E a resposta a esse falso ataque por parte de uma rede ou sistema pode ser o bloqueio da rede do PSP, gerando um DoS (mas não um DDoS).

[rubenskuhl]

Pensando rapidamente, vejo um problema que seria forjar notificações Pix. Veja que é fácil obter o txid dinâmico referente a uma cobrança. Se um hacker sabe que o usuário recebedor utiliza este "esquema de notificações", e se o endpoint servido pelo web sever do usuário recebedor não possui uma camada de segurança adequada, seria possível forjar notificações que estabeleçam que a cobrança foi liquidada, lesando o usuário recebedor por meio de, por exemplo, levá-lo a liberar uma mercadoria tendo em vista este recebimento fake.

Provavelmente essa forma de notificação dependesse de assinatura digital do BACEN, para que possa trafegar em canal inseguro e mesmo assim ser reconhecida como legítima. Não poderia ser assinatura do PSP pois alguém fora do SFN não consegue reconhecer quais os PSPs autorizados.

[feinstein]

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?

Sim, seria isso, mas a meu ver, corrija-me se estiver errado, se um PSP precisa fazer 10M de cobranças ao mês, então já serão 10M de requests à API Pix do bacen de qualquer forma. Se adicionarmos 1 URL, no pior dos casos a gente dobra isso para 20M de requests: 10M ao bancen e 10M ao URL de notificação. Dobrar fica pesado para esses PSPs que já tem a estrutura toda para 10M?

Pensando rapidamente, vejo um problema que seria forjar notificações Pix. Veja que é fácil obter o txid dinâmico referente a uma cobrança. Se um hacker sabe que o usuário recebedor utiliza este "esquema de notificações", e se o endpoint servido pelo web sever do usuário recebedor não possui uma camada de segurança adequada, seria possível forjar notificações que estabeleçam que a cobrança foi liquidada, lesando o usuário recebedor por meio de, por exemplo, levá-lo a liberar uma mercadoria tendo em vista este recebimento fake.

Sim, concordo, por isso que na minha sugestão anterior eu sugeri que houvesse um banco de dados disponibilizado pelo bacen onde a origem dos requests pudesse ser verificada de forma simples, através de uma assinatura digital onde as public keys fossem disponibilizadas pelos bacen, atrelado ao id do PSP. Talvez existam opções melhores, eu não sou especialista em segurança e não conheço todas as soluções de autenticação mutua, mas acredito que existam soluções pra isso e não seja um impedimento total a essa modificação.

[ninrod]

Provavelmente essa forma de notificação dependesse de assinatura digital do BACEN, para que possa trafegar em canal inseguro e mesmo assim ser reconhecida como legítima. Não poderia ser assinatura do PSP pois alguém fora do SFN não consegue reconhecer quais os PSPs autorizados.

Apenas expondo o ponto de vista do BCB, se entendi corretamente, neste caso, entendo que o BACEN assumiria um papel central na segurança da solução e acredito que estaríamos falando de uma carga brutal pensando no potencial de notificações para atender todo o país. Estabelecer essa comunicação BACEN x [todos os usuários recebedores do Brasil] seria uma arquitetura sem precedentes. Há, inclusive, questões jurídicas potencialmente envolvidas: joje o BACEN estabelece comunicações com instituições reguladas e neste cenário proposto, os usuários recebedores estariam fora do alcance regulatório do BACEN.

[feinstein]

@rubenskuhl:

A menção não era a DDoS, mas a requisições maliciosas que causariam problemas para o PSP, onde o PSP ficaria parecendo como culpado de um ataque. E a resposta a esse falso ataque por parte de uma rede ou sistema pode ser o bloqueio da rede do PSP, gerando um DoS (mas não um DDoS).

Você diz como e.g. colocar um SQL Injection num HTTP GET dentro de um QR Code e ai o PSP que faria o SQL Injection? Acho que o nome dessa vulnerabilidade é Open Redirect.

Realmente isso poderia ser um vetor de ataque, alguém tem ideais de como contornar isso de forma simples? Queria evitar um banco de dados de cadastro de URL seguras, pois isso iria dificultar a inclusão de apps pequenos como o meu, adicionar burocracia e seria mais um request para o PSP.

[rubenskuhl]

@rubenskuhl:

A menção não era a DDoS, mas a requisições maliciosas que causariam problemas para o PSP, onde o PSP ficaria parecendo como culpado de um ataque. E a resposta a esse falso ataque por parte de uma rede ou sistema pode ser o bloqueio da rede do PSP, gerando um DoS (mas não um DDoS).

Você diz como e.g. colocar um SQL Injection num HTTP GET dentro de um QR Code e ai o PSP que faria o SQL Injection? Acho que o nome dessa vulnerabilidade é Open Redirect.

Realmente isso poderia ser um vetor de ataque, alguém tem ideais de como contornar isso de forma simples? Queria evitar um banco de dados de cadastro de URL seguras, pois isso iria dificultar a inclusão de apps pequenos como o meu, adicionar burocracia e seria mais um request para o PSP.

Eu não vejo solução para isso usando HTTP. A solução que já comentei de mensageria pública ao estilo Google Firebase e similar é o caminho que vejo para isso.

[feinstein]

@rubenskuhl Como assim "mensageria pública ao estilo Google Firebase"?

[feinstein]

@ninrod:

Apenas expondo o ponto de vista do BCB, se entendi corretamente, neste caso, entendo que o BACEN assumiria um papel central na segurança da solução e acredito que estaríamos falando de uma carga brutal pensando no potencial de notificações para atender todo o país. Estabelecer essa comunicação BACEN x [todos os usuários recebedores do Brasil] seria uma arquitetura sem precedentes. Há, inclusive, questões jurídicas potencialmente envolvidas: joje o BACEN estabelece comunicações com instituições reguladas e neste cenário proposto, os usuários recebedores estariam fora do alcance regulatório do BACEN.

Mas o bacen precisaria estabelecer esse contato? Não seria apenas incluir na atual mensagem que o PSP já recebe, notificando que houve uma transação Pix, um campo que contém os dados da transferência, assinada pelo bacen? Dai o PSP apenas reenvia esse dado assinado com um nonce para a notificacao da URL. O dono da URL verifica que a transacao é correta pois vai estar assinada pelo bacen. Acredito que o nonce e um timestamp devem evitar ataques de replay. Nesse caso o PSP que faria a conexão, o bacen precisa apenas assinar.

[ninrod]

O MercadoPago (assim como o PayPal, PagSeguro e outros intermediadores e gateways), permitem que o cliente configure no painel da sua conta qual é a URL que receberá as notificações de pagamento. Todo pagamento é notificado para aquela URL, não importa se foi um envio de dinheiro de outra pessoa (espontâneo), um pagamento solicitado (seja diretamente ou por recursos como o "rachar contas"), por um link de pagamento, por uma venda do catálogo interno de produtos, por uma transação iniciada via API de cobrança, por um redirecionamento ao sistema de checkout em um e-commerce, etc, etc... todo dinheiro recebido é sempre notificado para aquela URL (exceto em casos onde uma cobrança criada via API especifique que os pagamentos oriundos daquela cobrança em particular devem ser notificados a uma URL específica, ou seja, é possível "sobrescrever" a URL configurada na conta do recebedor).

Entendo que essa descrição aproxima-se bastante ao cenário proposto pela API Pix hoje, via webhooks. A diferença é que essa URL única é a única possibilidade (você não consegue estabelecer uma URL por pagamento) e no lugar do dashboard você usa o webhook.

Isso dá uma abertura gigantesca para integrações super facilitadas, bastando o fornecedor de soluções orientar ao seu cliente "vá no painel da sua conta e coloque essa URL X para receber as notificações de pagamento". Elas nem precisam ser criadas via API(!) e o cliente poderá fazer uso de diversas soluções de gerenciamento de pedidos/cobranças e até traçar métricas/B.I. em cima dessas notificações, sem que essa ferramenta seja a encarregada de criar as cobranças. E ainda permite, inclusive, que a mesma conta seja utilizada em múltiplas integrações mais avançadas, bastando que as cobranças tenham uma URL de notificação definida no momento da sua criação (no campo específico da API para tal).

Poderia ser um cenário, o PSP recebedor apresentar um dashboard para configurar URLs de notificação "por fora da API". Em todo caso, preocupa-me as questões de segurança levantadas aqui.

[ninrod]

Mas o bacen precisaria estabelecer esse contato? Não seria apenas incluir na atual mensagem que o PSP já recebe, notificando que houve uma transação Pix, um campo que contém os dados da transferência, assinada pelo bacen? Dai o PSP apenas reenvia esse dado assinado com um nonce para a notificacao da URL. O dono da URL verifica que a transacao é correta pois vai estar assinada pelo bacen. Acredito que o nonce e um timestamp devem evitar ataques de replay. Nesse caso o PSP que faria a conexão, o bacen precisa apenas assinar.

Ok, entendo. O PSP recebedor poderia efetuar o "relay" da mensagem assinada pelo BACEN, evitando o problema da carga. Em tese, baseado na premissa de que sempre o usuário recebedor verificaria a corretude da assinatura, você teria um nível de segurança. Não sei dizer se seria o suficiente.

O foco aqui seria atender o fluxo QR Estático -> Confirmação de recebimento?

Apenas para entender a necessidade de negócio: se estabelecermos que o PSP do recebedor poderia fornecer em dashboard e mesma funcionalidade de webhooks, mas seguir exatamente o formato estabelecido pelo callback do webhook, resolveria a questão?

[feinstein]

O foco aqui seria atender o fluxo QR Estático -> Confirmação de recebimento?

A meu ver seria para qualquer QR Code, tanto estático quanto dinâmico.

[feinstein]

Apenas para entender a necessidade de negócio: se estabelecermos que o PSP do recebedor poderia fornecer em dashboard e mesma funcionalidade de webhooks, mas seguir exatamente o formato estabelecido pelo callback do webhook, resolveria a questão?

O que me preocupa é a palavra "poderia". Isso implica que não seria obrigatório a todos os PSPs e assim fica difícil fazer um serviço que só funcionaria para algumas pessoas.

Confesso que ainda estou lendo as documentações do Pix e não sei ainda suficiente sobre todo o fluxo do "callback do webhook" para medir as limitações que ele possa ter e assim poder te responder no momento.

[rubenskuhl]

@rubenskuhl Como assim "mensageria pública ao estilo Google Firebase"?

https://firebase.google.com/docs/cloud-messaging/

Se você tem um celular Android, já viu o FCM em ação... é o que usado para distribuir push notifications para apps nesse ambiente. Mas o FCM não é limitado a Android.

[rubenskuhl]

O que me preocupa é a palavra "poderia". Isso implica que não seria obrigatório a todos os PSPs e assim fica difícil fazer um serviço que só funcionaria para algumas pessoas.

Confesso que ainda estou lendo as documentações do Pix e não sei ainda suficiente sobre todo o fluxo do "callback do webhook" para medir as limitações que ele possa ter e assim poder te responder no momento.

Isso já é assim com a API Pix, não é uma oferta obrigatória pelo PSP.

[rubenskuhl]

O foco aqui seria atender o fluxo QR Estático -> Confirmação de recebimento?

A meu ver seria para qualquer QR Code, tanto estático quanto dinâmico.

O problema do QR-Code dinâmico é que ele precisa de uma interface de geração. O tipo de API simplificada que se está propondo neste issue me parece mais compatível com o QR-Code estático com TxID.

[feinstein]

Se você tem um celular Android, já viu o FCM em ação... é o que usado para distribuir push notifications para apps nesse ambiente. Mas o FCM não é limitado a Android.

Sim, eu sou dev mobile inclusive haha, só não entendi a comparação. o BCB seria o Firebase nesse caso? Ou o PSP? Tem toda uma arquitetura distribuída meio complexa de push por traz do FCM então não sei qual seria a viabilidade pra isso virar algo concreto.

[feinstein]

Isso já é assim com a API Pix, não é uma oferta obrigatória pelo PSP.

Sem ser algo obrigatório eu não consigo ver isso então como uma solução. Um cliente para adotar meu serviço teria que trocar de banco por exemplo e ai vira um entrave.

[feinstein]

O problema do QR-Code dinâmico é que ele precisa de uma interface de geração. O tipo de API simplificada que se está propondo neste issue me parece mais compatível com o QR-Code estático com TxID.

Sim, a ideia que eu tinha a principio é que eu ia gerar o QR Code dinâmico para o meu cliente e o pagamento cai no banco dele e o banco faz uma notificacao na URL que eu botei no QR Code (estático ou dinâmico).

Há também a possibilidade de se ter um dashboard no PSP em que a URL pode ser fornecida e incluída em cada QR Code gerado pela interface do PSP.

[rubenskuhl]

Se você tem um celular Android, já viu o FCM em ação... é o que usado para distribuir push notifications para apps nesse ambiente. Mas o FCM não é limitado a Android.

Sim, eu sou dev mobile inclusive haha, só não entendi a comparação. o BCB seria o Firebase nesse caso? Ou o PSP? Tem toda uma arquitetura distribuída meio complexa de push por traz do FCM então não sei qual seria a viabilidade pra isso virar algo concreto.

Não, o Firebase é quem entregaria a mensagem ao terceiro que o correntista quer que seja notificado. Ou o BCB ou o PSP entregaria a mensagem para o Firebase, o terceiro tem um identificador no FCM que seria usado. Então a única configuração seria "ID FCM xxxxxx irá receber notificações de recebimento da chave Pix xxxxxx".

[rubenskuhl]

Isso já é assim com a API Pix, não é uma oferta obrigatória pelo PSP.

Sem ser algo obrigatório eu não consigo ver isso então como uma solução. Um cliente para adotar meu serviço teria que trocar de banco por exemplo e ai vira um entrave.

Não, o cliente pode ter conta no banco que quiser, basta uma conta num PSP que suporte a API Pix ser usada para confirmar o recebimento, e o dinheiro já ser enviado via Pix para a conta apontada pelo cliente no banco de preferência dele.

De qualquer forma, se os 3 grandes bancos privados não conseguem nem fazer o acesso ao DICT funcionar direito, me parece uma expectativa exagerada que todos os PSPs suportem algo tipo de API de notificação. O mercado tem especializações, e quem precisa de um recurso especializado precisa buscar quem o forneça com competência, qualidade e preço competitivo.

[rubenskuhl]

O problema do QR-Code dinâmico é que ele precisa de uma interface de geração. O tipo de API simplificada que se está propondo neste issue me parece mais compatível com o QR-Code estático com TxID.

Sim, a ideia que eu tinha a principio é que eu ia gerar o QR Code dinâmico para o meu cliente e o pagamento cai no banco dele e o banco faz uma notificacao na URL que eu botei no QR Code (estático ou dinâmico).

Para isso há uma série de confirmações de autorização que torna isso muito mais parecido com o #83 do que com este issue.

Há também a possibilidade de se ter um dashboard no PSP em que a URL pode ser fornecida e incluída em cada QR Code gerado pela interface do PSP.

O que existe de caso de uso previsto como possível mas não mandatório é QR-Code dinâmico via app mobile.

[feinstein]

Não, o Firebase é quem entregaria a mensagem ao terceiro que o correntista quer que seja notificado. Ou o BCB ou o PSP entregaria a mensagem para o Firebase, o terceiro tem um identificador no FCM que seria usado. Então a única configuração seria "ID FCM xxxxxx irá receber notificações de recebimento da chave Pix xxxxxx".

Acho um pouco arriscado isso, ter toda a plataforma de notificações de pagamento do país atrelado ao FCM. Por enquanto ele é de graça, mas se a gente jogar todo esse fluxo lá, talvez ele deixe de ser. Além de que ele só aceita Android, iOS e Web Push, então fica limitado as arquiteturas que podemos utilizar para receber e processar essa notificação.

[rubenskuhl]

Não, o Firebase é quem entregaria a mensagem ao terceiro que o correntista quer que seja notificado. Ou o BCB ou o PSP entregaria a mensagem para o Firebase, o terceiro tem um identificador no FCM que seria usado. Então a única configuração seria "ID FCM xxxxxx irá receber notificações de recebimento da chave Pix xxxxxx".

Acho um pouco arriscado isso, ter toda a plataforma de notificações de pagamento do país atrelado ao FCM. Por enquanto ele é de graça, mas se a gente jogar todo esse fluxo lá, talvez ele deixe de ser. Além de que ele só aceita Android, iOS e Web Push, então fica limitado as arquiteturas que podemos utilizar para receber e processar essa notificação.

Isso tem uma solução chamada contrato. E há alternativas como CloudAlert, Amazon SNS, Pushwoosh, Urban Airship... Web é um padrão aberto assim como os padrões Web que foram usados na construção do Pix.

[felipedelima19]

Vejo que facilitaria muito se a cada request no endpoint /cob já fosse possível enviar a url de notificação para aquele txid. Eliminaríamos de cara a necessidade do endpoint webhooks e flexibiliza muito integrações diversas serem notificadas.

Um exemplo claro é nos casos no qual a url de notificação ja contem o id da transação, muitos e-commerces fazem isso. Por exemplo:

1. O e-commerce finaliza um pedido com o id 1234
2. O e-commerce envia para a cobrança do pedido para PSP, informando a url de notificação https://example.ecommerce.com/orders/1234
3. O PSP, a cada mudança relevante na cobrança, envia a notificação para a url informada no passo acima.

Dessa forma, é muito mais fácil identificar as notificações e não gerar um único ponto de entrada para todas elas como está sendo proposto.

Acredito que, informar a url de notificação no /cob seria a forma mais agnóstica, flexível e adequada para atender diversos modelos de negócio. Penso que a forma atual limita muito a atuação que podemos ter nesse tema.

[rubenskuhl]

Eu acho que definição de URL por TxID só complica o funcionamento do PSP, dando pouco ganho para o cliente. O que o cliente pode precisar como colocar o webhook num sistema stand-by, tirar de load-balance etc. pode ser endereçado completamente pelo /webhook como está agora. Não entendo a objeção a esse método.

Agora, nos casos de notificação de terceiros, vide #83 , alguma granularidade pode fazer sentido em alguns casos de uso. Eu sugeri que seja por chave, mas é algo que essa interface de complexidade maior pode precisar carregar, não a atual.

[fernandogodoy]

Na verdade, entendo o contrário disso, a definição de webhook da maneira como está na especificação é que complica para o PSP. Além da obrigatoriedade da criação de toda uma estrutura, em uma evolução da API pode quebrar o contrato, dado que não é possivel manter a retrocompatibilidade de mensagems em payloads antigos.

Imagino em algum momento a criação de um v2 dessa api de notificação. Notificações pendentes podem para de funcionar devido a alteração do contrato e notificações novas não podem ser emitidas até que todas antigas tenham sido devidamente notificadas. Isso pode se complicar num cenário simples como a inclusão de 1 unico campo obrigatório na nova versão que não exista na versão anterior.

Tendo a url de notificação no payload, além da eliminar todo o controle para as URLs teria como ganho o versionamento de notificações.

Se o problema for segurança, pode ser facilmente contornado enviando na notificação o payload em padrão JWS ou enviando um id gerado pelo PSP no endpoint e o cliente, de posse de ID faria uma chamada em um endpoint de consulta que atenda as normas de segurança da especificação para só obter os dados da notificação.

[rubenskuhl]

Esta já é a v2, mas entendi o ponto... eu acho que em termos de segurança é indiferente, ambas são chamadas dinâmicas sobre canal OAuth2 e mTLS.

Me parece que esse é um ponto de atenção em mudanças no pacote enviado via webhook e que independente do webhook ser definido por cobrança ou não, que suas evoluções precisam ser feitas com muito cuidado, inclusive aplicando o https://en.wikipedia.org/wiki/Robustness_principle no lado do cliente.

[renatofrota]

O MercadoPago (assim como o PayPal, PagSeguro e outros intermediadores e gateways), permitem que o cliente configure no painel da sua conta qual é a URL que receberá as notificações de pagamento. Todo pagamento é notificado para aquela URL, não importa se foi um envio de dinheiro de outra pessoa (espontâneo), um pagamento solicitado (seja diretamente ou por recursos como o "rachar contas"), por um link de pagamento, por uma venda do catálogo interno de produtos, por uma transação iniciada via API de cobrança, por um redirecionamento ao sistema de checkout em um e-commerce, etc, etc... todo dinheiro recebido é sempre notificado para aquela URL (exceto em casos onde uma cobrança criada via API especifique que os pagamentos oriundos daquela cobrança em particular devem ser notificados a uma URL específica, ou seja, é possível "sobrescrever" a URL configurada na conta do recebedor).

Entendo que essa descrição aproxima-se bastante ao cenário proposto pela API Pix hoje, via webhooks. A diferença é que essa URL única é a única possibilidade (você não consegue estabelecer uma URL por pagamento) e no lugar do dashboard você usa o webhook.

Isso. O MercadoPago, por exemplo, oferece essa tela de configuração de URLs de notificação, como já falei anteriormente. E, até onde eu entendi (pelas informações disponíveis na interface deles até o momento), os pagamentos recebidos via Pix serão notificados para esta URL configurada para a conta, assim como qualquer outro pagamento/transferência que chega à conta do MP hoje. É uma notificação ainda mais "sucinta" que um push no mobile, pois informa apenas que houve uma atualização naquela Operação.

Isso dá uma abertura gigantesca para integrações super facilitadas, bastando o fornecedor de soluções orientar ao seu cliente "vá no painel da sua conta e coloque essa URL X para receber as notificações de pagamento". Elas nem precisam ser criadas via API(!) e o cliente poderá fazer uso de diversas soluções de gerenciamento de pedidos/cobranças e até traçar métricas/B.I. em cima dessas notificações, sem que essa ferramenta seja a encarregada de criar as cobranças. E ainda permite, inclusive, que a mesma conta seja utilizada em múltiplas integrações mais avançadas, bastando que as cobranças tenham uma URL de notificação definida no momento da sua criação (no campo específico da API para tal).

Poderia ser um cenário, o PSP recebedor apresentar um dashboard para configurar URLs de notificação "por fora da API". Em todo caso, preocupa-me as questões de segurança levantadas aqui.

Ao receber a notificação de um novo pagamento entrante, esta acompanha unicamente o número da operação (similar ao e2eid no cenário do Pix). Se o recebedor quiser saber mais detalhes, deve fazer uma consulta usando a API deles, que retorna toda a sorte de informações sobre esta transação (ou verificar manualmente, abrindo o site/app).

Então, detalhando minhas ideias com base nas suas perguntas até aqui:

A minha expectativa é que a funcionalidade de webhook deixe de ser um recurso cujo acesso é exclusivo pela API (e com uma URL que é basicamente única por recebedor, conforme a contratação do acesso à Pix Api), para facilitar a adesão (e a forma mais facilitada que eu vejo para isso, é o PSP recebedor simplesmente oferecer uma interface onde o cliente possa definir uma URL de notificação por Chave Pix). Repetindo o que falei lá na mensagem inicial dessa própria issue, é crucial para qualquer comércio com um fluxo mínimo de clientes que se possa obter notificações de pagamento de forma tão facilitada quanto o comprovante emitido (automaticamente) pela maquineta de cartões. Do contrário, a adesão do Pix será muito aquém do potencial/esperado.

Já num cenário em que um QR Code dinâmico foi gerado (seja via Pix API ou pelo app mobile do PSP recebedor), eu acho que seria crucial a URL de notificação ser definida amarrada a este QR Code (e não uma configuração global da conta).

Assim, minha segunda expectativa, como também foi colocado em discussão por outros participantes nesta issue, é que uma URL de notificação possa ser definida para uma cobrança em particular (sobrescrevendo a URL de notificação geral da Chave Pix recebedora). Isso daria ainda mais flexibilidade (da mesma forma que a API de basicamente todos os intermediadores e gateways de pagamento permitem que eu defina URLs de notificação específicas quando crio cobranças). Isso eliminaria a necessidade dos endpoints de webhook (seria meramente um campo extra - junto a tantos outros que já existem - dentro da cobrança).

@feinstein ,

você pode explicar melhor quais são as suas dúvidas? Estou entendendo haver várias, talvez não explicamos bem o nosso problema e como isso viria a ser uma solução.

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.

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).

Hackear uma loja web e introduzir um URL no QR Code da loja pra a cada venda ter um disparo ao alvo do DDoS?

Pensando rapidamente, vejo um problema que seria forjar notificações Pix. Veja que é fácil obter o txid dinâmico referente a uma cobrança. Se um hacker sabe que o usuário recebedor utiliza este "esquema de notificações", e se o endpoint servido pelo web sever do usuário recebedor não possui uma camada de segurança adequada, seria possível forjar notificações que estabeleçam que a cobrança foi liquidada, lesando o usuário recebedor por meio de, por exemplo, levá-lo a liberar uma mercadoria tendo em vista este recebimento fake.

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).

Se quiser deixar 100% seguro, para que não fique visível em logs, esta chave pode ser enviada obrigatoriamente por um header ou o request pode ser obrigatoriamente um POST em vez de um GET e esta chave de notificação seria um dos campos (neste caso, as URLs de notificação seriam cadastradas no PSP em pares URL+chave de validação).

A informação enviada pode ser a mínima necessária para validar o pagamento e liberar o cliente. No caso de QR Codes estáticos txid + valor pago + horário do pagamento, já seriam suficientes (apesar de eu não ver prejuízo nenhum na segurança em adicionar outras informações, como o nome do pagador).

[rubenskuhl]

Isso. O MercadoPago, por exemplo, oferece essa tela de configuração de URLs de notificação, como já falei anteriormente. E, até onde eu entendi (pelas informações disponíveis na interface deles até o momento), os pagamentos recebidos via Pix serão notificados para esta URL configurada para a conta, assim como qualquer outro pagamento/transferência que chega à conta do MP hoje. É uma notificação ainda mais "sucinta" que um push no mobile, pois informa apenas que houve uma atualização naquela Operação.

Isso pode colocar o MP em contravenção ao regulamento do Pix, que permite apenas a API padrão deste repositório. Nós descartamos o MP como PSP recebedor por cobrar por MDR, mas mandar proposta ou colocar site dizendo que vai fazer isso é um tremendo risco de compliance.

[renatofrota]

Isso. O MercadoPago, por exemplo, oferece essa tela de configuração de URLs de notificação, como já falei anteriormente. E, até onde eu entendi (pelas informações disponíveis na interface deles até o momento), os pagamentos recebidos via Pix serão notificados para esta URL configurada para a conta, assim como qualquer outro pagamento/transferência que chega à conta do MP hoje. É uma notificação ainda mais "sucinta" que um push no mobile, pois informa apenas que houve uma atualização naquela Operação.

Isso pode colocar o MP em contravenção ao regulamento do Pix, que permite apenas a API padrão deste repositório. Nós descartamos o MP como PSP recebedor por cobrar por MDR, mas mandar proposta ou colocar site dizendo que vai fazer isso é um tremendo risco de compliance.

Eles não mudaram nada em sua documentação de geração de cobranças até o momento. Mas um QR Code "geral" da conta (sem nenhum txid específico) emitido no painel da conta hoje, que anteriormente seguia um formato específico deles, hoje está no formato BR Code e em conformidade com a API Pix (me parece ser um QR Code dinâmico). Em eles não informando o contrário até agora (o "não envio" de notificações de pagamento quando estes sejam feitos através do Pix) eu estou apenas supondo que eles notificarão recebimentos Pix assim como os demais pagamentos.

De qualquer forma, isto não é o mesmo que "oferecer acesso à API Pix de forma não padronizada". Ainda que o façam (notifiquem pagamentos), estariam oferecendo um serviço adicional, relativo ao Pix (por que o recebimento foi um Pix), mas é totalmente adicional e fora da estrutura/escopo do Pix em si e, principalmente, desta API padronizada. Não faz sentido, para mim, que um PSP qualquer seja impedido de informar seu cliente que ele recebeu um pagamento. Onde isso fere o regulamento? Pelo contrário, acho que esse é um tipo de facilitação que os PSPs devem buscar oferecer se quiserem se diferenciar dos demais e atrair clientes.

[rubenskuhl]

Diferenciação é exatamente a ferramenta de lock-in e de diminuição da competição, então isso parece bondade mas tem efeito detrimental.

Sobre BR Code, quando ele foi instituído todos os arranjos com QR-Code passaram a ser obrigados a usá-lo, independente de serem Pix ou outros arranjos. Então isso não necessariamente tem relação direta com o Pix.

[renatofrota]

Sobre BR Code, quando ele foi instituído todos os arranjos com QR-Code passaram a ser obrigados a usá-lo, independente de serem Pix ou outros arranjos. Então isso não tem relação direta com o Pix.

Eu gerei um QR Code no painel da minha conta e ele contém este trecho: 26910014BR.GOV.BCB.PIX2569pix-qr.mercadopago.com/instore/pix/p/<uuid>. Pela documentação, é um QR Code dinâmico compatível com Pix.

[rubenskuhl]

Sobre BR Code, quando ele foi instituído todos os arranjos com QR-Code passaram a ser obrigados a usá-lo, independente de serem Pix ou outros arranjos. Então isso não tem relação direta com o Pix.

Eu gerei um QR Code no painel da minha conta e ele contém este trecho: 26910014BR.GOV.BCB.PIX2569pix-qr.mercadopago.com/instore/pix/p/<uuid>. Pela documentação, é um QR Code dinâmico compatível com Pix.

Então se o pagamento desse QR for notificado via API diferente da padronizada, o MP pode estar na roça.

[felipedelima19]

Posso estar errado, mas acompanhando a thread eu vejo o @renatofrota, @fernandogodoy e eu trouxemos muitos argumentos para defender a mudança na forma como acontecem os webhooks e não vejo nenhum argumento plausível para manter o modelo atual.

Como o próprio @renatofrota citou, a grande maioria dos PSP, gateways, subacquirers e acquirers do mundo implementam os webhooks de uma maneira, e existem muitos motivos para isso.

Se o Banco Central quer realmente manter sua API aberta para o surgimento de novos modelos de negócio, sem que os PSPs criem suas próprias soluções como citado acima o exemplo do MP, sugiro olhar com atenção a esse ponto.

Creio que todos os exemplos, casos de uso e argumentos já foram colocados na issue. Nos resta aguardar um posicionamento oficial e espero que o BC esteja disposto a ouvir as sugestões aqui expostas.

[renatofrota]

Sobre BR Code, quando ele foi instituído todos os arranjos com QR-Code passaram a ser obrigados a usá-lo, independente de serem Pix ou outros arranjos. Então isso não tem relação direta com o Pix.

Eu gerei um QR Code no painel da minha conta e ele contém este trecho: 26910014BR.GOV.BCB.PIX2569pix-qr.mercadopago.com/instore/pix/p/<uuid>. Pela documentação, é um QR Code dinâmico compatível com Pix.

Então se o pagamento desse QR for notificado via API diferente da padronizada, o MP pode estar na roça.

Baseado em quê? Não sou PSP, não conheço a regulamentação em sua integralidade.

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.

Posso estar errado, mas acompanhando a thread eu vejo o @renatofrota, @fernandogodoy e eu trouxemos muitos argumentos para defender a mudança na forma como acontecem os webhooks e não vejo nenhum argumento plausível para manter o modelo atual.

Como o próprio @renatofrota citou, a grande maioria dos PSP, gateways, subacquirers e acquirers do mundo implementam os webhooks de uma maneira, e existem muitos motivos para isso.

Se o Banco Central quer realmente manter sua API aberta para o surgimento de novos modelos de negócio, sem que os PSPs criem suas próprias soluções como citado acima o exemplo do MP, sugiro olhar com atenção a esse ponto.

Creio que todos os exemplos, casos de uso e argumentos já foram colocados na issue. Nos resta aguardar um posicionamento oficial e espero que o BC esteja disposto a ouvir as sugestões aqui expostas.

Concordo. Mas não sinto que estou "chovendo no molhado". As perguntas do @ninrod foram pertinentes e ele parece estar interessado em modificar as coisas, se ainda der tempo. Espero que sim (ele esteja realmente interessado) e sim (dê tempo).

Considerando que a API já prevê uma funcionalidade de webhook e notificações (então não se demandaria muito tempo fazer mudanças neste sentido) e, pela nossa sugestão ser apenas de mudar a forma de definir as URLs de webhooks e o escopo delas (que seriam vinculadas às Cobranças, seguindo todos os intermediadores, gateways, acquirers e subacquirers do mundo, como você bem observou), eu entendo que não há motivos para a não aceitação das mudanças propostas.

Nos apps mobile, bastariam 1 ou 2 telas a mais para permitir o recebedor definir as URLs de notificação + uma chave de validação para cada chave Pix.

[rubenskuhl]

Posso estar errado, mas acompanhando a thread eu vejo o @renatofrota, @fernandogodoy e eu trouxemos Se o Banco Central quer realmente manter sua API aberta para o surgimento de novos modelos de negócio, sem que os PSPs criem suas próprias soluções como citado acima o exemplo do MP, sugiro olhar com atenção a esse ponto.

Se o MP quer sugerir algo de uma forma, está valendo... discussão é para isso mesmo. Mas criar soluções em contravenção ao regulamento não é o caminho.

Eu não vejo os problemas apontados na thread para o caso de uso originalmente previsto, de interação do correntista com seu PSP. Tanto este thread quanto o #83 identificaram situações de três partes onde essa relação pode ser melhor em outro formato, com este propondo algo mais light-weight e o outro algo mais heavy-weight. O que não significa que o caso bilateral correntista - PSP tenha qualquer necessidade de alteração.

[rubenskuhl]

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.

[ninrod]

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?

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?

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.

Concordo. Mas não sinto que estou "chovendo no molhado". As perguntas do @ninrod foram pertinentes e ele parece estar interessado em modificar as coisas, se ainda der tempo. Espero que sim (ele esteja realmente interessado) e sim (dê tempo).

Prezados, estou tentando acompanhar a discussão para verificar se tecnicamente a proposta apresentada aqui é realmente superior ao que está especificado na API. Sigo ouvindo atentamente.

Posso estar errado, mas acompanhando a thread eu vejo o @renatofrota, @fernandogodoy e eu trouxemos muitos argumentos para defender a mudança na forma como acontecem os webhooks e não vejo nenhum argumento plausível para manter o modelo atual.

Eu adicionei algumas preocupações acima, nesta resposta.

Considerando que a API já prevê uma funcionalidade de webhook e notificações (então não se demandaria muito tempo fazer mudanças neste sentido) e, pela nossa sugestão ser apenas de mudar a forma de definir as URLs de webhooks e o escopo delas (que seriam vinculadas às Cobranças, seguindo todos os intermediadores, gateways, acquirers e subacquirers do mundo, como você bem observou), eu entendo que não há motivos para a não aceitação das mudanças propostas.

Esse "seguindo todos os intermediadores, gateways, acquirers e subacquirers do mundo, como você bem observou" é um ponto importante que, acredito, tem que ser esclarecido: o BACEN não está padronizando, neste repositório, uma API para gateways, acquirers, subacquirers ou TEFs, os quais continuarão existindo. Estamos estabelecendo uma API para implementação por parte dos PSPs nos quais o usuário recebedor possui conta. O "gateway" pode continuar notificando seu cliente do jeito que achar melhor.

[rubenskuhl]

Esse "seguindo todos os intermediadores, gateways, acquirers e subacquirers do mundo, como você bem observou" é um ponto importante que, acredito, tem que ser esclarecido: o BACEN não está padronizando, neste repositório, uma API para gateways, acquirers, subacquirers ou TEFs, os quais continuarão existindo. Estamos estabelecendo uma API para implementação por parte dos PSPs nos quais o usuário recebedor possui conta. O "gateway" pode continuar notificando seu cliente do jeito que achar melhor.

O único cuidado aqui é não deixar que empresas de um mesmo grupo econômico não usem isso para driblar a padronização. Cliente é correntista da empresa A que misteriosamente não oferece API (nenhuma) mas a empresa B do mesmo grupo econômico oferece API não padronizada se alegando gateway/TEF.