Histórico de mensagens sobre integrador em pix

Não tem, mas vamos adicionar para que os integradores fiquem cientes. Obrigado pela sugestão.

Bom dia, pessoal! Como vão?
<@!689656729314656316> até o momento a rota POST /v2/gn/evp gera apenas chaves em produção, em vista de disponibilizar mais rápido as funcionalidades para os integradores. Na medida que formos caminhando com as soluções nos manteremos os ambientes similares.
No entanto, reportamos a vocês qualquer novidade.

Encontrei este tutorial aqui da AWS que ensina passo a passo a configuração com mTLS, outros integradores utilizarem ele, pode ser útil https://aws.amazon.com/pt/blogs/compute/introducing-mutual-tls-authentication-for-amazon-api-gateway/ . Vou buscar mais informações e retorno para você caso não consiga configurar.

Bom dia @everyone , informamos que foi realizado o deploy relativo a inclusão do /pix em todos os webhooks cadastrados como informado anteriormente aqui no canal e em outros meios de comunicação, como nos tickets que enviamos. Pedimos que os integradores que não fizeram o ajuste ainda que se atentem a esta mudança, pois, vai ocasionar falha(404) no recebimento das notificações.

Temos novidades, pessoal!
Sabe-se que muitos integradores desejam utilizar Qr Codes estáticos em cenários diversos, em especial envolvendo negócios de pequeno porte, mas que exigem um processo de conciliação dos recebimentos.

Para isto, publicamos uma atualização que irá notificar via Webhook os Pix pagos através de Qr Codes estáticos.
Saiba mais detalhes em nosso <#🖥changelog>

Lembrando o informativo enviado:

Informativo sobre à adequação do /pix no webhook

Foi estabelecido que ao realizar o cadastro do webhook base pelo integrador, ocorrerá a adição do parâmetro /pix no POST {$request.body#/webhookUrl} pela Gerencianet no momento do disparo das requisições.
Abaixo trazemos alguns exemplos de webhook's e como será a notificação após esta mudança:

Integrador cadastrou a url base https://gerencianet.com.br, ao acionar o webhook uma requisição do tipo POST será enviada para https://gerencianet.com.br/pix.

Integrador cadastrou a url base https://gerencianet.com.br/pix, ao acionar o webhook uma requisição do tipo POST será enviada para https://gerencianet.com.br/pix/pix.

Integrador cadastrou a url base https://gerencianet.com.br/?id=0000x22, ao acionar o webhook uma requisição do tipo POST será enviada para https://gerencianet.com.br/?id=0000x22/pix.

Seguindo então a nossa documentação o serviço será POST {$request.body#/webhookUrl}/pix.

Tal definição foi feita após analisar os feedbacks de integradores, questionamentos ao BACEN e discussões internas.
A data para deploy do novo padrão está alinhada para o dia 08/02/2021. Sendo esta arbitrada a fim de que todos os integradores da API-Pix que utilizam o serviço de webhook possam ajustar seus sistemas e aplicações, e evitar assim falhas ou mal funcionamento do serviço.

Uma sugestão é permitir o recebimento da notificação em ambos os modos: com e sem /pix. Dessa forma, quando virarmos a chave, não haverá problemas.

Quaisquer dúvidas referentes a esta transição, estamos a disposição em nossos canais de comunicação.

Boa tarde <@!400114559299616769>, como muito bem informado pelo Renato nós continuamos enviando o certificado, o que o x-skip-mtls-checking faz é dar a decisão ao integrador se ele vai ou não verificar o CA na requisição. Fizemos isso para auxiliar clientes que utilizam servidores compartilhados, mas a recomendação é sempre configurar o mTLS.

Boa tarde Lucas, como informado pelo Rubens foi o BACEN que definiu que fica por parte do integrador montar o brcode. No entanto a Gerencianet desenvolveu uma rota interna para montar e entregar o QRCode e o copia e cola. O endpoint GET v2/loc/:id/qrcode, onde você passa como parâmetro o id do location que você recebeu ao gerar uma cobrança anteriormente.

Vamos continuar enviando nosso CA nas requisições, o que fizemos foi deixar por parte do integrador validar ou não a informação.

Notar que a Gerencianet não diz que o mTLS não é necessário, e sim que o integrador pode ter outras formas de implementá-lo em camada de aplicação e aí garantir o mesmo nível de segurança. Então quem não estiver validando se o cliente é mesmo a Gerencianet, está em violação da documentação do Pix.

Boa tarde @everyone, sobre à adequação do /pix no webhook, ficou definido que será feito o cadastro do webhook base pelo integrador e a adição do parâmetro /pix no POST {$request.body#/webhookUrl} pela Gerencianet no momento do disparo das requisições.
Abaixo trazemos alguns exemplos de webhook e como será a notificação:

Integrador cadastrou a url base https://gerencianet.com.br/, ao acionar o webhook uma requisição do tipo POST será enviada para https://gerencianet.com.br/pix.
Integrador cadastrou a url base https://gerencianet.com.br/pix, ao acionar o webhook uma requisição do tipo POST será enviada para https://gerencianet.com.br/pix/pix.
Integrador cadastrou a url base https://gerencianet.com.br/?id=0000x22, ao acionar o webhook uma requisição do tipo POST será enviada para https://gerencianet.com.br/?id=0000x22/pix.

Seguindo então a nossa documentação o serviço será POST {$request.body#/webhookUrl}/pix.

Tal definição foi feita após analisar os feedbacks de integradores, questionamentos ao BACEN e discussões internas.
A data para deploy do novo padrão está alinhada para o dia 01/02/2021. Sendo esta arbitrada a fim de que todos os integradores da API-Pix que utilizam o serviço de webhook possam ajustar seus sistemas e aplicações, e evitar assim falhas ou mal funcionamento do serviço.

Uma sugestão é permitir o recebimento da notificação em ambos os modos: com e sem /pix. Dessa forma, quando virarmos a chave, não haverá problemas.

À medida que se aproximar da data de deploy seremos mais assíduos nas notificações. Quaisquer dúvidas estamos a disposição em nossos canais de comunicação. [ATUALIZADO]

Quando uma devolução é feita utilizando um id associado a outra devolução a mensagem retornada é a:

Não entendi esta:

Integrador cadastrou a url base https://gerencianet.com.br/?id=0000x22, ao acionar o webhook uma requisição do tipo POST será enviada para https://gerencianet.com.br/pix?id=0000x22

A possibilidade mais simples de contornar a concatenação do /pix que a documentação força é justamente colocar um ?x= ao fim da URL para ficar ?x=/pix.

então pergunto:

1. qual a razão para agregar o /pix "no meio" da URL que foi definida pelo integrador e não no fim?
2. isso vai contra a documentação atual que diz que o /pix irá (sempre) no fim da URL - e se for pra mudar o conceito, seria melhor que esse /pix fosse retirado.

e sugiro aos integradores que estão lendo agora: não usem query params na URL do webhook conforme esse exemplo (prefiram path params)

Os dois usando o mesmo integrador

Essa mesma falha aconteceu com um outro integrador e é relativo ao sistema não conseguir acessar o certificado, no caso foi no windows também

Essa mesma falha apareceu para um integrador ontem e o fato de ter um no key found está relacionado ao diretório

Boa tarde Paula! O nosso callback foi alterado para o padrão do BACEN, nas futuras modificações avisaremos com antecedência para que os integradores possam ajustar o sistema ao novo padrão. Exemplo de callback de Pix recebido atualmente:

Boa tarde <@!664563985885954079>, não tem problemas de autenticação ocorrendo, o que percebemos é que alguns integradores tentavam utilizar o cerificado de produção em rotas de homologação ou vice-versa. Me informe no privado o número da sua conta e detalhes do seu certificado para que eu identifique se é a mesma causa.

Como o Evanil citou, é algo que estamos abertos a discutir e implementar uma vez que contribua positivamente para os integradores, mas de todo modo teria um tempo para ser implementado

Já foi orientado e as credenciais não estão sendo enviados pela equipe, no entanto, a documentação estava desatualizada. Alterei para que o integrador informe o nome da aplicação e o ambiente para que possamos gerar o certificado.