Histórico de mensagens sobre PSP em pix

Mais um para coleção de problemas em PSPs pagadores... mas o PSP recebedor também deveria ter bloqueado.

Expirada não significa removida. Significa apenas que o PSP pagador e o PSP recebedor não devem mais fazer pagamentos nela.

funcionou o pagamento via Itau, outros PSP's ainda estao itermitentes

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.

ah sim, não manda mais o "status" (já que webhook só é acionado pelo PSP recebedor quando pix é recebido)

a diferença é que no TED, o ID de transação que o pagador vê, não é necessariamente o que você vê como recebedor. o seu banco recebedor gera um ID localmente também quando a transação "entra". já no PIX, o ID que veio do PSP pagador é persistente e a GN usa o mesmo ID pra identificar a transação do lado dela (e vc poder consultá-la por esse ID)

via de regra:
txid = identificador que o RECEBEDOR gera (você); pode se repetir (qr estático) ou não (dinâmico)
e2eid = identificador de uma transferência ÚNICA (pensa num TED.. quando é concluído, ele tem um ID de transação, o e2eid no contexto do Pix é análogo ao ID da transação TED) que o PSP do PAGADOR vai gerar e a GN vai te informar

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

Ao que eu lembre o E2EID é gerado pelo PSP pagador. Por isso que no envio ele é possível antes de se completar o envio, mas no recebimento depende da chegada do Pix.

então.. mas esse E2EID disponibilizado no retorno da solicitação de envio, como ele está disponível antes da conclusão do envio, logo, no meu entender, elementos e2eid podem existir mesmo antes da conclusão do Pix (ele não é "gerado" apenas na efetivação do envio, mas antes disso - ainda que acessível apenas do lado do PSP pagador). no caso de recebimentos, a GN só toma conhecimento do E2EID de um Pix depois que já está efetivado? seria essa a justificativa para não ter status nos webhook (toda notificação sempre se refere a um Pix efetivado e por isso não vemos mais um elemento status no corpo do request)?

O problema do estático é que ainda não gera notificações via callback. Daí você não ficará sabendo qual o e2eId do seu txid, a não ser que você fica consultando a lista de pix recebidos em um determinado período.
Outro problema crítico do estático é que alguns PSPs não estão devolvendo o txid, daí você não tem a menor ideia de quem pagou e porque pagou

Quando você cria o PUT /cob/:txid está criando um QRCode Dinâmico. Ele contém um location que o PSP Pagador usa para pegar o payload da cobrança.

Mas isso acontece com pagamento em qualquer PSP, não apenas no Itaú.

Sim, o PSP pagador deve enviar a informação para que o campo seja exibido

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

Sim, de desenvolvimento vai ser recusado por outros PSPs.

Eu só tenho dois chutes para uma devolução não dar certo: problema no PSP e conta que pagou o Pix ter sido encerrada. Esse 2o. motivo pode tentar quantas vezes quiser que não vai dar certo.

O status NAO_REALIZADO pode ocorrer desde instabilidades a recusa pelo PSP pagador.

Significa que aquela tentativa de devolução não deu certo. Se uma nova tem chance de funcionar, não dá para saber... se foi instabilidade no PSP, uma nova pode funcionar.

Não, o BACEN mantem um acervo de URLs dos PSPs autorizadas a disponibilizar payloads, e a do seu serviço não é uma delas.