Termos mais procurados:
Bom dia, @Hagi. Como vai?
Existe sim. Na API Pix você deve registrar sua URL webhook associada a uma chave Pix, que pode ser o CNPJ. Então toda cobrança emitida com sua chave Pix que possuir um txid, nó iremos acionar o seu webhook para notificação.
Veja mais detalhes em nossa documentação: https://dev.gerencianet.com.br/docs/api-pix-endpoints#webhooks
Olá @lordvitao! No caso de boletos é um pouquinho diferente. A URL deve ser informada em cada requisição; enviaremos um POST com o token de notificação, o seu servidor deve então consultar este token para conseguir visualizar o conteúdo informado.
Bom dia @leofnh ! Quando uma transação possui uma URL de notificação cadastrada (atributo notification_url), a Efí dispara um POST para esta URL a cada mudança no status da cobrança. Esse POST vai conter um token de notificação. Então você precisa cadastrar uma URL de notificação na cobrança e prepará-la para mostrar/armazenar o token de notificação para você consultar essa informação.
Olá @snarloff !
Para as cobranças Pix, você consegue simular da seguinte forma:
Se o valor da cobrança está entre R$ 0.01 à R$ 10.00:
A cobrança é confirmada, informação virá via Webhook.
Se o valor da cobrança é maior que R$ 10.00:
A cobrança permanece ativa, sem confirmação. Como não há webhook nesses casos, nada é feito.
Já para os boletos, você consegue cadastrar uma URL de Notificação em Homologação e receber as notificações. Mais detalhes aqui: https://dev.gerencianet.com.br/docs/notificacoes-recebendo
Boa tarde @excapy_web ! Quando uma transação possui uma URL de notificação cadastrada, a Efí dispara um POST para esta URL a cada mudança no status da cobrança. Essa notificação possui um token específico e o seu sistema deve consultar essa informação.
Bom dia @grupothx !
Em hospedagem compartilhada não é possível configurar o mTLS por não fornecerem as permissões necessárias.
Não sendo possível configurar o mTLS, você pode configurar uma URL de webhook ignorando esta validação.
Para isto, basta informar o parâmetro x-skip-mtls-checking igual a true no Header da requisição PUT /v2/webhook/:chave que será registrado seu webhook URL sem a validação do mTLS.
Desta forma, caso opte por deixar o x-skip-mtls-checking como true, a Efí vai continuar a enviar o certificado na requisição, mas como mencionado, seu servidor irá ignorá-lo.
No entanto é aconselhável que você encontre uma forma de validar se é a Efí quem está enviando a notificação, pois, sem o mTLS configurado não há o "hand-shake". Uma sugestão é verificar o IP de quem está notificando, pois a Efí comunica os webhook através do IP 34.193.116.226
Também estou com essa dúvida. Mas pelo o que eu estou sacando, funciona mais ou menos assim:
- vc recebe uma notificação em uma url que você cadastrou quando criou a assinatura. essa notificação tem só um token.
- com esse token, você vai na url /notification/[token] e pede as alterações. Aí vc recebe um array de objetos como esse da imagem
- Ali o rosa é o tipo de cada notificação. Se for "subscription_charge", significa que é uma modificação relativa a uma cobrança da assinatura.
- No amarelo você vê o status da cobrança e no azul vc tem o id dela. Aí se current for new, vc já sabe que uma nova cobrança acabou de ser gerada. Se for waiting, já sabe que a forma de pagamento foi definida e agora está agurdando a confirmação. Essa variação de new e waiting é no mesmo instante quando a assinatura já existe. Ela faz mais sentido quando você cria a assinatura e ainda não definiiu como será o meio de pagamento dela. Quando você usa o one-step é tudo junto.
Olá, @Silvio Fernadnes. Bom dia!
Quando você define uma URL de notificação em um boleto, a Efí dispara um POST para esta URL a cada mudança no status da cobrança. Por segurança essa notificação possui um token específico, que será o mesmo durante todo o "ciclo de alterações" da transação.
Então, sua aplicação deve receber o token na variável $_POST['notification'] e consultar essa informação através do endpoint GET /v1/notification/:token, a resposta será todos os dados informativos sobre a alteração sofrida pela cobrança, como por exemplo, o status anterior e atual da cobrança.
Nos seguintes link você encontra mais detalhes:
https://dev.gerencianet.com.br/docs/notificacoes-recebendo
https://dev.gerencianet.com.br/docs/playground-notificacoes
Qualquer dúvida, conte com a gente!
Estou tentando descobrir quais os status de uma cobrança pix que são enviados para o webhook, para poder construir o webhook do meu lado. Estou usando o template https://github.com/gerencianet/gn-api-sdk-typescript/blob/main/examples/pix/webhooks/pixConfigWebhook.ts para configurar a url gerada no webhookinbox, porém não estou recebendo nenhum evento e quando tento acessar o sistema, para ver as notificações de produção estou recebendo algumas vezes um erro - Erro interno do servidor
E não consigo ver nenhum historico de requisição e notificação, alguém consegue me ajuda?
Quero mudar a URL de notificação da API para: http://177.126.87.137:8180/
No Bolix da GN a URL de notificação é um parâmetro na criação do título. Se você não passar o parâmetro, não vai acionar. E pode inclusive cada título ter uma URL diferente.
Do Bolix vc pede para o pessoal da @consultoria_efi marcar um determinado título como pago e isso aciona a URL de notificação.
O atributo notification_url vai estar vinculado ao link de pagamento criado.
O botão em si onde é exibido o link é indiferente. Estando vinculado ao link, quando ocorrer o pagamento é feita a notificação
No Bolix o webhook é configurado a cada transação, acho que está como URL de notificação.
@Gerencianet Gostaria que me esclarecesse uma dúvida. Considerando que estou integrando o sistema de assinatura usando o sdk node, e implementado aqui o endpoint de cancelamento da assinatura:
Quando se cria a cobrança se passa uma URL de notificação
https://dev.gerencianet.com.br/docs/notificacoes-recebendo
Quando você cria o boleto você pode definir uma URL de retorno no parâmetro metadata>notification_url
Desta forma, automaticamente nossa API dispara um POST para esta URL a cada mudança no status da cobrança. Essa notificação possui um token específico, que será o mesmo durante todo o "ciclo de alterações" da transação. Por exemplo:
Foi gerada uma cobrança. Seu sistema recebe um POST da Gerencianet contendo o token de notificação 09027955-5e06-4ff0-a9c7-46b47b8f1b27 e informando o status da transação - neste caso, waiting;
Posteriormente, essa mesma cobrança teve o pagamento confirmado, então, o status muda para paid e novamente seu sistema recebe uma notificação, ainda com o mesmo token 09027955-5e06-4ff0-a9c7-46b47b8f1b27.
Então sempre que sua aplicação receber notificações, deve-se consultar o token para obter os dados atualizados da transação.
https://dev.gerencianet.com.br/docs/notificacoes-recebendo#21-exemplos-de-respostas
Boa tarde @drogaehobrian.! Tudo bem? Você pode cadastrar uma URL de notificação nas assinaturas. Por meio dessa URL enviaremos as notificações de baixa e/ou qualquer atualização da assinatura. Esse endpoint está sim disponível par testes em sandbox!
A diferença é que na de emissões você define a URL de notificação para cada boleto emitido, e na de Pix, para cada chave Pix. Por isso que na de Pix tem um método específico, enquanto na de emissões é um parâmetro.
@igor_efi Fala meu amigo bora tirar mais uma dúvida. Me corrija se estiver errado.
Entendi que vou receber um post com código da notificação na url indicada no campo notification
código esse que devo utilizar para consultar os dados da notificação e fazer a tratativa no meu sistema. Correto?
