Histórico de mensagens sobre dados em pix

Já chequei, cliente secret, client id estão conforme os dados lá da minha area restrita do gerenciant.

Tentei alterar apenas os dados do config-pix.php do exemplo passado pelo https://www.youtube.com/watch?v=6Es3i2eH5K4 (obtive os IDs e gerei o arquivo pem seguindo as orientações)

EM_PROCESSAMENTO é retornado quando os dados bancários e chave estão corretos, mas ainda depende do PSP recebedor se ele vai aceitar ou não a transação, esta resposta definitiva é retornada no webhook.

Boa tarde <@!783359762917752843>, a resposta já vem no momento da requisição, mas o webhook também é acionado com os dados do envio. Você pode configurar sim, mas neste caso o melhor cenário seria ter uma chave para envio de Pix com um webhook e outra chave com o segundo webhook exclusivo para recebimento, pois, cada chave só pode estar associada a um único webhook.

Técnicamente é o seguinte...

- Você cadastra o webhook para seu endpoint "exemplo.com/webhook"
- A GN vai enviar uma primeira requisição para este endpoint sem o certificado, e seu servidor deve RECUSAR
- Em seguida a GN vai enviar outra requisição, dessa vez com com certificado para handshake, mas vai servir apenas para confirmar o PIX gerado, vai enviar um POST com um nome de evento e a data_criacao
- Caso o cliente pagar o PIX, a GN vai enviar uma nova requisição com certificado para handshake para o endpoint mas dessa vez vão adicionar um "/pix" a mais na requisição, ou seja, vai enviar para "exemplo.com/webhook/pix". Você deve deixar este endpoint também disponível e vai receber um POST com os dados do PIX recebido.

Bom dia <@!812297338605273098>, respondendo ao questionamento que você fez no 2, sim é possível fazer o envio de Pix de sua conta Gerencianet para uma outra chave/conta via API. Para isto temos o endpoint POST /v2/pix (https://dev.gerencianet.com.br/docs#section-requisitar-envio-de-pix-) que permite o envio para uma outra conta via chave ou dados bancários.
Além disso via API você pode adicionar diversos recursos em seu site como cobranças estáticas e dinâmicas e fazer o controle via endpoints da API. Outro recurso interessante é o webhook que automatiza o seu sistema com os Pix recebidos, sem a necessidade de ter que construir uma rotina que fica realizando consultas na API. Você encontra tudo isso e mais na documentação e caso tenha dúvidas pode mandar aqui canal que te auxiliamos.

<@!715273512688025630> complementando com mais alguns entendimentos:
- A instituição recebedora que aparecerá ao pagador é sempre Gerencianet
- Os dados do estabelecimento do recebedor que aparecerão ao pagador serão: nome fantasia (caso exista) ou razão social.

Importante: não importa o que aparece no BR Code, a informação oficial é a que está no DICT. Ou seja, o correto é que o PSP sempre busque os dados da chave via DICT, ao invés de "confiar" no BR Code. Inclusive, isso é uma questão de segurança. Se o PSP não faz isso, pode acontecer do pagador achar que o pagamento está indo pro A ao invés do B.

Excluir imagem por conter dados sensíveis 🙂

Não, os dados obrigatórios e opcionais você pode encontrar em nossa documentação, detalhados em cada endpoint: https://dev.gerencianet.com.br/docs

e todos esses dados são obrigatórios?

Sim, temos os dados completos do veículo.

é 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?