Termos mais procurados:
Não precisa, a chave é associada a conta Gerencianet e não a aplicação. Você pode gerar uma nova chave pelo APP da Gerencianet ou então utilizar o novo endpoint que disponibilizamos, o POST /v2/gn/evp, ele vai gerar uma nova chave aleatória, mais detalhes aqui https://dev.gerencianet.com.br/docs#section-criar-chave-evp.
auth = base64.b64encode(
(f"{credentials['client_id']}:{credentials['client_secret']}"
).encode()).decode()
url = "https://api-pix-h.gerencianet.com.br/oauth/token" #Para ambiente de Desenvolvimento
payload="{\r\n \"grant_type\": \"client_credentials\"\r\n}"
headers = {
'Authorization': f"Basic {auth}",
'Content-Type': 'application/json'
}
response = requests.request("POST",
url,
headers=headers,
data=payload,
cert=certificado)
É a chave Pix associada à conta destino da cobrança. Você pode criar via app mobile ou via endpoint de criação de chave Pix. Essa chave vai ser colocada no QR-Code estático ou no payload do QR-Code dinâmico.
Sobre o 2, é mais no sentido de entender o que eu posso fazer com a API de vocês. Ela me permite adicionar qual recurso em relação ao PIX no meu app ou site?
Em relação a pergunta 2, você pode detalhar um pouco melhor? Seria desenvolver um app que esteja integrado à nossa API Pix?
Bom dia.1) Gostaria de saber se consigo utilizar a API da GerenciaNet com javascript e php. Na verdade, o melhor seria alguma integração direta com a plataforma low-code Outsystems. Mas se tiver em php e javascript, já é um bom começo. 2) Consigo fazer um pix de dentro do meu app para uma outra conta pix via API? Consigo gerar um QR CODE para permitir que façam o pix para a nossa conta? Obrigado!
Um exemplo de requisição em JS:
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.
Neste caso a GN está obrigando o pagador a escrever, pois só foi para a tela de pagamento após escrever qualquer coisa no app hoje.
#solicitação = No momento de pagar um pix no app da GN , ela pede o Solicitação ao Pagador, como obrigatório escrever algo para habilitar o pagamento, isso pode fazer o pagador desistir de pagar, é uma exigência do BACEN ter que escrever alguma coisa la ?
@Efí, o erro “A requisição na URL informada falhou com o erro: ERR_TLS_CERT_ALTNAME_INVALID” parece estar relacionado com o certificado da Amazon.
Ele ocorre para os dois cenários a seguir:
Webhook COM mTLS hospedado na Amazon, com certificado HTTPS emitido pela Amazon:
https://mtls.menur.app/vbeta1/establishments/mana/pix
Webhook SEM mTLS hospedado na Amazon, com certificado HTTPS emitido pela Amazon:
https://mtls.api.menur.app/vbeta1/establishments/mana/pix
Entretanto se acessar SEM mTLS com hospedagem no Heroku e certificado Let’s Encrypt o erro que dá é esperado:
https://api.menur.app/vbeta1/establishments/mana/pix
"A autenticação de TLS mútuo não está configurada na URL informada"
E agora? Vocês poderiam verificar o motivo? Obrigado!
Agora está certo sim: https://www.ssllabs.com/ssltest/analyze.html?d=mtls.menur.app
<@!620895261568401428> Você precisa gerar um certificado válido para
O meu testador preferido de SSL é este:
https://www.ssllabs.com/ssltest/analyze.html?d=mtls.menur.app&s=54.156.62.10&ignoreMismatch=on&latest
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? 🙏
Massa! Vou dar uma olhada no App Gateway ou API Gateway? Vou dar uma olhada. Achei que você era do BACEN. Você é da Gerencianet? Vi que tem algo na doc pedindo para postar aqui.
Mostrando que dá erro HTTP 500 caso o grant_type seja submetido via content-type: application/x-www-form-urlencoded ao invés de application/json. Por isso a configuração OAuth2 não consegue fazer o Fetch Tokens.
Pessoal, seria possível fazer com que o serviço https://api-pix.gerencianet.com.br/oauth/token aceitasse o content-type: application/x-www-form-urlencoded ? Desta forma evitaria o erro HTTP 500 ao enviar o body grant_type=client_credentials que é mais compatível com REST Clients como o Insomnia e até o próprio Postman na seção de autenticação OAuth2 usando o grant type "client credentials".
