Histórico de mensagens

Entendi..

É o mesmo, mas nós temos a chave privada que assina o certificado

Cluster K8S só para lidar com webhooks

Agora vai

Me pareceu que no caso da GN é o mesmo sim. Mas lembrando que o certificado é um par chave pública/chave privada, então para abrir uma conexão mTLS com ele precisa da chave privada da GN, não apenas da chave pública que está presente no certificado.

Eu entendi, mas o de vocês não é o mesmo correto? - Obviamente que não, mas apenas para garantir..

Estamos analisandoa possibilidade do integrador gerar um crt assinado com uma chave privada que só ele tem acesso, aumentando ainda mais a segurança

O certificado é o mesmo disponibilizado em nossa documentação. Para acontecer o Hand-Shake, o seu sistema deve apresentar o nosso certificado e vamos entregar o nosso também

Alguém tem um e-commerce já com o Pix funcionando para eu ver como ficou o processo?

O certificado utilizado para fazer o callback é diferente do certificado para receber?

Bem pontuado pelo Rubens! Com o mTLS que é inclusive exigido pelo Banco Central as informações transitadas são seguras

Como o callback tem mTLS, dá para confiar na integridade e autenticidade. Agora, se perder o callback, aí vale fazer GET .

Eles vão estar com o status Concluído

Se você for fazer via API pode usar o Consultar cobrança ou Consultar cobranças recebidos

Minha ideia é nunca confiar no callback, sempre que receber vou consultar na api...

Ou por ter recebido um objeto pix no webhook com esse txid

Com GET no /pix pelo txid

vou perguntar de uma forma diferente, existe como verificar se um txid está pago?

E quando vou saber se está pago ou não?

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.