Histórico de mensagens sobre PSP em pix

Então está correto o funcionamento. Em relação ao status, hoje são esses:"ATIVA","CONCLUIDA","REMOVIDA_PELO_USUARIO_RECEBEDOR","REMOVIDA_PELO_PSP". Que seguem a norma do Banco Central.

E como isso poderia ser controlado pelo PSP recebedor é com Expires, Cache-Control e Etag:
https://restfulapi.net/caching/

Um alerta: PSP pagador (Santander no caso) deixando o cliente alterar o valor pago em QR-Code dinâmico. Algo para a GN e depois PSPs recebedores checarem e rejeitarem o Pix.
https://github.com/bacen/pix-api/issues/219#issuecomment-737253308

E acho que é assim mesmo que tem que ser... a rota base ser o que muda potencialmente entre PSPs.

Esse do Inter já é de conhecimento do BACEN, pelo que entendi de https://github.com/bacen/pix-api/issues/209 . E nesse só consigo imaginar problema no Inter e Sofisa mesmo. Os demais problemas de interoperabilidade ainda precisam ser determinados se são na GN ou nos PSPs pagadores. Princípio 1 de diagnóstico é não assumir nada.

Eu já vi alguns PSPs mostrando o E2EID após a confirmação do pagamento, e outros que não. Gostei mais dos que mostraram.

Vulnerabilidade não, mas parece excesso de informação. Eu gosto de ter essa informação no PSP pagador, para poder passar ao estabelecimento em caso de problemas.

Fica atento também as mensagens fixadas, em alguns PSP há alguns problemas com o PIX.

Validação pelos PSPs pagador e/ou recebedor e/ou pelo BACEN, não. Mas você pode estabelecer essa regra e implementá-la.

A GN suporta todos os tipos de chave, assim como todo PSP.

#agradecimento , a equipe GN está de parabéns 🙂 " Fizemos Progresso". Consegui a liberação da conta para gerar cobrança em produção agora 🙂 O Suporte e atendimento de todos estão em alto nível. Já me mandaram 5 convites para outros PSP... "Daqui eu não saiu...daqui ninguém me tira..." Muito feliz e satisfeito com todos vocês da equipe GN 🙂 . Cartão solicitado já 🙂

Integração com o PIX via PSP GerenciaNet 100% concluída :)

Cobrança ✅
WebHook ✅
Devolução ✅

Só pra tirar uma dúvida, quem retorna o E2EID não é o PSP?

realmente. no consumo da API precisa ser emitido pelo PSP ou por AC externa. mas no webhook, não tem requisito (item 9 dessa mesma seção).

Exatamente Rubens! Muito bem colocado, é uma norma direta do Banco Central a ser seguida por todos PSPs

"Os certificados digitais dos clientes da API poderão ser emitidos pelo próprio PSP ou
por ACs externas, conforme definido por cada PSP. Não deverão ser aceitos
certificados auto-assinados pelo cliente."

Por ser uma determinação do BACEN todos os PSPs tem que cumprir esse padrão

ainda é possível usar um endereço de callback "externo" ao ambiente que lança as cobranças, mas sendo mTLS é mais seguro do que fazer o PSP enviar requests para qualquer destino desconhecido. o mTLS poderia não se justificar nos casos em que a iniciação é do PSP, mas na iniciação externa fica mais garantido que é intencional o uso de determinada URL para callback

estava refletindo e entendi porque os locations são abertos. para permitir a existência das soluções de "iniciação pix" por parte de empresas que não são instituição de pagamento ou instituição financeira. e aí até faz algum sentido o callback ser obrigatoriamente por um canal mTLS. dá mais controle ao processo, impedindo que eles sejam direcionados a destinos "selvagens" que não foram pre-acordados com o PSP recebedor quando a iniciação também não for via cobranças armazenadas no próprio PSP

o que eu achei errado foi justamente o location estar desprotegido de mTLS (deveria haver um ponto central de autoridade para obtenção dos dados de uma cobrança quando o QR é lido, para que apenas os PSPs pudessem obter esses dados, não qualquer pessoa com acesso ao QR, assim poderia implantar limitação de consumo, por exemplo) e o webhook estar protegido (esse, não deveria ter essa exigência de mTLS, já que é apenas meramente informativo, e quem define a URL de callback já fez uso das credenciais e do canal mTLS pra isso)