Boa tarde, @cachorro_05667!
Em nossa documentação da API Pix falamos sobre o webhook, segue o link: https://dev.efipay.com.br/docs/api-pix/webhooks
Termos mais procurados:
Histórico de mensagens sobre webhook pix 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
- Recebimento de Pagamentos via QR Code e Arduino
- Repetição do Processo de Criação com txid
- Implementação do Módulo Gerencianet no Perfex CRM
- Teste de Status de Pagamento em Ambiente de Homologação
- Tempo Médio de Análise de Documentos na Abertura de Conta
- Integrações com o Laravel e SDK de PHP da EFI
- Problemas com Token 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
- Funcionamento do Webhook em Ambiente de Homologação
- 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)
- Utilização de Endpoints e Payload no Pix
- Notificações de Pagamento de Boleto e Pix
- Interpretação do Campo 'Solicitação ao Pagador' no Webhook GN
EXIBINDO CONVERSAS RECENTES:
Texto: webhook pix
Canal: sugestões
Atualizem o guia de configuração nginx do hand-shake do pix,
nginx
server {
#
# ...
#
listen [::]:443 ssl ipv6only=on;
listen 443 ssl;
ssl_certificate server_ssl.crt.pem;
ssl_certificate_key server_ssl.key.pem;
ssl_client_certificate /root/chain-pix-webhooks-prod.crt;
ssl_verify_client optional;
ssl_verify_depth 3;
#
# ...
#
location /webhook {
if ($ssl_client_verify != SUCCESS) {
return 403;
}
proxy_pass /webhook;
}
}
#Desenvolvido pela Consultoria Técnica da Gerencianet
paraserver {
#
# ...
#
listen [::]:443 ssl ipv6only=on;
listen 443 ssl;
ssl_certificate server_ssl.crt.pem;
ssl_certificate_key server_ssl.key.pem;
ssl_client_certificate /root/chain-pix-webhooks-prod.crt;
ssl_verify_client optional;
ssl_verify_depth 3;
#
# ...
#
location /webhook {
if ($ssl_client_verify != SUCCESS) {
return 403;
}
proxy_pass /webhook;
}
}
#Desenvolvido pela Consultoria Técnica da Gerencianet
nginx
server {
#
# ...
#
listen [::]:443 ssl ipv6only=on;
listen 443 ssl;
ssl_certificate server_ssl.crt.pem;
ssl_certificate_key server_ssl.key.pem;
ssl_client_certificate /root/chain-pix-webhooks-prod.crt;
ssl_verify_client optional;
ssl_verify_depth 3;
#
# ...
#
location /webhook {
if ($ssl_client_verify != SUCCESS) {
return 403;
}
proxy_pass https://IP_DA_APLICAÇÃO:7080/webhook;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
#Desenvolvido pela Consultoria Técnica da Gerencianet
server {
#
# ...
#
listen [::]:443 ssl ipv6only=on;
listen 443 ssl;
ssl_certificate server_ssl.crt.pem;
ssl_certificate_key server_ssl.key.pem;
ssl_client_certificate /root/chain-pix-webhooks-prod.crt;
ssl_verify_client optional;
ssl_verify_depth 3;
#
# ...
#
location /webhook {
if ($ssl_client_verify != SUCCESS) {
return 403;
}
proxy_pass https://IP_DA_APLICAÇÃO:7080/webhook;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
#Desenvolvido pela Consultoria Técnica da Gerencianet
Se não tem devolucoes é pq não houve ainda nenhuma devolução daquele Pix. Se completar alguma devolução, vai ter esse campo. Mas isso segue o especificado pelo BACEN... só o webhook de envio de Pix que é definido pela GN.
Padronizar o retorno de webhook de PIX, retornando TIPO em todas as requisições (atualmente só em pix enviado: tipo = 'solicitacao')
Pessoal, trazendo para cá a discussão sobre devolução por parte do favorecido. Contexto:
Pessoal, uma dúvida sobre devolução de pix.
1. Pix enviado da GN > Chave qualquer. Recebo o webhook com a realização ou não. Tudo certo.
2. A partir da conta "favorecida", faço a devolução do pix.
Essa devolução por parte do "favorecido" deveria ativar o webhook e notificar minha aplicação? Entendo que a devolução esteja atrelada ao e2eid original.
Eu testei esse cenário aqui e não fui notificado. É um comportamento esperado ou temos um gap aí?
1. Pix enviado da GN > Chave qualquer. Recebo o webhook com a realização ou não. Tudo certo.
2. A partir da conta "favorecida", faço a devolução do pix.
Essa devolução por parte do "favorecido" deveria ativar o webhook e notificar minha aplicação? Entendo que a devolução esteja atrelada ao e2eid original.
Eu testei esse cenário aqui e não fui notificado. É um comportamento esperado ou temos um gap aí?
Sugestão: alinhar melhor com a equipe as informações a respeito dos [novos] recursos e exigências [removidas] para consumo da API Pix. Por ex: as informações a respeito da necessidade ou não de mTLS no PUT /webhook, bem como no recebimento dos callbacks, estão desencontradas lá no canal <#❖pix>. Tem membros da equipe GN dizendo A e outros membros dizendo B.
Na verdade, .webhook.pix.ae. Precisa do servername para decidir qual certificado apresentar.
## 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.
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]+$"
}
}
}