sendo o "webhookUrl/pix" acionado somente no recebimento de Pix e trazendo o txid + valor pago, já possibilitaria muitas integrações. com mTLS não fica tão facilitado, mas ainda perfeitamente possível.
Termos mais procurados:
Histórico de mensagens sobre Recebimento
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
- 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
- Configuração de URLs para Recebimento de Status
- 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
- Tempo Médio de Análise de Documentos na Abertura de Conta
- Integrações com o Laravel e SDK de PHP da EFI
- Teste de Status de Pagamento em Ambiente de Homologação
- Problemas com Token em Ambiente de Homologação
- Funcionamento do Webhook em Ambiente de Homologação
- Resolução de Delay nas Chamadas de Geração de QR Code e Pix em Node
- Geração de Link de Pagamento e Reembolso
- Retenção de Pagamento no PIX em Marketplace
- Cancelamento de Boleto e Remoção do DDA
- Notificações de Pagamento de Boleto e Pix
- Utilização de Endpoints e Payload no Pix
- Integração de Pix no Bubble (Plataforma No-Code)
- Interpretação do Campo 'Solicitação ao Pagador' no Webhook GN
EXIBINDO CONVERSAS RECENTES:
Texto: Recebimento
Mas para só o recebimento de notificações bastar, ele precisa ter as informações do recebimento... o que cai em requisitos que muitos acham pesados como mTLS. A simplificação do webhook com apenas (vê aí o que mudou no txid tal) torna a API direta mais necessária do que nunca. A única coisa que poderia atender isso seria não uma URL de notificação, mas o comprovante Pix digitalmente assinado.
No meu ponto de vista o principal entrave de adoção é a dificuldade técnica para o recebimento de notificações. Se fosse simples definir uma URL de notificação e o mercado pudesse ofertar serviços totalmente baseadas em QR estáticos (que são mais que suficientes para negócios cujo pagamento não tem vencimento, estão associados a um checkout imediato, como compras presenciais e e-commerce varejo padrão), sem necessidade de contratação da API por parte dos ECs, a adoção teria bombado.
Como eu faço envio de PIX pela api? Vi que não é possivel.. preciso ativar o envio? Os recebimentos estão vindo normalmente
Lembrando o informativo enviado:
Informativo sobre à adequação do /pix no webhook
Foi estabelecido que ao realizar o cadastro do webhook base pelo integrador, ocorrerá a adição do parâmetro /pix no POST {$request.body#/webhookUrl} pela Gerencianet no momento do disparo das requisições.
Abaixo trazemos alguns exemplos de webhook's e como será a notificação após esta mudança:
Integrador cadastrou a url base https://gerencianet.com.br, ao acionar o webhook uma requisição do tipo POST será enviada para https://gerencianet.com.br/pix.
Integrador cadastrou a url base https://gerencianet.com.br/pix, ao acionar o webhook uma requisição do tipo POST será enviada para https://gerencianet.com.br/pix/pix.
Integrador cadastrou a url base https://gerencianet.com.br/?id=0000x22, ao acionar o webhook uma requisição do tipo POST será enviada para https://gerencianet.com.br/?id=0000x22/pix.
Seguindo então a nossa documentação o serviço será POST {$request.body#/webhookUrl}/pix.
Tal definição foi feita após analisar os feedbacks de integradores, questionamentos ao BACEN e discussões internas.
A data para deploy do novo padrão está alinhada para o dia 08/02/2021. Sendo esta arbitrada a fim de que todos os integradores da API-Pix que utilizam o serviço de webhook possam ajustar seus sistemas e aplicações, e evitar assim falhas ou mal funcionamento do serviço.
Uma sugestão é permitir o recebimento da notificação em ambos os modos: com e sem /pix. Dessa forma, quando virarmos a chave, não haverá problemas.
Quaisquer dúvidas referentes a esta transição, estamos a disposição em nossos canais de comunicação.
O que se cadastra no webhook é a chave Pix, por exemplo [email protected] . Aí todo recebimento para essa chave Pix que tiver txid vai chamar a URL (mais o sufixo /pix a partir de daqui alguns dias).
Bom dia. É possível fazer o split no recebimento de um pix?
O estático pode ter txid e aí ser único por recebimento ou único por cliente, a seu critério. A comparação do estático é com boleto sem registro e do dinâmico com boleto registrado.
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.
ola boa tarde
estou com duvidas no recebimento das notificações do carne
a api de voces envia por meio de post.
mas as informações são do tipo Json, string ou outro formato.
Então se seus recebimentos são para [email protected] como chave, só precisa configurar webhook uma vez.
Boa tarde @Deleted User! O status do exemplo 1 refere-se ao status da devolução. No exemplo 2 é o recebimento de um Pix e por isso não tem status.
O webhook é "trigado" qto tempo depois do recebimento do pix?
Eu estava observando aqui: a nova documentação de UX do Pix (v3.0) agora determina que é obrigatório as notificações de recebimento Pix (push, sms, email) conterem a descrição digitada pelo pagador e também o txid, quando houver. WOW!
Boa tarde @everyone, sobre à adequação do /pix no webhook, ficou definido que será feito o cadastro do webhook base pelo integrador e a adição do parâmetro /pix no POST {$request.body#/webhookUrl} pela Gerencianet no momento do disparo das requisições.
Abaixo trazemos alguns exemplos de webhook e como será a notificação:
Integrador cadastrou a url base https://gerencianet.com.br/, ao acionar o webhook uma requisição do tipo POST será enviada para https://gerencianet.com.br/pix.
Integrador cadastrou a url base https://gerencianet.com.br/pix, ao acionar o webhook uma requisição do tipo POST será enviada para https://gerencianet.com.br/pix/pix.
Integrador cadastrou a url base https://gerencianet.com.br/?id=0000x22, ao acionar o webhook uma requisição do tipo POST será enviada para https://gerencianet.com.br/?id=0000x22/pix.
Seguindo então a nossa documentação o serviço será POST {$request.body#/webhookUrl}/pix.
Tal definição foi feita após analisar os feedbacks de integradores, questionamentos ao BACEN e discussões internas.
A data para deploy do novo padrão está alinhada para o dia 01/02/2021. Sendo esta arbitrada a fim de que todos os integradores da API-Pix que utilizam o serviço de webhook possam ajustar seus sistemas e aplicações, e evitar assim falhas ou mal funcionamento do serviço.
Uma sugestão é permitir o recebimento da notificação em ambos os modos: com e sem /pix. Dessa forma, quando virarmos a chave, não haverá problemas.
À medida que se aproximar da data de deploy seremos mais assíduos nas notificações. Quaisquer dúvidas estamos a disposição em nossos canais de comunicação. [ATUALIZADO]
## 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
}
}]
}
Não seria interessante o recebimentoManual poder ser definido como true ou 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
}
}
}]
}
}
"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.
Para já saber exatamente o status da cobrança, e poder tambem consultar o txid confirmando esta mudança de status. Seria um tiro de alerta a mudança de status. Para disparar a validação do recebimento da cobrança em si.
Minha duvida é voltaremos a ter o status da cobrança por opção de recebimento ?