Histórico de mensagens em pix

Por gentileza so para a conta de pessoa fisica, o de cnpj ja tenho. Pode gerar tudo, os client e certificados dev e prod , por gentileza.

É preciso importar os 2 certificados também pois são distintos (produção e homologação)

Criei um novo post, configurei novamente e funcionou. Weird, mas enfim, 100% 🙂

Sim, foi no que pensei, mas esta certo. Por via das dúvidas vou partir do zero de novo.

Veja se vc não está apontando para o host de homologação (api-pix-h...) em vez da de produção (sem o h)

Vou verificar

@Deleted User essa falha normalmente é erro nas credenciais mesmo. Verifique as credenciais cliente_id e client_secret, a url e o certificado, por gentileza, pois o procedimento é esse mesmo

@Efí Estou obtendo esse erro no servidor de produção, já verifiquei o novo certificado e alterei o client_id e client_secret. Preciso realizar mais algum procedimento?

Boa tarde <@!710205440956563536>. Ja estou com o ticket. Então é pra gerar pras 2 contas daquele perfil, correto?

@Efí solicitei outros Client_ID e Client_Secret, bem como so dois certificados dev e prod ticket Nº 1619359.

Uma linha digitável de boleto é até mais vulnerável pois os dados do recebedor estão todas na string. No entanto, no caso do brcode não é impossível, mas além de adulterar o link do payload esse payload deve conter as informações do pagamento e estar assinado

Esta é a questão, quem usa chave gerada aleatoriamente, vai ter que conferir um por um com a chave do recebedor, quem não tiver paciencia pode conhecer Silas = Silascar.

Uma linha digitavel de boleto tb já tá sujeito a isso hoje. Cabe a quem tá pagando conferir os dados atentamente na tela de revisão e desconfiar se tiver algo errado

Pensando aqui, #reflexoes, a grande vulnerabilidade para o usuario comum ao efetuar um envio utilizando "copia e cola" é se esta url seja interceptada, modificada com outra chave de recebimento e validada novamente como um novo pix, retornando uma nova url "copia e cola" modificada o seu destino de envio. Ai não tem como impedir, tem como saber quem recebeu, ai são outros 300.

Só faltam ver a questão da expiração da validade após concluida a transação 🙂 do BRCode.

No Nubank, apesar do bug da primeira leitura do qrcode ele lê corretamente, exibe o txid na tela de revisão e ao confirmar o pagamento deve retransmitir o txid pra GN e a cobrança muda pro status CONCLUIDA, funciona certinho

O tamanho maximo dele é de 63 do ID62 Aditional Data Field Template, E fica entre 39 e 63 caracteres maximos. Se estes bancos estão ignorando isso...ai paciencia.

faz sentido

Pois é. Ou esses pagadores (banco inter e Sofisa) não estão retransmitindo porque validam o tamanho do txid e se estiver acima de 25 carácteres ignoram ou eles estão simplesmente comendo bola. O interessante seria fazer um teste em produção com um txid menor ou igual a 25 carácteres pra testar porém hj o txid do GN deve conter no mínimo 26, o que inviabiliza o teste

Tem o txid sim ao criar o PIX no rotorno {
"calendario": {
"criacao": "2020-11-22T21:49:51.946Z",
"expiracao": "93600"
},
"txid": "fc9a4366ff3d4964b5dbc6c91a8722e8",
"revisao": 0,
"loc": {
"id": "11",
"location": "https://qrcodes-pix-h.gerencianet.com.br/v2/362c897b2176435b8c02c1d3ef0b0fd8",
"tipoCob": "cob",
"criacao": "2020-11-22T21:49:52.009Z"
},
"location": "https://qrcodes-pix-h.gerencianet.com.br/v2/362c897b2176435b8c02c1d3ef0b0fd8",
"status": "ATIVA",
"devedor": {
"cpf": "12345678909",
"nome": "Seu Cuca"
},
"valor": {
"original": "1523.45"
},
"chave": "1605806648Q",
"solicitacaoPagador": "O Pagamento do Fiado."
}