Histórico de mensagens sobre dados

Mais uma razão para que os comprovantes não vazem agência e conta. Ou, pior: no Itaú não precisa nem enviar o Pix e esses dados já são expostos ao consultar a chave.

Então <@!305835973474910208> ... se o cliente permitir você utilizar os dados da conta dele, pode ser. Senão você pode criar uma conta para você realizar os testes. A abertura de conta é 100% gratuita

Boa tarde, existe a possibilidade de incluir um boleto via api, com os dados do pagador, incluindo o e-mail, mas não enviar para pagador? Quando incluo os dados do pagador como e-mail o sistema já envia um e-mail direto para o pagador.

Bom dia pessoal!
<@!375094642238029824> melhor maneira para verificar o pagamento de uma cobrança é mesmo utilizando o webhook. Com seu webhook cadastrado em sua chave, as cobranças Pix (Por enquanto, QrCode dinâmico) criadas com sua chave que estejam associados a um txid, serão notificados em sua URL.
Exemplo de notificação de um Pix pago:

Obrigado pela resposta rápida, Rubens!

Só de suprimir o teste do mTLS já me ajudou um bocado, espero que continue assim pois não temos a menor intenção de implementar esta medida de segurança que pouco nos afeta.

E quanto aos dados serem suprimidos. Poxa vida, que passo para trás, agora será bem fácil darem golpe com o PIX roubado de terceiros e a gente nem sequer saber 😦

De qualquer forma, eu não consegui encontrar os dados do pagador da cobrança do PIX. Fiz um pagamento com meu banco para teste e nao tem informação nenhuma do pagador. Isto está mesmo certo? Já temos integração com APIs de outros prestadores, e em todos é informado o nome completo, cpf, instituição pagadora, etc. Estou perdendo alguma coisa ou realmente o gerencianet não retorna estes dados do pagamento PIX recebido?

quais dados vocês me envia na URL que informei?

Armazenar dados de cartão de crédito necessita da certificação PCI-DSS (https://pt.pcisecuritystandards.org/index.php).

Boa tarde!
É a primeira vez que eu implemento um sistema de pagamentos e gostaria de uma sugestão: Como eu poderia/deveria armazenar os dados do cartão de um cliente para que ele não precise informar os dados do cartão sempre?

Eu poderia salvar os dados exceto CVV de forma encriptada? ou ao autenticar um cartão via gerencianet ela me retorna um token e eu posso salvar esse token e com ele recuperar os dados do cartão?

Oi boa tarde!
Estou com um problema também com o $gn.ready, só consigo executar uma vez. Se eu executar com os dados de um cartão errado a api de vocês retornam um erro normalmente, mas se eu tentar executar novamente com os dados certo o código não entra no $gn.ready.

Só volta a funcionar normalmente se eu recarregar a página, mas isso eu teria que preencher o form tudo de novo.

sendo que o $gn.ready só vai ser executado quando o cliente escrever os dados do cartão dele

O cliente não tem acesso a essas informações, o que ele vê é apenas a interface de inserir os dados do cartão, o script não aparece ao cliente. De qualquer forma o identificador não é uma informação sensível e sim as credenciais(client_id e client_secret)

Pessoal, outra questão aqui. Onde vejo o schema/payload desse "Dados do Pix efetuado."

eu preciso saber quais dados vocês me enviam como resposta para u URL que informo quando gera a transação

mas quais dados vocês me enviam como resposta?

Acho estranho a questão do processo, o valor pode ser facilmente "digerido" pelo Itaú. Se for real a questão do processo, é uma difícil tentativa.

Agora, qualquer dinheiro recebido que não é legitimamente da pessoa, a pessoa deverá devolver o dinheiro, há várias jurisprudências nesta linha. As informações fornecidas pelas instituições vão além de dados cadastrais e contribuem muito na localização dos reais beneficiários.

não é bem assim. na verdade, a conexão mTLS não tem como ser validada dos dois lados. quem envia o request manda o certificado e o recebedor é responsável por validar, mas não tem como o emissor impedir que o outro lado "consuma" o request sem validar o certificado enviado. então a norma do BACEN, na prática, obriga o PSP a enviar o certificado e dar meios pro cliente verificar (e rejeitar o request se quiser). mas o EC pode simplesmente ignorar a verificação. o que o novo parâmetro faz é desligar a verificação que a GN faz (por iniciativa dela, não por obrigação) enviando um request sem certificado primeiro para testar se o EC valida. então se vc usa esse parâmetro, você poderá receber callbacks depois, que virão com o certificado, e recebe os dados normalmente mesmo que não valide o certificado (ou seja, sem "fechar mTLS").

O cadastro das chaves de endereçamento deve ser feito pelo aplicativo.
Para cadastrar suas chaves Pix:
Acesse sua conta pelo app Gerencianet.
No menu lateral, toque em Pix para começar seu cadastro.
Leia as informações que aparecem na tela e clique em Registrar Chave.
Caso esse não seja mais o seu primeiro contato, toque em Minhas Chaves e, em seguida, no ícone (➕).
Selecione os dados que você vai cadastrar como Chave do Pix e toque em avançar – você deve escolher pelo menos 1 das 4 opções de chaves disponíveis (celular, e-mail, CPF e/ou chave aleatória).
Após cadastrar as chaves do Pix desejadas, clique em concluir.

no request que vc recebe já vem os dados do pagamento, não precisa enviar nova consulta à API (a menos que queira verificar alguma informação, mas aí deve ser feita com GET no /v2/pix/{e2eid} )

Uma otimização seria só revalidar os callbacks idle. Os de quem transação a cada alguns minutos logo terão dados de retorno gerados pelas próprias notificações.