Histórico de mensagens sobre integrador

Desabilitar o check mas ainda exigir mTLS nas efetivas notificações ajuda em algo o integrador com problemas em ambientes compartilhados ?

basicamente.. o Itaú tá usando QR estático para um cenário onde deveria estar usando dinâmico. apenas se pouparam de ter que oferecer a leitura de qr codes via payload. deixaram todos os dados da cobrança a cargo do integrador, guardando somente a associação txid <-> valor, e rejeitando o que não coincidir

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

Pessoal, gostaria de opiniões e sugestões em cima desse desenho de endpoint:

PUT /config

Objetivo: permitir que o integrador controle alguns comportamentos. Por hora: receber ou não webhooks, receber ou não a tarifa cobrada como atributo na notificação do webhook, setar uma regex que será considerada na validação do txid.

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.

A respeito do discutido em https://discord.com/channels/775322853884821504/775328670784159744/796748024566120519:

A GN poderia oferecer na parte de API > Aplicações, uma opção para compartillhar os direitos de acesso à essa aplicação com um integrador parceiro por dentro da plataforma da GN, que poderia ver o client_id e client_secret e solicitar certificados.

Assim não dependeria do cliente fazer o processo de obtenção de credenciais, solicitar certificado, receber senha por SMS (que tem período de validade relativamente curto - 4 horas) e depois encaminhar tudo isso pro integrador por fora do sistema.

então vazios e estáticos vão para o teste de regex, e aí o integrador decide o que fazer

a ideia é testar se o regexp do integrador admite txid "vazio"

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

Não deveria ter um segundo condicionante antes de jogar para a regex do integrador, que verifique se o txid tem 1-25 caracteres? Pois se passar txid com 26-35 (que deveria ser relativo a uma cobrança) para o regex do integrador testar (sem haver uma cobrança), significa que o payload foi manipulado/mal-interpretado/etc...

Pessoal, o que acham dessa proposta? A ideia é dar mais liberdade ao integrador na decisão de aprovar ou não um Pix.

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.

A discussão no momento é permitir ao integrador bloquear Pix sem txid. Mas eu vou levantar essa questão também para a equipe, pois, já não seria com a API e sim com a equipe financeira.

Está em discussão, antes de implementarmos a mudança vamos avisar com antecedência para que os integradores possam se adequar ao /pix. Inclusive hoje eu questionei o andamento e uma discussão foi fomentada . Já trago mais detalhes aqui quando alinharem comigo.