<@!671762828046106646> {#1325
+"nome": "webhook_invalido"
+"mensagem": "A autenticação de TLS mútuo não está configurada na URL informada"
}
Termos mais procurados:
Histórico de mensagens sobre url em pix
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
- Implementação da SDK do Pix em Next.js ou React
- Configuração de URLs para Recebimento de Status
- Acionamento de Webhooks em Pagamentos e Devoluções
- 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
- 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: url
Canal: pix
{
"webhookUrl": "https://exemplo-pix/webhook"
}
curl_setopt_array($curl, array(
CURLOPT_URL => $_ENV["PIX_URL_AUTH"], // Rota base, desenvolvimento ou produção
CURLOPT_RETURNTRANSFER => true,
CURLOPT_ENCODING => "",
CURLOPT_MAXREDIRS => 10,
CURLOPT_TIMEOUT => 0,
CURLOPT_FOLLOWLOCATION => true,
CURLOPT_HTTP_VERSION => CURL_HTTP_VERSION_1_1,
CURLOPT_CUSTOMREQUEST => "POST",
CURLOPT_POSTFIELDS =>"{\r\n \"grant_type\": \"client_credentials\"\r\n}",
CURLOPT_SSLCERT => $arq_certificado, // Caminho do certificado
CURLOPT_SSLCERTPASSWD => "",
CURLOPT_HTTPHEADER => array(
"Authorization: Basic $authorization",
"Content-Type: application/json",
),
));
e a pergunta oposta: quem disse que o PSP deve mandar request pra URL do webhook no momento do PUT? isso não tá previsto. eu poderia configurar o webhook com o PUT sem a URL estar sequer alcancável
A chave que passamos na URL no endpoint pra criar webhook, é uma específica para webhooks ou aquela outra serve??
estranho, o meu nao vai por nada, acho que nao entendi o que voce esta fazendo, meu config do gerar cobranca é assim
> const agent = new https.Agent({
> pfx: fs.readFileSync('./pix/cert/prod280854.p12'),
> passphrase: '',
> });
> const config = {
> method: 'put',
> url: process.env.GERENCIA_URL + 'cob/' + txid,
> headers: {
> authorization: 'Bearer ' + token,
> },
> httpsAgent: agent,
> data: JSON.stringify(data),
> };
>
Aqui eu gero a cobrança:
const requestConfig = await this.getRequestConfig();
return this.httpClient.send(
Object.assign({}, requestConfig, {
method: 'POST',
url: requestConfig.url + '/v2/cob',
data,
}),
);
return this.httpClient.send(
Object.assign({}, requestConfig, {
method: 'POST',
url: requestConfig.url + '/v2/cob',
data,
}),
);
Aqui eu pego o token;
const agent = new https.Agent({
pfx: Buffer.from(this.config.getCertificate(), 'base64'),
passphrase: '',
});
const authConfig: AxiosRequestConfig = {
method: 'POST',
url: this.config.getHost() + '/oauth/token',
headers: {
Authorization: this.credentials.getBasicAuth(),
'Content-Type': 'application/json',
},
httpsAgent: agent,
data: this.credentials.getData(),
};
pfx: Buffer.from(this.config.getCertificate(), 'base64'),
passphrase: '',
});
const authConfig: AxiosRequestConfig = {
method: 'POST',
url: this.config.getHost() + '/oauth/token',
headers: {
Authorization: this.credentials.getBasicAuth(),
'Content-Type': 'application/json',
},
httpsAgent: agent,
data: this.credentials.getData(),
};
Então eu configuro uma URL global para todas as cobranças da minha aplicação é isso?
Para que você seja notificado acerca de Pix recebidos, etc, você deve configurar sue webhook vinculado à sua chave.
Para isso você consome a rota PUT /v2/webhook/:chave, onde chave é sua chave Pix, e passando no body seu webhook:
{
"webhookUrl": "https://exemplo-pix/webhook"
}
Obs: Somente PIX associados a um txid serão notificados. Ou seja, cobranças geradas (atualmente com QrCode dinâmico) com sua chave Pix que possuírem um txid, você será notificado a cada alteração em seu webhook
A url deve ter o certificado SSL para HTTPS, onde foram geradas as chaves pública e privada?
Bom dia, estou desenvolvendo a integração com o webhook da api pix, seguindo a documentação fiz a configuração do NGINX com o certificado de desenvolvimento, entretanto ao configurar o webhook pela api, está retornando o seguinte erro:
json
{
"nome": "webhook_invalido",
"mensagem": "A URL informada respondeu com o código HTTP 403"
}
{
"nome": "webhook_invalido",
"mensagem": "A URL informada respondeu com o código HTTP 403"
}
a url é essa https://api-pix-h.gerencianet.com.br/v2/cob/teste
<@!704694550631022592> Para que você seja notificado acerca de Pix recebidos, etc, você deve configurar sue webhook vinculado à sua chave.
Para isso você consome a rota PUT /v2/webhook/:chave, onde chave é sua chave Pix, e passando no body seu webhook:
Obs: Somente PIX associados a um txid serão notificados. Ou seja, cobranças geradas com sua chave Pix que possuírem um txid, você será notificado a cada alteração em seu webhook
chave => vc cadastra no app. um sistema integrado normalmente só vai usar 1 chave pra tudo.
txid => vc cria um txid para cada cobrança (literalmente você, não a GN). vc escolhe qual deve ser o txid de uma cobrança e cria ela pela API (passando o txid que vc criou + a chave da sua preferência)
a notificação é enviada pra uma URL fixa (vinculada à chave); e a cada notificação recebida você terá a chave + o txid.
Bom dia pessoal! Ainda sobre essa questão.
Eu consegui contornar criando um arquivo .php independente, em outro vhost, embora usando o "mesmo arquivo .conf", alterando apenas o subdominio. A conclusão que cheguei, foi a de que, por meu projeto original ser um framework (laravel), o mesmo se utiliza de arquivos .htaccess pra obfuscar a URL. e de alguma forma, isso interfere no processo de handshake da autenticacão mútua.
Então: Criei outro vhost, com certificado proprio no subdominio, recebendo o POST do webhook da GN, e retransmitindo para meu app principal via requisição post. Isso é provisório enquanto descubro o "ponto de falha" entre o framework e o protocolo mTLS.