Histórico de mensagens sobre webhook em pix

Não entendi esta:

Integrador cadastrou a url base https://gerencianet.com.br/?id=0000x22, ao acionar o webhook uma requisição do tipo POST será enviada para https://gerencianet.com.br/pix?id=0000x22

A possibilidade mais simples de contornar a concatenação do /pix que a documentação força é justamente colocar um ?x= ao fim da URL para ficar ?x=/pix.

então pergunto:

1. qual a razão para agregar o /pix "no meio" da URL que foi definida pelo integrador e não no fim?
2. isso vai contra a documentação atual que diz que o /pix irá (sempre) no fim da URL - e se for pra mudar o conceito, seria melhor que esse /pix fosse retirado.

e sugiro aos integradores que estão lendo agora: não usem query params na URL do webhook conforme esse exemplo (prefiram path params)

O achar isso péssimo era uma discussão para quando da elaboração do padrão do BACEN. Agora já era.

E há sim uma vantagem que é permitir a adoção futura de novos verbos no webhook.

aproveitando o gancho, qual seria o resultado para um webhook cadastrado como:
https://meusite.com.br/algumapasta/algumarquivo.php

então nao sera mais obrigado ter um certificado para receber o webhook e isso?

@Efí como faço para saber qual taxa foi cobrada em cima da transação liquidada do pix? eu sei que tem as regras lá no site, mas supondo que isso mude, a "fee" deveria vir no callback da confirmação/devolução, não? em último caso, talvez estar disponível ao consultar o pix recebido
(eu li a discussão nas sugestões, deu a entender que querem colocar no postback do webhook, será isso mesmo?)

Bom dia Branco! No momento sim, pois, servidores compartilhados não permitem que o cliente faça a inclusão de nosso CA e sem o mesmo o mTLS não ocorre, impossibilitando o cadastro do webhook. Mas estamos discutindo outras formas de contornar essa situação para os clientes que tem servidores compartilhados.

bom dia, <@!671762828046106646> , <@!775350441965649951> , <@!780500321994539068> , o servidor do webhook tem que ser dedicado, ou seja, de maneira alguma a hospedagem devem ser compartilhada, confere ou isso nao tem nada haver ?

No endpoint POST /pix caso a chave do recebedor não exista, você receberá um erro na hora. Isso significa que o webhook nem será acionado pois a solicitação de envio de Pix não funcionou.

Sobre os aplicativos conseguirem indicar contatos cujo telefone/email já estejam cadastrados no Pix, sabemos que estuda-se isso no BC e inclusive nós enviamos há pouco tempo uma proposta relacionada.

Pode ser que em breve seja viável uma "consulta no cache do DICT", de forma que não se gaste as fichas do bucket oficial...

A ideia é conseguir validar a chave antes de enviar o Pix e informar que essa chave não existe para fazer o Pix, por exemplo, sem a necessidade de esperar o webhook ou o processamento da solicitação de envio do Pix.

estou tentando RESGISTRAR o webhook somente

Isso é do seu certificado, mas precisa ver como seu sistema responde ao certificado que a GN usa para acessar o webhook.

<@!664563985885954079>, o e2eid você consegue somente depois de pagar o Pix.. Então você pegar ele através do webhook que você recebe ou consultando Pix recebidos

Irei verificar seu ticket neste momento.
Realmente, na SDK não está disponibilizado as funcoes para webhook, mas iremos auxiliá-lo!

o sdk em php nao tem as funcoes para webhook

para "consumir" a API, cada aplicação (par de client_id / client_secret), recebe um arquivo .p12 (contendo certificado + chave, que podem ser desmembrados em .cer e .key, se for necessário);

para receber os "callbacks" no seu endpoint de webhook, você precisa de um certificado específico para tal - este é único para todos os clientes.

a brecha que existe - pouco explorável - é que outros clientes podem definir a sua URL de webhook para as chaves deles, e recebimentos deles acionarem o seu webhook intencionalmente

não entendi se a sua preocupação é por ser ou por não ser único. pois ele é único no caso dos webhooks (o que é diferente entre cada cliente é o certificado de consumo da API; enquanto o dos webhooks é único para todos os clientes)

se caso alguem pegar o mesmo certificado e mandar a requisiçao pro meu enpoint do webhook

o próprio BACEN que retirou da spec argumentando que um Pix (e2eid) só chega ao cliente quando já está concluído, então você deve se basear na existência ou não de items de devolução dentro do pix pra saber quanto recebeu referente ao e2eid [e quanto foi devolvido, se for o caso] e não num campo de "status", pois um webhook pode ser acionado no momento que uma devolução acontecer, por exemplo e aí o status fica meio dúbio.. deveria ser, ainda, recebimento/recebido (pq o Pix foi recebido) ou devolução/devolvido por ser uma notificação acionada pelo gatilho de devolução? se o Pix for R$ 100 e a devolução for parcial, de R$ 10, fica ainda mais complicado se basear só nesse campo.

no video o webhook volta o status e tal