Termos mais procurados:
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
ah eh.. eu coloquei o ID/tamanho ali junto neh kk... mas, to vendo aqui, parece que ele tem que ter 32 caracteres pra consultar no endpoint /v2/pix/{e2eId}
Para qr code dinâmico sim, é obrigatório
Já para qr code estático não, pois o qr code estático não é vinculado a nenhuma cobrança
Para o que você está tentando fazer dar certo, você deveria gerar um qr code estático com no máximo 25 caracteres ao invés dos 28 que você está usando, pagá-lo e depois consultar, mas em outra rota GET /v2/pix/{e2eId}
Note que a consulta é pelo e2eID e não pelo txid
agora, como eu faço pra simular o pagamento ? Se eu pegar o certificado de produção, e tentar consultar um PIX real, já é pra retornar algo ali pra mim, certo?
pessoal, desculpa ficar perguntando, não tenho muita experiência em fazer essas requisições.. eu estou usando o vb.net, com o exemplo que eu peguei do site consegui fazer a comunicação e peguei aquele objeto JWS. Agora pra consultar se o PIX foi pago, como eu devo montar a requisição? Não achei no manual, nem um outro exemplo... seria um GET? é necessário informar o que exatamente no header?
Você pode seguir a ideia do Rubens e informar 2 paths pelo Location, um para as notificações de boletos e outro pelo Pix. As notificações da nossa API seguem um padrão onde você insere em seu servidor um arquivo para consultar o nosso token, veja mais detalhes aqui de como é o arquivo de consulta e exemplos de notificação por aqui https://dev.gerencianet.com.br/docs/notificacoes-recebendo .
Para as configurações da API-Pix é necessário o mTLS para receber as notificações que seguem um padrão diferente, não sendo necessário um arquivo de consulta de token, uma vez que enviamos um objeto pix já com todas as informações.
Este é o primeiro relato similar que vejo, mas se tivesse acontecido comigo, dividiria a análise do caso em 3 partes.
- certificar se o cliente realmente não foi debitado, uma vez que pelo relato, ele não sabe o saldo anterior e, aparente, não sabe consultar o histórico de movimentações
- certificar se houve mudança de status na GN que justifique a baixa da cobrança
- certificar se o sistema está fazendo baixas apenas com base em notificações realmente pagas, pois nem toda cobrança com status "CONCLUIDA" está de fato paga
Minha impressão é que pode ter ocorrido o seguinte (HIPÓTESE):
Algumas cobranças passam para o status "CONCLUIDA" em determinadas situações, principalmente quando consumimos a rota PUT /v2/cob. Não era pra acontecer, mas acontece. Daí, pode ser que quando o cliente leu o location, a cobrança pode ter mudado de status para "CONCLUIDA". Então, quando ele tentou pagar deu erro, pois a cobrança não estava mais "ATIVA". Uma notificação de mudança de status ocorreu ao alterar para "CONCLUIDA" e o sistema processou a baixa sem verificar se o array de pix estava devidamente preenchido
você pode consultar a cada X minutos a lista de pix recebidos nos últimos Y minutos (sendo Y um número algumas vezes maior que X por segurança) e "processar" todos que não tenha processado ainda
Consultar Pix.
AUTHORIZATIONS: OAUTH2 (pix.read)
Endpoint para consultar um Pix através de um e2eid GET /v2/pix/{e2eId}.
<@!783359762917752843>, verifiquei sim esta sua demanda.
Realizei vários testes, e constatei que realmente uma devolução realizada através do app, não é possível consultá-la através da rota /v2/pix/:e2eId/devolucao/:id
Acredito que isso acontece para evitar consulta excessiva. Pois para consultar a rota citada acima, necessita saber o id da devolução. Neste caso então, você não terá este id.
Com isso terá primeiro que realizar uma consulta na rota /v2/pix/:e2eId para obter o id da devolução, e nela você já possui todas as demais informações da devolução, não tendo necessidade de realizar outra consulta na rota /v2/pix/:e2eId/devolucao/:id
Mas de qualquer forma, levantamos esta questão para nosso time da API para melhor esclarecimento.
<@!783359762917752843>, fiz testes neste momento. Quando você solicita uma devolução, é gerado o código rtrId (ReturnIdentification da devolução).
Ao consultar a devolução você deve estar passando o rtrId. O correto é passar o endToEndId do PIX e o ID da que usou na solicitação da devolução
Há uma anomalia no endpoint /v2/pix para o método "Consultar Pix recebidos".
Estou filtrando algumas cobranças para analisar os pagamentos e está acontencendo o seguinte:
Ao filtrar os PIX recebidos em um determinado período, a API informou um total de 16 pix recebidos.
só pra constar.. isso nao é no webhook, é no serviço de consultar a cobrança PIX
Mas sem txid dá pra consultar no /pix
Bom dia, <@!783359762917752843>. Está implementada sim. Em nossa collection do Postman em Consultar Pix recebidos, e informa o parâmetro desejado, podendo ser cpf ou cnpj.
Exemplo da consulta:
https://api-pix-h.gerencianet.com.br/v2/pix?inicio=2020-10-15T00:00:00.000Z&fim=2020-10-19T23:00:00.000Z&cpf=62499313099
eu tou fazendo o endpoind de consultar o pix
e vi que na documentação nao mostra os exemplos as Respostas de Sucesso(200) e Falhas/erros do consumo....
Fiz algumas vendas aqui com Pix em produção por volta das 13h e ao consultar pelo consultaListaPixRecebidos.php ele devolve que os pixt foram feitos às 16h de hoje, só que agora são 13:38
tem algum jeito de fazer um troubleshoot do pq eu nao receberia uma notificação no meu webhook? Chamando o rest p/ consultar os webhooks ele aparece registrado, mandei um pix com txid (ate apareceu no extrato a identificação) mas meu servidor nao recebeu nenhuma chamada...
Esse e2eId é o endToEndId que retorna nas chamadas "Consultar Cobrança", "Consultar Pix" e "Consultar Pix Recebidos"
Pessoal, atualizamos a collection do Postman (https://documenter.getpostman.com/view/13574984/TVetcm6R) com os endpoints consultar Pix e solicitar devolução. E estamos inserindo a descrição de cada endpoint em nossa documentação.
