Histórico de mensagens sobre webhook

mas no relatório tem o ID que eles chamam de "Operação". e eles tb notificam via webhook as "operações" pagas via Pix. o que mais vc precisa no relatório? 🤔

Boa tarde, estou fazendo a questão do webhook, fiquei com algumas dúvidas, o parâmetro "chave" diz respeito a chave pix mesmo ou é o txid?

<@!775350441965649951> , desculpa me intrometer, mas você falou algumas coisas erradas.

1. o GET /pix?txid=xxx é para consultar Pix recebidos (indiferente serem oriundos de QR estático ou dinâmico, tendo txid eles retornam nessa consulta), e não cobranças (que é no GET /cob)

2. pra consultar o(s) Pix recebido(s) por QR estático com um determinado txid ficaria GET /pix?txid=xxx&inicio=data_inicio&fim=data_fim

3. tendo o e2eid (que vem no retorno da consulta acima ou pelo webhook - quando a GN estiver notificando recebimentos oriundos de QR estático), aí pode-se consultar GET /pix/{e2eid}

e se quiser mais detalhes, depois que já tiver o e2eid (obtido nessa consulta acima, ou por webhook, quando a GN passar a notificar pagamentos via qr estáticos), poderá usar o GET /pix/{e2eid}

#dica Tenha o próprio WEBHOOK para testar em modo desenvolvimento. Como ? Use o postman para enviar POST para a sua url de recebimento dos callback . Assim você pode testar todas as possibilidades existentes em modo desenvolvimento , sem ter que ficar entrando em bancos e pagando BRCodes para depois esperar o recebimento do callback, estou testando assim e ajuda muito 🙂

Bom dia <@!781944293739986984>, verifique se você trocou o CA para ambiente de produção.

Por gentileza, uma duvida 🙂
Em que situação o webhook envia isso = já para o PIX enviado, temos:
• tipo "SOLICITACAO";
• status possiveis: ["EM_PROCESSAMENTO", "REALIZADO", "NAO_REALIZADO"]

estou fazendo um teste em produção, no endpoint de configuar webhook
poren esta me retornando um erro
"A autenticação de TLS mútuo não esta configurada na URL informada"

Sugestão para a incorporação do /pix: no teste de ativação do webhook, testar primeiro com /pix. Se funcionar, já sabe que esse cliente está preparado e usa dessa forma. Se não funcionar, por enquanto ativa sem /pix, vai registrando para notificar os clientes para mudar.

Bom dia! <@!522899003663450113> ontem informamos que houveram mudanças nas notificações de nossos pix.
São elas: nós retiramos o campo tipo e status das notificações de PIX recebidos (seguindo a especificação do BACEN).

já para o PIX enviado, temos:
• tipo "SOLICITACAO";
• status possiveis: ["EM_PROCESSAMENTO", "REALIZADO", "NAO_REALIZADO"]

A mudança no retorno do webhook é para adequar as especificações do BACEN. A principal diferença foi a remoção dos status e tipo do Pix recebido. Um exemplo de como está a notificação de Pix recebido:
{"pix":[{"endToEndId":"E00416965620122145239O7ZcRRTsI88","txid":"fc9a43k6ff39ai84ryP5fd41a9718","valor":"0.01","horario":"2020-12-21T12:39:09.000Z"}]}

#deucerto O bom de estudar 5 dias é que em poucas horas consegui mudar tudo aqui. Funcionando normalmente com validação do retorno do webhook com o txid. Agora vamos para a etapa do websocket e da página de obrigado 🙂 O remarketing agradece 🙂

Como ainda não tenho o webhook operando, minha principal rota de baixa é pelo ajax de 10 em 10 segundos.
Sim, o final da análise de uma consulta aciona a consulta seguinte via setTimeout, caso o pagamento ainda não tenha sido feito.
Dificilmente uso o setInterval

aqui eu to fazendo assim:
- assim que a pessoa gera o PIX, eu coloco o qrcode e o pix copia-cola na tela e instruo ele a realizar o pagamento
- enquanto ela vê o PIX, eu rodo uma checagem de 2 em 2segundos analisando se em meu banco de dados o PIX consta como pago
- quando a pessoa paga, no retorno via webhook eu atualizo em meu banco de dados para PAGO...
- assim que a checagem consta como "pix pago", o usuário recebe uma mensagem de confirmação e é redirecionado pra um histórico de pagamentos

como fallback (ainda nao fiz), é bom ter um script pronto pra consultar os pix do dia e ver se nada ficou "esquecido", talvez um cron a cada X minutos (ou horas).

Dois sistemas estavam prontos um LMS e o outro um ecomm em alguns clientes, estou mudando a lógica e os códigos ,pois tudo eram através dos status vindos dos webhooks 😦

me refiro ao conteúdo do retorno de comandos e endpoints. pelo que eu entendi, a GN ainda esta adequando tudo ao mesmo tempo que o BACEN está lançando novas versões mas, pelo menos em teoria, modificações na especificação do bacen dentro de uma mesma major version não devem causar quebra de compatibilidade. então se vc contar com um elemento no webhook que a GN enviava mas o exemplo do BACEN não contempla, então vc tá se ancorando num elemento que pode sumir a qualquer momento do webhook da GN (como aconteceu)

ah sim, não manda mais o "status" (já que webhook só é acionado pelo PSP recebedor quando pix é recebido)

Foi modificado sim o webhook para mandar apenas array pix como previsto na especificação do BACEN.

ah, vc diz do /pix na URL do webhook, saquei

Os webhooks pararam aqui 😦

sim. mas isso você śo pode fazer se souber o e2eid de uma transação da qual quer consultar detalhes. e vc não sabe o e2eid de uma transação até que:
- faça um GET /pix?txid=... e obtenha o e2eid da transação que quer consultar detalhes; ou
- receba um webhook informando o e2eid de uma transação que vc recebeu (o que a GN só está fazendo nos QR dinâmicos, por enquanto);
por isso, se usar QR estático, tem que fazer polling com o GET /pix?txid=... em vez de GET /pix/:e2eid