Histórico de mensagens sobre dados

é que são aplicações diferentes em cada chave e vão para bancos de dados diferentes, por isso a necessidade, são dois sistemas separados.

estou salvando tudo que recebo direto no banco de dados e esta salvando normal, este de hoje que nao sei se foi enviado, pois nao tem nada no banco, por isso perguntei se tem como ver ou solicitar reenvio.

E só completando aqui a ideia do secret. Não há 2 pessoas envolvidas como você citou. Existe só 1 pessoa. A pessoa cria o secret e ela mesma cadastra o webhook no serviço do PSP. Por isso que o conceito é secret mesmo. Se entrarmos no mérito que alguém do PSP pode acessar a base de dados de cadastro de webhooks aí o negócio começa a ficar extremo, pois da mesma forma poderia ter acesso a outras informações pessoais que teriam muito mais valor que um secret de um webhook. E quem garante que a geração das chaves privadas na CA do PSP, que provavelmente não tem certificação oficial de CA, é mais segura que o acesso às informações privadas de uma base de dados de produção? Comentando aqui só para destrinchar mais o assunto... indo além do tabu.

Sim. Mas o client cert não garante, na prática, neste cenário, nenhuma segurança a mais do que usar um secret, por exemplo. Todos os dados são tunelados com SSL da mesma forma. Só comentei mesmo pelo fato do tabu que existe quando se fala de certificado. Neste caso, ao meu ver, acaba sendo apenas burocracia.

Não é apenas não-repúdio, como há informações financeiras em trânsito, há também questões de sigilo bancário. O próprio BACEN parece amigável a que numa versão 3 o webhook contenha menos dados (por exemplo apenas a chave Pix e o txid) e com isso possa ter requisitos menores de segurança, pois a informação bancária só seria transmitida no GET de /pix ou da cobrança que o causou. Mas para a versão 2.x, ficou assim e não vai mudar.

Na verdade a solução seria a mesma. Tanto é que, atualmente, é preciso que seja feita uma requisição antes sem o certificado onde o erro é esperado. Para só então repetir a requisição com os dados corretos. O mesmo poderia ser feito com o secret. A primeira sem o secret e esperar o erro. Depois repetir. Só seria MUITO mais simples de configurar, de implementar, de manter, além de ser mais compatível por ser menos dependente de configuração de ambiente.

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.

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

<@!671762828046106646> ele gera.. bacana.. mas ele está gerando com dados errados.. tento ler ele dá como código inválido. é só o id mesmo?

Estou conseguindo gerar cobranças no cartão pelo payment token entretanto os pagamentos não estão sendo aprovados, tem algum maneira de a equipe tecnica validar o meu payment token? Eu preciso ter uma certeza de que os dados estão de fato coincidindo com o que eu tô mandando.

relato: a melhor parte de ficar procurando bug aonde não tem... Quando o campo do VARCHAR no banco de dados está com 600 e preciso de 636 characters para armazenar, com isso eu recebia invalid_acess token. Claro o sistema estava lendo 600 e nao 636.....kkkk adoro este tipo de bug, deixei com 700...

Se você está utilizando a SDK de PHP, acredito que seja os dados de infoAdicionais, elas não são retornadas no webhook e aparecem no momento de leitura do QRcode pelo pagador.

e apos o cliente pagar eu preciso ficar consultando ou tem um aviso IPN via POST contendo os dados como esse criado invoice='1234'

[
"nome" => "invoice", // Nome do campo string (Nome) ≤ 50 characters
"valor" => "1234" // Dados do campo string (Valor) ≤ 200 characters
],

porque em APIs propietárias vem mais dados..

A Gerencianet tem essa solução sim, a API Pix. Notar porém que cada cliente seu precisaria abrir uma conta na Gerencianet, pedir os dados de acesso (client-id, client-secret e certificado), gerar uma chave Pix e aí te passar os parâmetros para vocês rodarem essas cobranças dos clientes de vocês para os clientes finais deles.
https://dev.gerencianet.com.br/docs/api-pix tem a documentação de integração, e o canal <#❖pix> tem pessoas tanto da Gerencianet quanto usuários da API que podem ajudar.

eu tendo os dados bancários eu ja consigo no meu proprio celular?

Por isto o E2EID não estava em nosso banco de dados, mas é uma questão financeiro entre os PSPs e não uma falha de API.

O cenário atual da GN não permite consultar um pix sem txid, logo não consigo buscar dados de um pix enviado via POST /v2/pix. Dessa forma, não existem maneiras de saber, via aplicação/integração, quando um pix é devolvido por parte do favorecido.

Pode ser o banco de dados da Receita (atualizado a cada 3 meses):
https://receita.economia.gov.br/orientacao/tributaria/cadastros/cadastro-nacional-de-pessoas-juridicas-cnpj/dados-publicos-cnpj
Pode ser algum serviço como receitaws, vai saber...