Histórico de mensagens sobre pagamentos

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}

Não, não devem. É essa parte que o pessoal tem testado em produção com pagamentos de baixo valor.

O meu sistema é mais simples, a pessoa só paga a mensalidade, sem carrinho. O fluxo de pagamentos é mais básico

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

também, mas não apenas isso. e ele está numa etapa de integração muito anterior às devoluções. não vamos complicar a cabeça dele 🙂 ele quer saber como consultar os pagamentos recebidos

Aliás, os curiosos podem analisar o E2EID que começa com o ISPB para ver que PSPs geram mais pagamentos.

e2eid é o "id da transação (INDIVIDUAL) ponta a ponta", ou seja, "de um Pix enviado/recebido"
txid é um "identificador" que pode ser único (cobranças) ou agregador (no caso de qr estático, pois admite-se múltiplos pagamentos do mesmo QR com mesmo txid)

outra coisa, tem como eu simular esses pagamentos em homologação??

Agora notei que não vem mais o status na notificação do weebhook, daí quebrou a baixa automática aqui.... no caso só está sendo notificados pagamentos agora ?

Mas nem sempre né? A maioria dos meus pagamentos vem sem (me refiro a infoPagador), isso é por causa do PSP Pagador?

ok, aqui para mim esta normal as notificações de pagamentos.

eu tenho a sensação que o qr dinâmico (e sua cobrança associada) tinha sido pensado para admitir múltiplos pagamentos e, posteriormente, reavaliaram a questão e passaram a tratar de forma mais próxima a um boleto registrado onde o valor pago deve ser igual ou maior (quando houver multa/juros) ao boleto, especialmente depois que mencionaram a ideia do "reuso de location", que serve para o propósito de cobranças recorrentes de um mesmo devedor com valores que podem variar (contas de consumo, por exemplo)

Notar que dois pagamentos só configuram duplicidade se a soma dos valores exceder o valor cobrado...

Sim, temos como lidar, é só devolver os pagamentos em duplicidades, a questão é receber as notificações e também temos que ler via api os status e de quantos txid iguais foram pagos.

Mais deixando o BRcode dinamico para ser pago apenas uma vez isso já elimina a possibilidade de dois pagamentos, correto ?

<@!783359762917752843> e <@!440035527127990273> vou levar essa questão de bloqueio de pagamentos sem txid a nível de chave e retorno para vocês.

esse problema específico ainda existe em outros bancos; e agora tem o outro, do "histórico mal feito" de alguns PSPs, onde vc paga um QR estático ou dinâmico com txid, ele guarda só a chave do recebedor e mostra num histórico pra vc enviar outros pagamentos.. como se bastasse identificar o recebedor pela chave. e o cliente paga por ali, sem ter noção de que precisa ler um novo QR

Não sei se entendi bem o cenário, mas você quer recusar pagamentos de PSPs que não enviam o txid?

Especulação minha, eu acho que há algum entrave relacionado ao financeiro.
Se a GN fizer tal filtro, seria possível receber todos os pagamentos via qr code estático, sem custo, e ainda fazer a conciliação, bastando para isso gerar qr code estático com txid.

mas aí tu bloqueia todos pagamentos estáticos..