Histórico de mensagens sobre webhook

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 ?

## Objetivo

Permitir que o EC defina algumas configurações:

- Quando aceitar um txid;
- Aceitar ou não Pix Manual;
- Quais notificações receber via webhooks;
- Receber ou não a tarifa no webhook;
- Outras configurações podem surgir.

---

# PUT /gn/config

## Input

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

<@!522899003663450113> acredito que podemos assumir que, se webhook.notificar.envio for habilitado, a notificação do envio de Pix será enviada com a informação se foi sucesso ou falha. Em caso de falha, irá constar o motivo, que pode ser uma recusa ou timeout do PSP recebedor.

Não esqueci disso. Acho bem pertinente esse webhook.

Você diz enquanto recebe uma notificação de webhook?

Será que todo Pix Manual não deve ser entendido como transferência e, por conseguinte, ser sempre aceito e nunca acionar webhook? 🤔

Atualizando:

PUT /gn/config

Até então estamos assim:

PUT /gn/config

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