Histórico de mensagens sobre pix

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"]

É que dessa forma vocês não precisam coordenar uma mudança do tipo "vira a chave"... quem já estiver pronto, já ativa assim.
(E no /pix poderia já ter o ?client_id também)

<@!780500321994539068>, bom dia!. Sugere então testarmos com uma url https://meudominio.com.br/pix por exemplo, e testar sem o /pix. Certo?

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"}]}

MercadoPago implementou Pix no web checkout. Um QR code estático (com a chave do recebedor) é gerado com txid = "mpcheckout" + ID do checkout.
Diferentemente do boleto pendente (que é notificado e consta nas "atividades" da conta imediatamente), o checkout concluído via Pix só passa a constar do relatório de atividades (e é notificado) se o Pix for pago.

os links internos da documentação (como o "veja aqui" no quadro do txid que comentei acima) são no formato https://dev.gerencianet.com.br/v1/docs/api-pix#section-id-da-transa-o o que causa o carregamento de uma nova página se o visitante estiver lendo em https://dev.gerencianet.com.br/docs (sem o /v1 no path) e, quase sempre, não rola a tela para âncora que foi referenciada no link.

Os links poderiam ser resumidos à ancora: #section-id-da-transa-o ou os endereços com/sem /v1 poderiam ser unificados (o endereço sem /v1 redirecionar para o endereço com /v1) aí links poderiam ser completos ou ter apenas a âncora que não ficariam quebrados.

Eu optei por usar a página de sucesso mesmo para exibir o QR Code e o Copia e Cola do Pix.
Assim já consigo mudar para Aguardando Pagamento no Status e salvo também no Histórico do Pedido.

Logo se o cliente sair da tela de Sucesso, pode ainda acessar no Detalhes do Pedido.
Faço desta forma com Boleto tb a alguns anos.

Já com outro Pagamento, adotei a ideia de verificar a cada X segundos tb por JS e depois mandar para o sucesso ou quando chegar no tempo limite de X minutos de espera.

se vc estiver consultando pelo GET /pix na GN, 10 segundos é interessante, conservador. mas se vc vai consultar no seu próprio banco de dados se o pedido/pix tá pago ou não, 2 ou 5 segundos é perfeitamente aceitável. e seja como for, é interessante encadear as consultas (acionar a primeira, e fazer a próxima ser enviada após o retorno da primeira + X segundos, por um setTimeout disparado). se fizer um setInterval pode emparelhar muitos requests e sobrecarregar seu sistema

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).

(exceto pelos endpoints/métodos adicionais, criados pela GN, obviamente, que vc pode usar hoje e poderão - ou não - sofrer padronização no futuro. ex: o endpoint de envio de Pix)

dica pra todo mundo lendo aqui: se vc seguir a documentação do BACEN, já estará sempre um passo a frente e não vai depender de avisos da GN quando as coisas mudarem 😉 não contem com nenhuma informação que não for padrão. https://bacen.github.io/pix-api/

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

não tá enviando Pix? (não entendi o /pix)

E o pior que a GN não ta enviando /pix

<@!779417651947896852> acho interessante vc ler esse documento: https://www.bcb.gov.br/content/estabilidadefinanceira/pix/Regulamento_Pix/II-ManualdePadroesparaIniciacaodoPix.pdf

até vc receber o Pix, vc não tem o e2eid, e ao consultar pelo txid, terá um array vazio. ao receber um Pix, você terá um e2eid daquela transação, e a consulta por txid trará a lista - com 1 elemento, se só tiver recebido 1 pix (ou os detalhes completos, se consultar pelo e2eid)

se vc tem o e2eid de um Pix recebido, ele sempre é "RECEBIDO" (efetivado), nunca diferente disso