Termos mais procurados:
{"parametros":{"inicio":"2020-12-01T16:01:35Z","fim":"2020-12-23T15:10:00Z","paginacao":{"paginaAtual":0,"itensPorPagina":100,"quantidadeDePaginas":1,"quantidadeTotalDeItens":1}},"pix":[{"endToEndId":"E18236120202012221753s0009417GUD","txid":"1234567890123456789012345","valor":"1.00","horario":"2020-12-22T17:53:09.000Z","infoPagador":"mensagem de teste"}]}
Obrigado <@!440035527127990273>. <@!728308672043941999> Pontuo que havia trocado somente a rota desta mensagem https://discord.com/channels/775322853884821504/775328670784159744/790996877885702164
O correto é GET /v2/pix/ (Consultar Pix recebidos) como está fazendo, e não GET /v2/cob/ (Consultar lista de cobranças)
além disso, as datas são em tempo UTC, então para os parâmetros que vc passou, o retorno seria de Pix recebidos entre 01/12/2020 às 13:01:35 e 22/12/2020 às 12:10:00 (se vc acabou de pagar há pouco, não será retornado, pois já são 15:09)
e na rota GET /v2/cob/ (Consultar lista de cobranças) não aparece o PIX que eu acabei de fazer lá..
<@!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}
Você conseguirá consultá-los se ele tive sido pago. Ou seja, quando tiver o endToEndId. Daí você poderá consultá-lo através da rota GET /v2/pix/ (Consultar Pix recebidos)
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}
Isto <@!558328193438973972>. Só podem ser pagos Pix que forem gerados em produção
Sugerimos utilizar em produção com cobranças de baixo valor. Até o dia 30/04/2021 não haverá cobranças pelo consumo via API
Teste o seu Copia e Cola aqui = https://pix.nascent.com.br/tools/pix-qr-decoder/
Pessoal alguem sabe se o PIX esta fora? Tentei efeutar o pgto em mais de um PSP e todos estao dando erro, os dados de cobrança sao reconhecidos pelo app mas ao efetuar o pgto da erro.
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"]
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"}]}
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
