Histórico de mensagens sobre an

mTLS também não é garantia, pq alguém pode hackear a Gerencianet, e roubar os certificados do mTLS, e sair por aí enviando webhooks fraudulentos, se for seguir por essa lógica.

Isso não é garantia, pois existe IP hijacking.

Ou, você além das verificações normais no backend, simplemente coloca um firewall aceitando solicitações somente dos IPs do gateway.

Sobre pedir mTLS, há duas estratégias para garantir integridade: uma é a que você mesmo vê na API de emissões da Gerencianet, onde a notificação só avisa de mudança de estado e você precisa de requisição direta para obter a alteração. A outra é carregar informação na requisição, e aí precisa de mTLS para ter certeza de quem veio. O Banco Central escolheu a 2a., mas ambas são alternativas válidas.

Eu sou também, pq eles fizeram recursos de segurança funcionais, como por exemplo criar um token pro cartão de crédito que não fica salvo no servidor. Isso tudo em documentação oficial.

Eles são, você provavelmente não é, dada a baixa preocupação com segurança.

Sim, eu tenho gateways de pagamento pra cartão de crédito, e eles também não pedem mTLS, e são PCI Compliance.

O Banco Central neste caso é instituidor do arranjo. Visa e Mastercard não são estatais, e ambos especificam tanto funcionalidade quanto segurança, criaram o PCI Security Council para definir segurança. A questão não é ser estatal ou não.
Veja você mesmo a tonelada de requisitos de segurança dos arranjos de cartão:
https://www.pcisecuritystandards.org/

Cara, a solução nunca vai ser um órgão centralizado estatal vir e te obrigar a fazer certas coisas em nome de segurança. Se os desenvolvedores não cuidam da segurança do seu sistema isso é a consequência dos atos deles.

MercadoPago é um mal exemplo de desobediência a padrões. Aqui MP não entra nem de graça.

E o que você mesmo de diz de que não são úteis mostra que sem um requisito mandatório, nada vai ser feito por segurança. Eu lido com devs nessa discussão há mais de 20 anos, e é sempre o mesmo papo-aranha.

A parte de segurança fica por parte de quem desenvolve o sistema.

Recursos de segurança que atrapalham o lado funcional não são úteis. O pessoal desde sempre utilizou webhook e ainda utiliza, sem mTLS, e nunca teve problemas. Inclusive MercadoPago funciona dessa forma, as IPNs não pedem certificado nem nada do tipo.

O pessoal do Banco Central que criou isso trabalha sim com programação... mas eles tem um ponto de vista de maior valorização de requisitos não funcionais como segurança e privacidade, enquanto você está olhando apenas o lado funcional.

Amigo, faz igual eu, cria um cronjob pra ficar verificando as cobs usando o endpoint de pixDetail, e dando baixa nos pagamentos. Esse negócio de mTLS no webhook claramente foi criado por alguém que não precisa programar, pq só dor de cabeça.

Os funcs Gerencianet são os de ID laranja. 😉

ah, obrigado, creio que cometi um enganho pensando que trabalhava para a gerencianet, peco desculpas

Oi, @everyone! Você já entendeu a importância do Open Banking e quais os impactos nas soluções de pagamento? O Diretor de Produtos da Gerencianet, Danilo Oliveira, conta pra você, de forma resumida, o que é, quais as vantagens e principais novidades do novo ecossistema financeiro do Banco Central.

A promessa é de uma grande revolução para negócios digitais e consumidores. Quer saber mais? Reunimos nossos especialistas para analisar o Open Banking, como ele será integrado ao Pix e muito mais. Confira o bate-papo na íntegra:

🔸 Open Banking para negócios digitais | Roda de Conversa - https://youtu.be/H_8kvAhaURg

Tem alguma dúvida ou sugestão sobre o assunto? O canal # 945404752546635826 está aberto para vocês.

Conte com a gente. 🧡

<@!780500321994539068> as vezes tenho recebido uma mensagem, utilizando a o sdk java, onde diz Already connected

No dicionário do SPI, conta-pagamento é "TRAN", e conta-salário é "SLRY", além das duas que você já citou.

Pessoal, um adendo a uma sugestão que já dei neste canal: mesmo colocando um hostname aleatório para receber o webhook, como dajsdasjkda.exemplo.com.br, o requisito de Certificate Transparency que as CAs tem que obedecer acaba fazendo vazar esse hostname quando se usa um proxy reverso como Cloudflare. Assim, o melhor mesmo é registrar outro domínio não correlacionável com o domínio principal (CPF/CNPJ diferente, e-mail diferente, ID diferente etc.) e esse domínio ser usado para o webhook.