Histórico de mensagens sobre webhook pix em pix

Lembrando que apesar do teste ser em exemplo.com.br/webhook, o que a GN vai chamar depois é exemplo.com.br/webhook/pix

certificado https://pix.gerencianet.com.br/webhooks/chain-pix-prod.crt

Estou tentando fazer o hand-shake em minha url webhook mas acontece esses erros. A chave crt é a fornecida pela GN e a url "https://api.suasorte.com.br/webhook/pix" está configurada pela AWS API Gateway com mTLS configurado com a .crt que a GN também forneceu. O que ainda preciso fazer para que funcione isso? Eu não sei mais o que fazer... 😔

Bom dia <@!812297338605273098>, respondendo ao questionamento que você fez no 2, sim é possível fazer o envio de Pix de sua conta Gerencianet para uma outra chave/conta via API. Para isto temos o endpoint POST /v2/pix (https://dev.gerencianet.com.br/docs#section-requisitar-envio-de-pix-) que permite o envio para uma outra conta via chave ou dados bancários.
Além disso via API você pode adicionar diversos recursos em seu site como cobranças estáticas e dinâmicas e fazer o controle via endpoints da API. Outro recurso interessante é o webhook que automatiza o seu sistema com os Pix recebidos, sem a necessidade de ter que construir uma rotina que fica realizando consultas na API. Você encontra tudo isso e mais na documentação e caso tenha dúvidas pode mandar aqui canal que te auxiliamos.

Essa é a questão. "Estar devidamente com o certificado inserido" que até agora não entendi. Se eu simplesmente utilizo o "https://pix.gerencianet.com.br/webhooks/chain-pix-prod.crt" e gero um .pem dele ou se preciso associar ao meu certificado .p12 de produção que recebi via ticket.

<@!671762828046106646> uma dúvida sobre como saber que um pix está pago. No caso de estar pago no webhook do pix o campo devolucoes estará preenchido com o status "NAO_REALIZADO" e com isso inferimos que o pix está confirmado? Ou há alguma outra maneira de garantir o sucesso do pagamento?

Oi pessoal! Estamos integrando a API Pix e estamos com uma dúvida sobre a consulta do status do pix. Os webhooks nos informam os status dos PIX enviados ou apenas dos PIX recebidos?

Seu webhook já está adaptado para atender com /pix à mais em relação à URL configurada ?

cadastrou normal aqui assim

Seria basicamente você cadastrar https://url.com.br/webhook/pix/webhook.php/?ignorar=

Quinta feira, dia 11 fizemos o deploy dessa alteração. "Concatenação do /pix nas URLs dos Webhooks: Foi realizado o deploy relativo à inclusão do /pix em todos os webhooks cadastrados."

Então nos enviamos para https://url.com.br/webhook/pix/webhook.php/pix

Então a GN vai chamar https://url.com.br/webhook/pix/webhook.php/pix

a url aqui cadastrada esta https://url.com.br/webhook/pix/webhook.php consultei via postman

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

Basicamente se você cadastrar:

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

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.

O mTLS faz sentindo. Ainda mais quando se tem volume de transações, se a sua comunicação com o PSP é segura, não tanta há necessidade de checagem do evento (apesar de ser um item de segurança a mais). A questão toda é que um volume alto de transações iria gerar números altos de Webhook + números altos de checagem de Pix recebido, isso poderia bater no ratelimit do PSP.