Histórico de mensagens sobre webhook

Pensando na implementação lógica, o fluxo seria mais ou menos esse:

-> se o txid é dinâmico {26,35} a GN valida com base na chave + txid se existe cobrança (talvez isso até já esteja implementado hoje).
-> elseif, txid é nulo, GN consulta a configuração da conta do EC recebedor (ou da chave) se deve acatar Pix com txid nulo.

se a GN tiver como diferenciar quando o Pix foi enviado via "manual" (informando dados bancários) ou com uso da chave DICT, o ideal seria a configuração de aceitar/não os recebimentos com txid nulo ser por chave + uma configuração extra para bloquear todos os recebimentos manuais (que nunca tem txid associado).

se não tiver como diferenciar, a configuração poderia ser global (por conta transacional), com opção de sobrescrever a escolha para chaves individuais (assim poderia bloquear recebimentos com txid nulo para toda a conta [que seria o comportamento padrão] e autorizar o txid nulo em uma chave particular).

e, futuramente:
-> else (txid é estático), valida conforme as regras de aceite do EC (por regex match ou enviando o request de validação para webhookURL/txidmatch, como sugeri acima).

e esse "futuramente" eu não consigo nem ver uma demanda relevante. o importante são as outras funções.

Certo então realmente webhook é indispensável na aplicação

Que eu ia adicionar o webhooks quando fosse adicionar cobranças sem fazer pela imediata. Mas posso adicionar desde o inicio

Iria comentar isso <@!127179327447105537> , para a sincronização com seu sistema acredito que a melhor abordagem é o webhook

<@!127179327447105537> e eu adiciono que o webhook é o que vai te informar primeiro do pagamento, propiciando a melhor experiência para seu cliente.

<@!127179327447105537> , porém, eu te recomendo implantar o webhook. Não que seja essencial para qualquer operação, mas especialmente em escala, usar o webhook diminui a necessidade de consultas autônomas à API para obter o status da cobrança e, consequentemente, a carga (processamento e rede) do seu servidor.

Na sua pergunta original, você já tinha perguntado exatamente isso:

Essa é a outra pergunta. Mas reformulando a pergunta, eu quero saber se a cobrança imediata irá me retornar como concluida a transação se bem sucedida para que eu não tenha que depender de webhooks para saber o estado atual da cobrança

Bom dia, sobre a cobrança imediata, no ambiente de hml ele retorna como status ATIVA no ambiente de produção ela já voltaria como CONCLUIDA ou realmente sou obrigado a adicionar um webhook para saber se a transação conclui?

Mas em relação ao Webhook é semelhante sim

Uso links de pagamento pros meus clientes, onde recebo apenas via PIX. Atualmente uso os webhooks do mercadopago para receber as notificações de pagamento e proceder com a integração do meu sistema

Uma observação é: Se for utilizar o PIX, não irá conseguir usar o Webhook em ambiente compartilhado.

Vc diz quem envia o Pix ou quem recebe ? Quem envia recebe notificação no webhook.

Tivemos dificuldade em gerar uma chave nova via app, então criamos uma nova aplicação, que será apenas para pagamentos, sem webhook

bom dia. O webhook é ligado á chave pix

Bom dia pessoal, uma dúvida. As notificações via webhook ficam atreladas a uma chave pix ou ao client_id da aplicação? 2 aplicações diferentes usando a mesma chave pix utilizariam 2 webhooks diferentes ou o mesmo?

Bom dia, <@!811410181933498421>. Isto não é possível, mas é permitido cadastrar mais de uma chave para o mesmo webhook.

Isso é só para testes, até pq não consigo fazer nada em ambiente de homologação da gerencianet. Como estou em fase ainda de desenvolvimento o meu webhook é "local"

Posso cadastrar mais de um webhook para a mesma chave ?

tive uma ideia aqui. e se a GN mandar um request para webhookURL/txidmatch passando o txid recebido, com um timeout de uns 3 segundos, e o EC responde se a GN deve ou não aceitar o recebimento?

talvez o problema seja o BC encasquetar com o prazo de conclusão do recebimento (a média de tempo iria subir)