Histórico de mensagens sobre integrador

Boa tarde <@!799254503651541032>, o POST é feito enviando um token como este

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.

qual é a recomendação para o integrador caso o cliente já possua diversas assinaturas ativas? seria o cancelamento manual dessas e recriação via API?

Não jogar essa responsabilidade para o integrador.

Pessoal, acabei de passar por uma situação aqui com a API de envio de PIX.

Aqui na Xerpa temos um produto que oferece antecipação salarial. Os colaboradores fazem "saques" do salário a qualquer dia/hora.

Fizemos um lançamento interno aqui e API falhou bastante. Motivo: múltiplos saques simultaneamente.

Segundo o <@!671762828046106646> a API de envio de PIX só pode receber uma requisição por vez.

1. Gostaria de confirmar esse entendimento. É uma requisição por vez? Isso é limitante demais!
2. Podemos discutir uma forma da serialização ser feita por parte da GN e não do integrador?

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>

Mas há uma questão conceitual que atrapalha que é o modelo orientado a integração pelo próprio correntista, sem previsão de integrador... apesar de terem pensado assim por simplificação, algo na linha MVP, acaba fazendo falta.

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.

No caso de implementar no ato do callback, eu tô pensando mesmo é em deixar o integrador desativar de vez, se assim permitir a spec.

Integrador precisa validar por exemplo se o webhook é de test ou transacional para enviar o x-mtls-check da forma correta.

e o integrador tb pode "só enviar um header e pronto" na hora que recebe o callback, da mesma forma.. qual a dificuldade?

Eu acho que isso demanda demais configurações para o script, algo um pouco desnecessário. O modelo da GN é bem mais fácil o qual o integrador só envia no header e pronto.

isso dá mais flexibilidade pra um integrador que recebe os webhooks de ligar/desligar o mTLS bypass sem interferência no script que tá fazendo o envio do PUT

hoje:
- GN envia "callback" simulado sem certificado (se for aceito pelo integrador, é uma falha; dá "break" aqui)
- GN envia "callback" simulado com certificado (que deve retornar 200)

poderia ficar assim:
- GN envia "callback" simuilado sem certificado:
--> se receber de volta 200 + um header x-mtls-bypass: true, tá ok e dá break;
--> se receber de volta 200 sem o header, é falha e dá break;
--> se receber de volta 4xx, segue adiante
- GN envia "callback" simulado com certificado (que deve retornar 200)

Como assim <@!522899003663450113> ? A validação durante o cadastro continua. Opcionalmente o integrador fará um "bypass" desse recurso, se achar necessário. De resto, continua tudo como está.

Enfim, tornar a validação opcional não resolve 100% do problema, mas abre caminhos para que o integrador consiga resolver.