No caso de acontecer um longo loop, nosso time entraria em contato com o cliente solicitando correção ou pedindo para desabilitar (com autorização do cliente) o Webhook
Termos mais procurados:
Histórico de mensagens sobre webhook em sugestões
PROCURE NO HISTÓRICO
CANAIS DE TEXTO
DISCUSSÕES
- Conceito de Payload Locations no PIX
- Inserção automática do formato do Pix copia e cola pelo WhatsApp
- Autenticação com Certificado em NextJS
- Consulta de Chave PIX na API de Envio
- Configuração de URLs para Recebimento de Status
- Acionamento de Webhooks em Pagamentos e Devoluções
- Implementação da SDK do Pix em Next.js ou React
- Cobrança em Período de Teste Grátis de 7 dias
- Especificação da URL do Webhook no Exemplo Pix
- Repetição do Processo de Criação com txid
- Recebimento de Pagamentos via QR Code e Arduino
- Implementação do Módulo Gerencianet no Perfex CRM
- Tempo Médio de Análise de Documentos na Abertura de Conta
- Teste de Status de Pagamento em Ambiente de Homologação
- Integrações com o Laravel e SDK de PHP da EFI
- Problemas com Token em Ambiente de Homologação
- Funcionamento do Webhook em Ambiente de Homologação
- Geração de Link de Pagamento e Reembolso
- Resolução de Delay nas Chamadas de Geração de QR Code e Pix em Node
- Retenção de Pagamento no PIX em Marketplace
- Cancelamento de Boleto e Remoção do DDA
- Integração de Pix no Bubble (Plataforma No-Code)
- Notificações de Pagamento de Boleto e Pix
- Utilização de Endpoints e Payload no Pix
- Interpretação do Campo 'Solicitação ao Pagador' no Webhook GN
EXIBINDO CONVERSAS RECENTES:
Texto: webhook
Canal: sugestões
Pessoal, hoje após 5 tentativas o webhook de notificação está sendo desativado. Isso faz com que ele precise de rearme manual; seria melhor o sistema continuar retentando para que ele se rearme automaticamente. Hoje o intervalo máximo entre notificações chega a 80 minutos, e quer seja 80, 120 ou 160 minutos de intervalo após decaimento exponencial, eu sugiro que o sistema continua tentando exatamente para evitar desarme/rearme. Se isso perdurar alguma ação manual por parte da Gerencianet talvez faça mesmo sentido, mas que por padrão o comportamento seja de reestabelecer a notificação é minha forte preferência. Que acha, <@!793123559874494465> ?
## Objetivo
Permitir que o EC defina algumas configurações:
- Quando aceitar um txid;
- Aceitar ou não Pix Manual;
- Quais notificações receber via webhooks;
- Receber ou não a tarifa no webhook;
- Outras configurações podem surgir.
---
# PUT /gn/config
## Input
json
{
"pix": {
"aceitarSemChave": true,
"chaves": [{
"valor": "[email protected]",
"webhook": {
"notificar": {
"envio": true,
"recebimento": true,
"devolucao": true,
"recusa": true
},
"incluir": {
"tarifa": true
}
},
"recebimento": {
"txidRegex": "^[a-zA-Z0-9]+$"
}
}, {
"valor": "[email protected]",
"webhook": {
"notificar": {
"envio": false,
"recusa": false
}
}
}]
}
}
{
"pix": {
"aceitarSemChave": true,
"chaves": [{
"valor": "[email protected]",
"webhook": {
"notificar": {
"envio": true,
"recebimento": true,
"devolucao": true,
"recusa": true
},
"incluir": {
"tarifa": true
}
},
"recebimento": {
"txidRegex": "^[a-zA-Z0-9]+$"
}
}, {
"valor": "[email protected]",
"webhook": {
"notificar": {
"envio": false,
"recusa": false
}
}
}]
}
}
## Output: 200
---
## Definições
Por default:
→ Todas as notificações nascem habilitadas;
→ Não há match de regex: aceita-se qualquer txid;
→ Tarifa não é retornada no webhook;
→ Pix Manual é acatado sempre;
Default em JSON
json
{
"pix": {
"aceitarSemChave": true,
"chaves": [{
"valor": "[email protected]",
"webhook": {
"notificar": {
"envio": true,
"recebimento": true,
"devolucao": true,
"recusa": true
},
"incluir": {
"tarifa": true
}
},
"recebimento": {
"txidRegex": "" // se vazio, desconsiderar
}
}]
}
{
"pix": {
"aceitarSemChave": true,
"chaves": [{
"valor": "[email protected]",
"webhook": {
"notificar": {
"envio": true,
"recebimento": true,
"devolucao": true,
"recusa": true
},
"incluir": {
"tarifa": true
}
},
"recebimento": {
"txidRegex": "" // se vazio, desconsiderar
}
}]
}
{
"pix": {
"recebimentoManual": "aceitar",
"chaves": [{
"valor": "[email protected]",
"webhook": {
"notificar": {
"envio": true,
"recebimento": true,
"devolucao": true,
"recusa": true
},
"incluir": {
"tarifa": true
}
},
"recebimento": {
"txidRegex": "^[a-zA-Z0-9]+$"
}
}, {
"valor": "[email protected]",
"webhook": {
"notificar": {
"envio": false,
"recusa": false
}
}
}]
}
}
"pix": {
"recebimentoManual": "aceitar",
"chaves": [{
"valor": "[email protected]",
"webhook": {
"notificar": {
"envio": true,
"recebimento": true,
"devolucao": true,
"recusa": true
},
"incluir": {
"tarifa": true
}
},
"recebimento": {
"txidRegex": "^[a-zA-Z0-9]+$"
}
}, {
"valor": "[email protected]",
"webhook": {
"notificar": {
"envio": false,
"recusa": false
}
}
}]
}
}
Definições:
Por default:
- Todas as notificações nascem habilitadas;
- Não há match de regex: aceita-se qualquer txid;
- Tarifa não é retornada;
- Pix Manual é acatado sempre;
Default em JSON
{
"pix": {
"recebimentoManual": "aceitar",
"chaves": [{
"valor": "[email protected]",
"webhook": {
"notificar": {
"envio": true,
"recebimento": true,
"devolucao": true,
"recusa": true
},
"incluir": {
"tarifa": true
}
},
"recebimento": {
"txidRegex": "" // se vazio, desconsiderar
}
}]
}
"pix": {
"recebimentoManual": "aceitar",
"chaves": [{
"valor": "[email protected]",
"webhook": {
"notificar": {
"envio": true,
"recebimento": true,
"devolucao": true,
"recusa": true
},
"incluir": {
"tarifa": true
}
},
"recebimento": {
"txidRegex": "" // se vazio, desconsiderar
}
}]
}
Observação
Quando de um envio de Pix: a notificação de webhook, em caso de status NAO_REALIZADO , poderá trazer o motivo da falha (PSP deu timeout, recusou, etc..). Em outro momento falaremos disso.
<@!522899003663450113> acredito que podemos assumir que, se webhook.notificar.envio for habilitado, a notificação do envio de Pix será enviada com a informação se foi sucesso ou falha. Em caso de falha, irá constar o motivo, que pode ser uma recusa ou timeout do PSP recebedor.
Será que todo Pix Manual não deve ser entendido como transferência e, por conseguinte, ser sempre aceito e nunca acionar webhook? 🤔
Atualizando:
PUT /gn/config
{
"pix": [{
"chave": "[email protected]",
"webhook": {
"notificar": {
"envio": true,
"recebimento": true,
"devolucao": true,
"recusa": true
},
"incluir": {
"tarifa": true
}
},
"recebimento": {
"txidRegex": "^[a-zA-Z0-9]+$"
}
}, {
"chave": "[email protected]",
"webhook": {
"notificar": {
"envio": false,
"recebimento": false,
"devolucao": false,
"recusa": false
},
"incluir": {
"tarifa": false
}
},
"recebimento": {
"txidRegex": "^[a-zA-Z0-9]+$"
}
}]
}
"pix": [{
"chave": "[email protected]",
"webhook": {
"notificar": {
"envio": true,
"recebimento": true,
"devolucao": true,
"recusa": true
},
"incluir": {
"tarifa": true
}
},
"recebimento": {
"txidRegex": "^[a-zA-Z0-9]+$"
}
}, {
"chave": "[email protected]",
"webhook": {
"notificar": {
"envio": false,
"recebimento": false,
"devolucao": false,
"recusa": false
},
"incluir": {
"tarifa": false
}
},
"recebimento": {
"txidRegex": "^[a-zA-Z0-9]+$"
}
}]
}
Até então estamos assim:
PUT /gn/config
{
"pix": {
"webhook": {
"notificar": {
"envio": true,
"recebimento": true,
"devolucao": true,
"recusa": true
},
"incluir": {
"tarifa": true
}
},
"recebimento": {
"txidRegex": "^[a-zA-Z0-9]+$"
}
}
}
"pix": {
"webhook": {
"notificar": {
"envio": true,
"recebimento": true,
"devolucao": true,
"recusa": true
},
"incluir": {
"tarifa": true
}
},
"recebimento": {
"txidRegex": "^[a-zA-Z0-9]+$"
}
}
}
- Próxima alteração: tratar configurações por chave;
- <@!293443355915059210> esse endpoint, de fato, não substitui, posteriormente, um painel em uma UI autenticada;
- <@!440035527127990273> de fato, esse endpoint precisará de um escopo específico. Podemos pensar também em um mecanismo de autenticação de 2 fatores;
Se for por cada chave (Webhook nesse caso) seria interessante colocar no singular. Mas se for algo pra todas os Webhooks eu deixaria no plural
Em relação a isso já que implementaram também o envio do Pix e ele é async, seria interessante criar um webhook também pra recusa do PSP recebedor...
Aqui eu não utilizo nenhum dos webhooks a não ser de recebimento, então pra mim faz sentido sim.
Observem que coloquei um atributo webhooks.notificar.devolucao.
Faz sentido pra vocês optar por ser notificado de um recebimento e não de uma devolução? 🤔
E o input está ficando assim:
{
"pix": {
"webhooks": {
"notificar": {
"envio": true,
"recebimento": true,
"devolucao": true,
"recusa": true
},
"incluir": {
"tarifas": true
}
},
"recebimentos": {
"txidRegex": "^[a-zA-Z0-9]+$"
}
}
}
"pix": {
"webhooks": {
"notificar": {
"envio": true,
"recebimento": true,
"devolucao": true,
"recusa": true
},
"incluir": {
"tarifas": true
}
},
"recebimentos": {
"txidRegex": "^[a-zA-Z0-9]+$"
}
}
}
<@!793123559874494465> que tal assim?
{
"pix": {
"webhooks": {
"notificar": {
"envio": true,
"recebimento": true,
"recusa": true
},
"incluir": {
"tarifas": true
}
},
"recebimentos": {
"regex": "^[a-zA-Z0-9]+$"
}
}
}
"pix": {
"webhooks": {
"notificar": {
"envio": true,
"recebimento": true,
"recusa": true
},
"incluir": {
"tarifas": true
}
},
"recebimentos": {
"regex": "^[a-zA-Z0-9]+$"
}
}
}
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.
{
"pix": {
"webhooks": {
"notificar": {
"envio": true,
"recebimento": true,
"recusa": true
}
},
"tarifas": {
"informar-no-webhook": true
},
"pagamentos": {
"validar-txid-regexp": "^[a-zA-Z0-9]+$"
}
}
}
"pix": {
"webhooks": {
"notificar": {
"envio": true,
"recebimento": true,
"recusa": true
}
},
"tarifas": {
"informar-no-webhook": true
},
"pagamentos": {
"validar-txid-regexp": "^[a-zA-Z0-9]+$"
}
}
}
Sugestão para a incorporação do /pix: no teste de ativação do webhook, testar primeiro com /pix. Se funcionar, já sabe que esse cliente está preparado e usa dessa forma. Se não funcionar, por enquanto ativa sem /pix, vai registrando para notificar os clientes para mudar.
a falha de segurança não existe se a GN valida que apenas requests com mTLS serão respondidos, Rafael. entendo que você queira sugerir um exemplo onde o ssl_verify_client seja on, mas isso só é possível em server {} exclusivo para webhooks. o exemplo dado é para um server {} onde requests de webhook (mTLS) e outros requests coexistem, e não há nada de inseguro nisso, especialmente depois de passar por validação.