Histórico de mensagens em pix

O mTLS aí está servindo para "garantir" para o meu back-end que quem está chamando e mandando as requisições para meu webhook é um certificado gerado pela CA que está naquele cert disponibilizado no site da Gerencianet. O que estou "propondo", é que não houvesse essa restrição na chamada do webhook. Logo, o payload da requisição poderia não ser de confiança. Por isso, a chamada ao webhook seria apenas como um ping, como um push notification, contendo uma chave para que só então o webhook fosse, ativamente, buscar pela informação. É uma arquitetura diferente da que está. É como o Pag Seguro faz, por exemplo. E é tão seguro quanto, só que menos dependente de configuração junto à infra. Enfim... é só um pensamento. Vou ver como resolver de outra forma.

O @anoni_mato tem um serviço de mTLS que oferece menos configuração, você pode verificar com ele.

Eu concordo plenamente, mas em relação ao mTLS funciona bem, porém, há alguns problemas, inclusive um relatado por mim sobre segurança.

Eu entendo realmente que isso em muitas vezes possa ser um impeditivo, mas ambientes mais compartilhados não devem ser utilizados para esse tipo de serviço.

Então, <@!522899003663450113>, na verdade eu suponho que a spec do webhook poderia ser melhor. Mas aí já é discussão para envolver Bacen tmb.

Não há como fazer isso sem acesso a infraestrutra, a não ser que o seu provedor dê acesso a alguma ferramenta.

E esse dificultador praticamente será um item restritivo nos ambientes PaaS de mercado.

Sim concordo. Não estou questionando a necessidade do webhook em prol do polling. Eu inclusive quero usar o webhook. Só que a restrição do client cert, que ao meu ver poderia ser de uma forma que dependesse menos de acesso a infra sem perder a segurança. A exemplo de como é a do PagSeguro.

Vale lembrar também que a ideia é que se tenha controle do ambiente que seu serviço está hospedado, este é um requisito para ter acesso ao Webhook.

O mTLS faz sentindo. Ainda mais quando se tem volume de transações, se a sua comunicação com o PSP é segura, não tanta há necessidade de checagem do evento (apesar de ser um item de segurança a mais). A questão toda é que um volume alto de transações iria gerar números altos de Webhook + números altos de checagem de Pix recebido, isso poderia bater no ratelimit do PSP.

A coisa ficaria menos "burocrática" sem abdicar da segurança.

Ao meu ver, toda essa restrição de segurança no webhook só é necessária porque a requisição que chega nele vem com dados da transação pelo que vi no vídeo. Se a requisição chegasse apenas: "olha só webhook, tem coisa nova lá no txid (ou e2eid) tal, então se vira para achar o que há de novo". Daí a implementação do webhook procuraria os dados "sensíveis" consumindo o serviço específico. Pelo que lembro, a API do Pag Seguro, por exemplo, faz assim. Aí, ao meu ver, não precisaria de tanto "cuidado" com o que chega no webhook, uma vez que a informação vai ser checada na fonte a posteriori.

Eu quero evitar fazer polling no serviço /cob/{txid} , mas se não for possível funcionar o webhook nesse cenário, já que é mandatório o client cert no handshake pelo que entendi, não vai ter jeito ☹️

Pessoal, alguém conseguiu fazer funcionar o handshake com client-cert para o webhook no Heroku? Meu back-end não faz o handshake HTTPS pois já recebe pronto do Heroku, que ao final faz um forward da requisição para meu back-end. Ou seja, meu back-end não participa do handshake. Em princípio essa "limitação" seria comum em cenários de uso em PaaS. Quem está usando webhook está usando servidor dedicado ou está em uma PaaS também? Valeu!

A única informação que recebo de volta no pagamento é o txid?

Não recebo nada através da consulta que posso identificar através dos dados que tenho do pagador?

Está correto. Mas você vai saber que há anomalias a conciliar, não qual cobrança se referem.

Pelo que entendi é possível obter as informações de pagamento de todos que não enviaram o txid , através da consulta no endpoint com txidpresente igual a no. Estou pensando correto?

E há uma questão de timing também: o Banco Central acredita que até 15 de Março vai colocar os PSPs na linha. De repente consegue...

Obrigado. Vou verificar no fluxo da minha aplicação onde posso colocar isto.