Histórico de mensagens em pix

entendi...

Questão de segurança, já vi casos de um estelionarario trocar o POS da loja, a segurança de manter o POS original é do estabelecimento.

Mais isso é coisa para quem vai ter o CPF ou CNPJ dele cadastrado como recebedor do dinheiro, ai são outros 300. Isso não é a regra é a excessão. A regra é o povo usar sem hack.

Nunca deixo chave em banco de dados ou codigos, para dificultar.

É por isso que a chave está dentro de um arquivo criptografado em uma pasta com permissão 0400 em outro servidor do sistema.

A automação comercial deve fazer segurança antes de enviar a criar cobrança, pega o clientid criptografa, assina, enfim.

@Deleted User resumindo, quem tiver acesso ao banco de dados ou arquivo config vai receber a grana, simples assim, é só mudar a chave.

<@!710205440956563536> supondo que o ecommerce tenha uma falha de segurança.. a chave sendo alterada no database, por exemplo, qualquer createCob vai com essa nova chave em vez da anterior anterior.. eu entendi o argumetno de <@!440035527127990273> assim

Na api tem as configurações do retorno por Webhook. A GN manda para a sua url cadastrada via api o retorno.

Entendi esta parte 🙂 O que não entendo é como o cara vai criar uma nova url de payload com a chave dele sem ser pela GN, ele teria que ter a sua propria url de payload, correto, sei que o comprador não tem a minima ideia disso, ele vai ficar vulneravel mesmo.

como eu faço para dar baixa nela agora?

e gerei uma cobrança no ambiente de teste

boa tarde, estou começando a integração agora

uma chave alterada num módulo de integração de um ecommerce vai gerar novos pedidos relativos a essa nova chave injetada. com novos locations (dessa nova chave). e novos qr codes com esses novos locations.. entendeu?

mas o CRC é um cálculo feito em cima do QR já pronto. vc tá olhando pro âmbito superficial da coisa. a chave sendo substituída, tudo vai refletir a alteração (as cobranças serão vinculadas a essa nova chave, e os payloads que estão no QR surtirão o efeito).

<@!440035527127990273> como ele vai modificar o retorno da url do payload se é gerado pela GN ?

Sim mais ai o crc16 será diferente.

sim, mas a chave sendo alterada no ecommerce, os (novos) payload também vão refletir a alteração. e é justamente por isso que estamos perguntando se o certificado limita as chaves que podem usadas pra gerar as cobranças

eu entro na loja camisetas123 e ao pagar, é comum que o nome do recebedor seja de uma empresa com outro nome ou até uma PF. como pagador, eu nunca vou imaginar que a loja pode ter sido hackeada e aquele nome ali não ser o do dono da loja.

Mais tem um detalhe, a chave está dentro do payload, portanto vai ser gerada sempre pela GN.