Histórico de mensagens sobre url em pix

Hoje é segunda , fiz pagamento de pix com sucesso e não recebí nada na url cadastrada via webhook, por isso estou na duvida.

#duvida. Mesmo com o processamento de recebimento de pix efetuado com sucesso nas segundas-feiras temos que esperar para a terça-feira para receber a notificação do webhook na nossa url ?

exato, tentei mais de 10 vezes pagar um pix lá, e agora que lembrei que hoje é segunda e a GN não envia webhook hoje de recebimento para a url 😦

#duvida Em qual local posso ver os envios do webhook para a url cadastrada, não consigo achar em API logado online na conta. 😦

@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!

De qualquer modo, é importante fazer o url encoding.

dai me instruiram pra consultar em /pix... só mudei o path na url

Fiz a requisição fazendo o parse de URL encoding e funcionou. https://api-pix.gerencianet.com.br/v2/pix?inicio=2021-01-04T22%3A21%3A49Z&fim=2021-02-15T15%3A29%3A47Z

url: https://api-pix.gerencianet.com.br/v2/pix?inicio=2021-01-04T22:21:49Z&fim=2021-02-15T15:29:47Z

Então preciso reconfigurar a minha url para que eu consiga receber o callback?

Você está tratando o /pix no final da URL?

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? 🙏

Isso jéssica, estou consultando na url /cob, passando os parâmetros inicio e fim.

Lembre-se de adicionar o "/pix" ao final da URL.

Esse -h na URL mostra que é de homologação. Uma dúvida comum é que não há como quitar a cobrança de homologação para ver a continuidade do processo... então para isso vai precisar testar em produção com valores baixos.

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.

Exemplo da configuração do OAuth2 no Insomnia, que é igual ao Postman e outros clients compatíveis. Com isso deixa de ser necessário chamar o serviço de geração de token antes, e sempre que expirar. O client REST mesmo toma conta desse gerenciamento. Além do que, o Insomnia não tem a opção de rodar script que manipula as variáveis de ambiente como o Postman, que faz com que seja possível dar aquele "jeitinho" (no bom sentido) para esse tipo cenário. Vejo que o ideal seria usar o próprio padrão. É relativamente simples de resolver, aceitando não só o JSON como também o Form como Content-Type do serviço de geração do Access Token URL.

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".

Outra duvida.. no meu teste gerou no location a url qrcodes-pix-h.gerencianet.com.br/v2/1ddbab2c4dcc4d10a3020fb42cb4955b

mas eu posso exigir o mTLS em /webhook e não em /webhook/pix

faz sentido que eu faça isso? não. assim como também não faz sentido testar a URL que não é efetiva.