Até pq, uma opinião minha agr...
O webhook é o ponto "menos importante" pq a transação já aconteceu...
Uma forma de segurança q eu uso, pq vem da época de webhook q não tinha mtls, q é o caso do cartão e boleto, é quando recebo um webhook, não confiar nele, pego o id da transação e eu faço a consulta a api para validar o status...
Não é pq o webhook falhou, q o Pix vai ser desfeito... Se o webhook não chegar na aplicação, nada muda, financeiramente...
Esse tipo de argumento foi passado para o BACEN, está no histórico do Github do BACEN. Mas não aceitaram, e o padrão é com mTLS. Notar que o webhook do Pix tem mais informações do que só um transaction ID, então isso pode ter colaborado para essa exigência. Ou por homogeneidade com o OpenFinance.
O certificado para gerar a transação, criar a cobrança, acho q deveria ter em todos os endpoints... Pix, cartão, boleto...
Mas o webhook, vamos ser sinceros, muda nada...
Era mais fácil o Bacen colocar para só enviar o id da transação, e o cliente fazia uma Consulta...
A api antiga do PagSeguro, era assim, o webhook, só trazia o código da notificação, não era nem o id da transação, e o cliente consumia um endpoint para saber oq era aquela notificação, e o código de notificação, tinha uma prazo para expirar...
Cartão teria possíveis normas das bandeiras, mas de fato não tem nada nelas obrigando uso de certificado. Boleto poderia ter norma FEBRABAN, mas de fato as normas da FEBRABAN não exigem certificado. Então aí é discrecionaridade da Efí... Pix não.
