Histórico de mensagens sobre webhook

Olá, estou estudando a api de pix do EfiPay, até o momento estou bem feliz com tudo que estou vendo. Mas ainda estou com algumas dúvidas que são mais para confirmar se eu realmente entendi bem tudo.

# PIX + Split de pagamento
Eu tenho intenção de usar o split de pagamento juntamente com PIX. Vi que existe uma forma onde eu crie uma split config no POST /v2/gn/split/config .
- Uma vez que eu criar uma split config, não existe uma forma onde eu consiga criar o pagamento PIX já com o split config em uma única requisição?
- Eu tenho que criar o PIX e então associar o split de pagamento previamente criado? (2 requisições)

# PIX Webhooks
Outra importante parte que precisarei integrar é a api de webhook, também vi que precisa cadastrar este event jutamente com uma chave PIX. Portanto se tiver 3 chaves, serão 3 subscriptions para escutar os updates relacionados a estas chaves.
- Existe uma forma onde eu possa registrar meu webhook globalmente ao invés de registrar por chave?

É possivel verificar o status do bolepix via webhook? Não encontrei nada falando sobre na pagina da documentação do bolepix

O request do webhook do Pix é um POST. A URI é aonde você escolheu hospedar...

Mesmo na devolução, o webhook vai dar a nova situação daquele Pix.
O que você precisa validar é (1) certificado da Efí no mTLS (2) que a chave Pix é uma para a qual você emitiu cobrança naquele txid

copié y pegué el archivo .php del ejemplo lo analicé para entender qué hacía y me pareció que no me hacía lo que peregunté. Para confirmar le puse https://pix.gerencianet.com.br/webhooks/chain-pix-prod.crt dentro del request URI y lo corrí, y como me imaginé, no anda. Por favor, necesito un ejemplo claro para permitir que mi server se pueda contactar al server de EFI. Hay dos errores que me aparecen:
PHP Warning: Undefined array key "REQUEST_METHOD" in /home/goopzer/ipn/EFI_webh.php on line 46
PHP Warning: Undefined array key "https://pix.gerencianet.com.br/webhooks/chain-pix-prod.crt" in /home/goopzer/ipn/EFI_webh.php on line 47

Me pueden indicar específicamente qué escribir en esos dos campos por favor?
REQUEST_METHOD
REQUEST_URI

Saludos

quando acontece uma mudança no status do pix o meu servidor vai receber um webhook, mas como posso diferenciar os tipos de webhook recebidos, não estou vendo nenhum STATUS na resposta, preciso pegar o txid e fazer uma consulta para ter certeza, para não ocorrer uma baixa indevida no caso de ouver uma devolução por exemplo?

Todos os concorrentes da Efí que analisamos que seguiam a API Pix padrão do BACEN tem webhook com mTLS... vários inclusive que requerem certificado ICP-Brasil no webhook, o que é tremendamente não prático. A Efí emite os certificados com CA dela o que é bem simples de usar.

Vou utilizar a EFI por conta do SDK e documentação que é maravilhosa, mas a questão do WEBHOOK do pix é realmente uma pedra no sapato, não tem nenhum concorrente da EFI que eu tenha conhecimento que utilize mtls, pra implementar isso no meu sistema eu vou ter que mudar toda a estrutura do meu servidor aumento muito o nivel de complexidade para simplesmente receber a confirmação do recebimento. Pensei varias vezes em mudar para outra plataforma por causa disso. Para não ter que fazer a configuração do mtls estou pensando em validar de outra maneira atraves das chamadas mesmo. Assim que o usuario atualizar a tela ou entrar fazer a chamada para verificar. Isso deixa a desejar muito.

Olá, @diogo.f.m.7 e @rubenskuhl. Bom dia!

Gostaríamos de esclarecer que, conforme as normas do Banco Central, as notificações enviadas do PSP recebedor (no caso, a Efí) para o usuário recebedor trafegam utilizando o canal mTLS. Como parte desse protocolo, sempre enviamos o certificado nos webhooks, seja no cadastro ou na notificação de Pix.

Entendemos que em alguns cenários, como hospedagem em servidores compartilhados, pode haver restrições em relação à inserção de certificados. Por isso, disponibilizamos a opção skip mTLS, que permite o cadastro do webhook sem a necessidade do hand shake mTLS por parte do integrador. É importante destacar que, ao optar por utilizar o atributo skip mTLS, o integrador fica responsável por validar o nosso certificado, conforme as orientações que fornecemos.

Ressaltamos que sempre seguimos as diretrizes do Banco Central para garantir a segurança e conformidade de nossos serviços. 🧡

Esse foi um dos modelos sugeridos para o BACEN, que disse não... o que aliás até se voltou contra a segurança quando se descobriu o ataque do webhook via outra conta.

Não não, concordo, foi só uma opinião, de q o webhook é o menor dos problemas... Kkkk

Era mais fácil o Bacen colocar para só enviar o id da transação, e o cliente fazia uma Consulta...

A api antiga do PagSeguro, era assim, o webhook, só trazia o código da notificação, não era nem o id da transação, e o cliente consumia um endpoint para saber oq era aquela notificação, e o código de notificação, tinha uma prazo para expirar...

O certificado para gerar a transação, criar a cobrança, acho q deveria ter em todos os endpoints... Pix, cartão, boleto...

Mas o webhook, vamos ser sinceros, muda nada...

Esse tipo de argumento foi passado para o BACEN, está no histórico do Github do BACEN. Mas não aceitaram, e o padrão é com mTLS. Notar que o webhook do Pix tem mais informações do que só um transaction ID, então isso pode ter colaborado para essa exigência. Ou por homogeneidade com o OpenFinance.

Não é pq o webhook falhou, q o Pix vai ser desfeito... Se o webhook não chegar na aplicação, nada muda, financeiramente...

Até pq, uma opinião minha agr...
O webhook é o ponto "menos importante" pq a transação já aconteceu...

Uma forma de segurança q eu uso, pq vem da época de webhook q não tinha mtls, q é o caso do cartão e boleto, é quando recebo um webhook, não confiar nele, pego o id da transação e eu faço a consulta a api para validar o status...

@igor_efi @elaine2983, podem dar uma orientação sobre esse assunto?? Em produção, usando hospedagem compartilhada, posso usar o skip-mtls, e validar o webhook pelo IP de origem??

Não não, só olhar a doc deles... Eles deixam bem claro que em hospedagem compartilhada pode usar o skip-mtls, e fazer a validação do webhook via IP de origem da request...

ja verifiquei se os certificados estão conseguindo ser acessados nesses locais, e estou fazendo as chamadas no o link de sandbox, se eu desabilitar a verificação do certificado consigo cadastrar a chave normalmente, e recebo um webhook avisando que foi cadastrado, mas quando habilito a verificação ele consegue concluir.

Boa tarde, @geovannisc! Tudo bem?

Parece que o certificado utilizado está configurado para o ambiente sandbox, e isso pode causar uma falha 403 ao tentar cadastrar o webhook no ambiente de produção.

Outra possível causa para essa falha pode estar relacionada ao local onde o arquivo está armazenado. Se o caminho do arquivo contém espaços ou caracteres especiais, isso pode estar causando impacto na configuração e resultar na falha mencionada.

Para resolver esses problemas:
1 - Certifique-se de que está utilizando o certificado correto para o ambiente de produção, se aplicável. Verifique se o certificado está configurado corretamente para o ambiente em questão.
2 - Verifique o caminho do arquivo do certificado e certifique-se de que não há espaços ou caracteres especiais que possam causar problemas na configuração. Renomeie o arquivo ou mova-o para um local sem espaços ou caracteres especiais, se necessário.

Ao resolver essas questões, você poderá evitar a falha 403 e garantir uma configuração adequada do webhook.