Histórico de mensagens sobre cobranças em pix

Você se refere ao location do QrCode dinâmico?
Consultando o location possui o status da cobrança, ou seja, sendo um QrCode que pode ser pago várias vezes, se você receber um Pix por esta cobrança ela continuará com o status "ATIVA".

Com o webhook cadastrado com sua chave, com as cobranças que possuem txid você é notificado quando um Pix é recebido.
Além disso, pode ser ser realizada a consulta pela rota /v2/pix com os parâmetros inicio=data_da_criação da cobrança, fim=data_atual e o txid da cobrança

Aconteceu comigo 6 vezes, mas como faço o tratamento para verificar se a soma dos pix recebidos menos a soma das possíveis devoluções bate com o valor devido, não realizei nenhuma baixa indevida. Você consegue verificar isso através de uma consulta GET /v2/cob e filtrando "inicio=data_inicial&fim=data_final&status=CONCLUIDA". Feito o filtro, faça uma varredura para verificar quais estão sem o array pix. Daí você verifica o txid dessas cobranças no seu sistema para ver se estão marcadas como pagas.
Edit: aconteceu da cobrança mudar o status, não a parte do usuário tentar pagar e dar o erro causando a mudança de status

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

<@!780500321994539068> uma dúvida, eu consigo visualizar apenas as cobranças pagas, qual endpoint que visualizo as cobranças geradas?

Acho que você não entendeu o pedido do Ezequiel. Ele quer evitar que a conta dele receba Pix que não tenham txid. A GN já ofereceu isso aqui nesse mesmo canal no passado (não exatamente com base na existência de txid, mas com base na existência de cobrança vinculada - então a GN verificaria se existe cobrança para o txid e, se existir, acata o pagamento, do contrário, rejeita - porém o BACEN já deu abertura para que a análise seja com base na existência do txid (independentemente de haver cobrança ou não), só cabe à GN a decisão de atender esse pedido; de qualquer forma, talvez a oferta existente, já atenda a necessidade do Ezequiel, não sei se ele precisa receber pagamentos com txid vindos de QR estáticos, não ligados à cobranças).

<@!375094642238029824> se você explicar o cenário (por que precisa gerar cobranças para recebedores que não usam GN), talvez possamos entender melhor e direcionar a melhor forma de alcançar o que você deseja.

E as cobranças geradas pela API da GN devem ser, obrigatoriamente, direcionadas a uma chave de recebedor que esteja registrada na GN.

<@!375094642238029824> , a API da GN só gera cobranças (que vc representa com qr dinâmicos para o devedor escanear/copiar e pagar). QR codes estáticos são gerados no aplicativo do banco do recebedor ou por você, de forma autônoma (sem API alguma).

e só dá pra gerar cobranças para chaves na sua conta, mas QR codes estáticos (independentes de API) vc pode gerar pra qualquer conta

Não tem como no momento, ele não é apto para pagamentos. Vamos realizar algumas melhorias no ambiente de homologação para possibilitar estes testes. Recomendamos que gere cobranças de R$0,01 em produção para testes de pagamento

Sugerimos utilizar em produção com valores de R$0,01. Até o dia 30/04/2021 não haverá cobranças pelo consumo via API

Este é um problema da GN, pelo que o pessoal informou já estão verificando internamente.

Segue as palavras do <@!671762828046106646>:
"Boa tarde Joel! A demanda está sendo tratada com prioridade, foi notado que essa alteração ocorre em momentos aleatórios. Exemplo: Fizemos 20 testes realizando o mesmo PATCH em cobranças idênticas e em 2 casos o status foi alterado e nos outros não
Por essa aleatoriedade a falha fica mais difícil de ser corrigida, mas o time todo está focado na correção e até o fim desta semana daremos um parecer"

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.

eu acho que é um bug.. porque o status de CONCLUIDA ficou apenas nas cobranças que eu paguei...

Fiz alguns testes aqui e consegui gerar as cobranças em ambiente de homologação. Você está utilizando alguma SDK ou está fazendo pelo Postman?

Integrações mais facilitadas surgirão com o tempo. Observe que o BACEN determinou a obrigatoriedade de oferta da API Pix padronizada pelos PSPs que quiserem ofertar API Pix. Talvez a GN oferte outra API posteriormente, mais próxima do que você está acostumado (onde o controle sobre as cobranças e os detalhes internos do arranjo é menor).

Os status das cobranças da API-Pix são os mesmo definidos pelo BACEN. Os status da API para boleto e cartão são diferentes e também estão definidos em nossa documentação.

Exato, já que sabemos os possíveis retornos das cobranças.

Pessoal outra dúvida, para emitir o Pix/Cobrança temos o calendario, tentei passar assim:

a API de geração e de baixa de cobranças Pix, existe. e programaticamente, dá pra "baixar" ou cancelar boletos pela API, também. então de alguma maneira, dá. mas não como uma solução pronta. tem que desenvolver em cima das duas API e fazer funcionar como você quer