Histórico de mensagens em pix

Sim. Porém sai porque ainda não está em produção

Juno já está com API Pix ? Eles tinham tirado por não alinhamento com o Banco Central...

Mas o secret seria tunelado junto no header. Não vejo forma disso ocorrer. Mas enfim... estou nos finalmente da integração e me deparei com essa limitação. O Heroku faz o hand shake SSL utilizando o Amazon Elastic Load Balancers (ELB). Imagino que essa solução venha impactar muita plataforma que esteja hospedada em ambientes PaaS. Seria muito legal ter uma solução para este cenário. Serviria para mim também.

Cara. Fiz o mesmo processo pela Juno e perdi quase uma semana. Aqui menos de 12 hrs..

Sim. Já fiz obrigado..

Já vai pedindo via ticket o certificado de produção para agilizar...

A vantagem de par chave pública/chave privada, como se faz nos certs, é ter uma prova de autoria que só pode ser gerada por uma das partes. Um shared secret pode sofrer replay attack. O certificado é apenas uma forma padronizada e usual de usar criptografia assimétrica, que é a raiz desse processo.

Sim. Isto mesmo. Hoje eu testo em produção até recebimento por cartão de crédito. Isto para o meu caso é comum. Amanhã vou verificar com o pessoal como obter uma chave para colocar o PIX em produção até na quarta-feira.

Sim. Mas o client cert não garante, na prática, neste cenário, nenhuma segurança a mais do que usar um secret, por exemplo. Todos os dados são tunelados com SSL da mesma forma. Só comentei mesmo pelo fato do tabu que existe quando se fala de certificado. Neste caso, ao meu ver, acaba sendo apenas burocracia.

Esse -h na URL mostra que é de homologação. Uma dúvida comum é que não há como quitar a cobrança de homologação para ver a continuidade do processo... então para isso vai precisar testar em produção com valores baixos.

Não é apenas não-repúdio, como há informações financeiras em trânsito, há também questões de sigilo bancário. O próprio BACEN parece amigável a que numa versão 3 o webhook contenha menos dados (por exemplo apenas a chave Pix e o txid) e com isso possa ter requisitos menores de segurança, pois a informação bancária só seria transmitida no GET de /pix ou da cobrança que o causou. Mas para a versão 2.x, ficou assim e não vai mudar.

Olha o bicho ai...

Depois de alguns perrengues consegui gerar o primeiro qrcode pix. Agora é fazer alguns ajustes. Obrigado pessoal o sdk do php é muito bom.

Muitas vezes "apelam" pelo uso de certificados se valendo equivocadamente de proteções jurídicas referentes ao não repúdio. Mas que não se aplica em casos como este e em muitos outros que usam certificado sem tanta necessidade.

Na verdade a solução seria a mesma. Tanto é que, atualmente, é preciso que seja feita uma requisição antes sem o certificado onde o erro é esperado. Para só então repetir a requisição com os dados corretos. O mesmo poderia ser feito com o secret. A primeira sem o secret e esperar o erro. Depois repetir. Só seria MUITO mais simples de configurar, de implementar, de manter, além de ser mais compatível por ser menos dependente de configuração de ambiente.

Isso é realmente bom. Mas acho que a preocupação do BACEN foi de justamente o pessoal não utilizar os meios de segurança. Impondo o mTLS obrigatoriamente eles cumpririam os requisitos de segurança.

Esse aí por exemplo é do Github.

Uma forma também comum no mercado é, quando registrar um webhook, definir também um secret. E fica a cargo do webhook checar o secret. Isso garantiria também que as requisições vem de uma origem confiável e não precisaria fazer grandes mudanças na arquitetura. Uma solução de mercado que é viável em webhook em PaaS.

Oi <@!440035527127990273>, se puder compartilhar a solução 🙏

A única informação que garantidamente voltaria é o txid. Você pode pedir para o pagador colocar informações no infoPagador, mas o pagador põe se quiser. E se o txid que é muito mais importante tem PSP que não manda, infoPagador é pior.