Termos mais procurados:
Você pode configurar uma URL de notificação, para receber em seu servidor a cada alteração de status, ou pode também buscar os detalhes da cobrança por meio deste endpoint: https://dev.efipay.com.br/docs/api-cobrancas/boleto#retornar-informa%C3%A7%C3%B5es-de-transa%C3%A7%C3%A3o-existente
No caso da API Cobranças você deve usar uma das seguintes URLs:
Produção: https://cobrancas.api.efipay.com.br
Homologação: https://cobrancas-h.api.efipay.com.br
Documentação: https://dev.efipay.com.br/docs/api-cobrancas/credenciais#rota-base
@Consultoria Técnica no canal <#💻devs> o @rubenskuhl forneceu uma URL citando os endereços IP's utilizados pela Efí (https://sejaefi.com.br/central-de-ajuda/api/quais-enderecos-de-ip-gerencianet-utiliza#conteudo).
Não sei se essa lista é atualizada ou não, mas poderiam disponibilizar igual ao cloudflare. Assim abriria possibilidade para automatizar a liberação dos IP's de vocês por scripts.
Exemplo:
- https://www.cloudflare.com/ips-v4/
- https://www.cloudflare.com/ips-v6/
Sugestões que me lembre até agora:
- Utilizar % bem parecido com o LIKE do MySQL;
- Utilizar iniciaCom e terminaCom;
- Utilizar o regex bloqueando o uso de "()" (faria com que não demorasse tanto);
- Enviar uma requisição para uma URL para homologar um txid, ex: {webhookUrl}/txidmatch (Essa necessitaria de uma homologação parecida com BACEN x PSP);
Pensando na implementação lógica, o fluxo seria mais ou menos esse:
-> se o txid é dinâmico {26,35} a GN valida com base na chave + txid se existe cobrança (talvez isso até já esteja implementado hoje).
-> elseif, txid é nulo, GN consulta a configuração da conta do EC recebedor (ou da chave) se deve acatar Pix com txid nulo.
se a GN tiver como diferenciar quando o Pix foi enviado via "manual" (informando dados bancários) ou com uso da chave DICT, o ideal seria a configuração de aceitar/não os recebimentos com txid nulo ser por chave + uma configuração extra para bloquear todos os recebimentos manuais (que nunca tem txid associado).
se não tiver como diferenciar, a configuração poderia ser global (por conta transacional), com opção de sobrescrever a escolha para chaves individuais (assim poderia bloquear recebimentos com txid nulo para toda a conta [que seria o comportamento padrão] e autorizar o txid nulo em uma chave particular).
e, futuramente:
-> else (txid é estático), valida conforme as regras de aceite do EC (por regex match ou enviando o request de validação para webhookURL/txidmatch, como sugeri acima).
e esse "futuramente" eu não consigo nem ver uma demanda relevante. o importante são as outras funções.
tive uma ideia aqui. e se a GN mandar um request para webhookURL/txidmatch passando o txid recebido, com um timeout de uns 3 segundos, e o EC responde se a GN deve ou não aceitar o recebimento?
talvez o problema seja o BC encasquetar com o prazo de conclusão do recebimento (a média de tempo iria subir)
Outra coisa... o serviço de geração de token não está aceitando o conteúdo em form-urlencoded. Apenas em JSON. E o padrão form-urlencoded é o utilizado pelos clients visuais e SDKs do OAuth2 para automatizar o gerenciamento do ciclo de vida do Token. Seria importante que o serviço aceitasse ambas.
e qual o risco que existe para o PSP em mandar um request pra uma URL sem mTLS que não existe com o mTLS? é o EC que tem que confiar ou não. tinha que ser opção do EC.
Eu não entendi o raciocínio. Se na hora da notificação eu tenho que validar o mTLS de qualquer forma, melhor que a validação aconteça no cadastro da URL, mesmo, como está hoje. É um benefício gigante eu não precisar gerar o acionamento de webhooks pra saber se a configuração tá correta!
Espera-se que sim. Ele vai conseguir cadastrar a URL. Quando for notificado, nós enviaremos o certificado. Isso abre caminhos para que o integador decida como validar que a requisição que está chegando é realmente da Gerencianet. Talvez ele não possa alterar uma configuração do nginx por estar sendo compartilhado com outras aplicações, porém talvez ele possa "ensinar" o nginx a repassar essa informação pra dentro da aplicação e validar manualmente via código.
A ideia da validação durante o PUT é pra ajudar a validar o ambiente mTLS, não seria, digamos, mandatória.
<@!793123559874494465> poderia dissertar melhor sobre isso: "- Permitir o cadastro da URL no PUT /webhooks sem validação ativa do mTLS no momento do consumo;"?
<@!780500321994539068>, bom dia!. Sugere então testarmos com uma url https://meudominio.com.br/pix por exemplo, e testar sem o /pix. Certo?
