Histórico de mensagens sobre PSP em pix

Sim, melhor fazer um loop. Inclusive por sobrevivência a mudanças quer seja de código na Gerencianet, quer seja de mudança de PSP.

Não. Imagine que você tenha emitido duas cobranças para duas pessoas diferentes que tenham conta no mesmo PSP e façam o pagamento ao mesmo tempo. O formato de envio do BACEN para os PSPs permite agregar mais de uma transação em uma mensagem (chamada PACS.008), então pode acontecer das duas virem para você numa única notificação.

<@!780500321994539068> , mestre, qual outro PSP que possa enviar o dado de pagador, vc conhece outro alem do GN ?

É função do número de transação efetivamente realizadas. Se ficar consultando e não realizar transação, o PSP fica limitado e não consegue consultar o DICT.

pq se os outros PSPs possuem

O BACEN tirou isso da API e a GN tirou também. Mas outros PSPs disponibilizam.

O cobv é uma cobrança única com vencimento. O lotecobv é em lote, diversas cobranças com vencimento uma para cada cliente diferente. Notar que o BACEN instruiu os PSPs pagadores a suportarem isso até o dia 15 de Março, e os recebedores a só ofertarem depois do dia 15 de Março.

mas "não seguir" mTLS seria não enviar o certificado. se é o EC que valida, qual a responsabilidade do PSP? qual o critério pra saber que o EC não tá validando?

Não é só o mTLS que o PSP precisa avaliar do EC, é toda a postura de segurança.

e a pergunta oposta: quem disse que o PSP deve mandar request pra URL do webhook no momento do PUT? isso não tá previsto. eu poderia configurar o webhook com o PUT sem a URL estar sequer alcancável

<@!780500321994539068> o manual de segurança diz que o callback deve ser enviado por canal mTLS. mas como o PSP pode garantir que o canal é mTLS? não existe isso. ele envia com certificado e o cliente verifica se ele quiser. não tem como a GN saber se o cliente tá validando.

O não testar não exime o PSP de validar o cumprimento do manual de segurança pelo EC.

não é bem assim. na verdade, a conexão mTLS não tem como ser validada dos dois lados. quem envia o request manda o certificado e o recebedor é responsável por validar, mas não tem como o emissor impedir que o outro lado "consuma" o request sem validar o certificado enviado. então a norma do BACEN, na prática, obriga o PSP a enviar o certificado e dar meios pro cliente verificar (e rejeitar o request se quiser). mas o EC pode simplesmente ignorar a verificação. o que o novo parâmetro faz é desligar a verificação que a GN faz (por iniciativa dela, não por obrigação) enviando um request sem certificado primeiro para testar se o EC valida. então se vc usa esse parâmetro, você poderá receber callbacks depois, que virão com o certificado, e recebe os dados normalmente mesmo que não valide o certificado (ou seja, sem "fechar mTLS").

Quando você realiza uma devolução o status pode ficar EM_PROCESSAMENTO, pois, necessita da comunicação com o segundo PSP e a transação pode ser aceita ou recusada nesse tempo de análise.

O NAO_REALIZADO é o status que ocorre quando uma tentativa de devolução é feita, porém, o PSP recusa a devolução.

não tem um com o retorno do txid com o psp da gerencianet ?

Você só pode emitir cobranças através do PSP onde esteja registrada a chave Pix utilizada. Se você está aqui imagino que seja para emitir via Gerencianet, então precisa ter conta na Gerencianet.

Mas esse tipo de customização precisa ser feita com cautela, e usada com parcimônia, já que em outro PSP isso não vai existir ou ser diferente.

Boa tarde <@!348725207076175872>! Você se refere ao campo solicitacaoPagador ? Em algus PSPs é ignorado esta informação enquanto que em outros ela aparece. Em qual PSP você está lendo o QRCode?

Boa tarde <@!783359762917752843>! As chaves Pix ficam salvas em um DICT que é consultado no momento do envio do Pix, se este CPF não estiver atrelado a nenhum PSP como chave, então a transação não ocorre. Ym exemplo de retorno ao consumir a rota v2/pix :