Histórico de mensagens sobre chave pix

Bom dia, pessoal. Temos novidades!
Foram publicados os novos endpoints para administração de chaves aleatórias do Pix.
Confira os detalhes em nosso <#🖥changelog>. 😉

não, tem um endpoint que retorna o qrcode e a chave pix

A chave Pix é o apelido da conta para o arranjo Pix. Com ela as pessoas não precisam colocar número da instituição/tipo de conta/agência/conta. As possibilidades são e-mail, CPF, CNPJ e chave aleatória, mas eu sugiro para cobranças de QR-Code dinâmico criar uma chave aleatória. A criação de chave só pode ser feita no app mobile da Gerencianet, atualmente.

$request = [
'calendario' => [
'expiracao' => 3600
],
'devedor' => [
'cpf' => '12345678909',
'nome' => 'Fulano de Tal'
],
'valor' => [
'original' => '10.00'
],
'chave' => PIX_KEY,
'solicitacaoPagador' => 'Pagamento do pedido 123'
];
eu tenho essa requisicao, queria saber qual seria essa 'chave' => PIX_KEY.

Boa tarde gente! Uma dúvida que tenho: No ambiente de produção preciso usar uma chave Pix já cadastrada?

Oi Mateus. Abrir um chamado número 186413O solicitando a chave de produção que será utilizada no endpoint para criação do PIX. É possível resolver isto por aqui. Obrigado.

São diferentes os retornos dependendo do endpoint consumido, se você se refere a criação da cobrança o retorno é:

API de Cobrança. Daria para conciliar recebimentos, não pagamentos. No caso de envio de Pix se você fizer por banco/conta/CPF já vai saber para quem foi, mas por Chave Pix não. E imagino que seja esse o problema.

Olá, @Efí

Ainda na labuta do Webhook em ambiente PaaS. Fiz os seguintes passos e creio estar quase lá:

- Criei uma conta na Amazon para o projeto
- Cadastrei o cartão de crédito
- Provisionei o Amazon API Gateway
- Configurei um custom domain nele
- Configurei o domínio no meu Registrar
- Habilitei o custom domain no API Gateway
- Criei certificado e habilitei o HTTPS
- Baixei o cert webhook da Gerencianet
- Criei uma Trust Store PKCS12
- Coloquei a cadeia da GN lá
- Converti a TS para o formato PEM
- Provisionei um armazenamento Amazon S3
- Subi a TS.pem
- Finalizei a configuração do custom domain
- Ativei o mTLS neste domínio
- Criei uma rota de API para o meu server
- Associei a rota ao custom domain com mTLS

Fui configurando e testando a cada passo. Quase tudo funcionando. A única coisa que não consigo é fazer uma requisição client para testar o mTLS já que não tenho o cert client do webhook.

Então…

- Invoquei o serviço PUT /webhook/{chave} passando no body a url e recebi o seguinte body com o status 400:

{
"nome": "webhook_invalido",
"mensagem": "A requisição na URL informada falhou com o erro: ERR_TLS_CERT_ALTNAME_INVALID"
}

Supus ser algum erro no pem que usei para configurar o mTLS. E já experimentei o seguinte:

- Usei exatamente o CRT que baixei das docs da GN
- Fiz a conversão como citei acima (criando a TS)

Se vocês puderem fazer uma requisição mTLS com o certificado client correto para testar, a UTR é esta:

POST https://mtls.menur.app/vbeta1/establishments/mana/pix

O serviço está retornando 204 fixo para qualquer body json (não obrigatório).

Alguma luz? 🙏

Bom dia, pessoal! Tudo bem? Estou com dificuldades para receber webhook quando realizo pagamento de uma cobrança Pix imediata.
Eu tenho uma chave aleatória Pix cadastrada na GN e utilizei a mesma no cadastro do webhook, chamando a rota PUT /v2/webhook/:chave. Acredito que o cadastro foi bem sucedido, já que a GN fez uma chamada POST no endereço que eu informei.
Criei uma cobrança imediata com essa mesma chave Pix e realizei o pagamento. Verifiquei que o valor da cobrança já foi creditado na conta da GN, mas o webhook não foi disparado. Preciso de ajuda, por favor

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.

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.

Não posso perder a venda de maneira alguma. Vou ter que conciliar de alguma forma. Como faço receber o E2EID do pagador? No SDK pode ser informado uma chave. Será que posso utilizar para identificar o meu PIX?

URL url = new URL ("https://api-pix.gerencianet.com.br/v2/webhook/" + CHAVE_PIX);
HttpsURLConnection conn = (HttpsURLConnection)url.openConnection();
conn.setDoOutput(true);
conn.setRequestMethod("PUT");
conn.setRequestProperty("Content-Type", "application/json");
conn.setRequestProperty("Authorization", "Bearer =" + authToken);
conn.setRequestProperty("x-skip-mtls-checking", "true");
conn.setSSLSocketFactory(sslsocketfactory);

Não, é a Chave Pix da conta que receberá os recursos. O mais usual é criar uma chave aleatória para os recebimentos, mas pode ser qualquer dos tipos de chave Pix existentes.

Vou exemplificar aqui, um Pix recebido:

Este vídeo dá uma boa idéia:
https://www.youtube.com/watch?v=6Es3i2eH5K4

Mas o mTLS normalmente é implementando no web-server, no PHP só ficam lógicas como checagem de chave Pix.

A Gerencianet tem essa solução sim, a API Pix. Notar porém que cada cliente seu precisaria abrir uma conta na Gerencianet, pedir os dados de acesso (client-id, client-secret e certificado), gerar uma chave Pix e aí te passar os parâmetros para vocês rodarem essas cobranças dos clientes de vocês para os clientes finais deles.
https://dev.gerencianet.com.br/docs/api-pix tem a documentação de integração, e o canal <#❖pix> tem pessoas tanto da Gerencianet quanto usuários da API que podem ajudar.

e já criei uma chave pix no aplicativo da gerencianet

Consegue sim. Eu mesmo criei uma chave Pix lá, uma aleatória.