coloquei o v2 e continuou o mesmo erro 😦
Termos mais procurados:
Histórico de mensagens sobre erro em pix
PROCURE NO HISTÓRICO
CANAIS DE TEXTO
DISCUSSÕES
- Inserção automática do formato do Pix copia e cola pelo WhatsApp
- Conceito de Payload Locations no PIX
- Consulta de Chave PIX na API de Envio
- Repetição do Processo de Criação com txid
- Endpoint para Recuperar Saldo
- Recebimento de Pagamentos via QR Code e Arduino
- Teste de Status de Pagamento em Ambiente de Homologação
- Implementação da SDK do Pix em Next.js ou React
- Autenticação com Certificado em NextJS
- Implementação do Módulo Gerencianet no Perfex CRM
- Configuração de URLs para Recebimento de Status
- Problemas com Token em Ambiente de Homologação
- Integrações com o Laravel e SDK de PHP da EFI
- Tempo Médio de Análise de Documentos na Abertura de Conta
- Geração de payment_token pelo Postman e teste em homologação
- Interpretação do Campo 'Solicitação ao Pagador' no Webhook GN
- Cobrança em Período de Teste Grátis de 7 dias
- Atualização de informações no Retentiva de Cobrança
- Especificação da URL do Webhook no Exemplo Pix
- Utilização de Endpoints e Payload no Pix
- Retenção de Pagamento no PIX em Marketplace
- Resolução de Delay nas Chamadas de Geração de QR Code e Pix em Node
- Acionamento de Webhooks em Pagamentos e Devoluções
- Funcionamento do Webhook em Ambiente de Homologação
- Cancelamento de Boleto e Remoção do DDA
EXIBINDO CONVERSAS RECENTES:
Texto: erro
Canal: pix
async receive(receiveDto: { value: string, key: string }) {
const token = await this.auth();
const { value, key } = receiveDto;
const data = JSON.stringify({
grant_type: 'cob.write',
calendario: {
expiracao: 3600,
},
devedor: {
cpf: '12345678909',
nome: 'Francisco da Silva',
},
valor: {
original: value,
},
chave: key,
solicitacaoPagador: 'Cobrança dos serviços prestados.',
});
try {
const { data: response } = await this.httpService
.post(${this.GERENCIA_NET_URL}/cob, data, {
headers: {
Authorization: token,
'Content-Type': 'application/json',
},
})
.toPromise();
console.log(response);
} catch (error) {
console.log(error);
}
return true;
}
const token = await this.auth();
const { value, key } = receiveDto;
const data = JSON.stringify({
grant_type: 'cob.write',
calendario: {
expiracao: 3600,
},
devedor: {
cpf: '12345678909',
nome: 'Francisco da Silva',
},
valor: {
original: value,
},
chave: key,
solicitacaoPagador: 'Cobrança dos serviços prestados.',
});
try {
const { data: response } = await this.httpService
.post(${this.GERENCIA_NET_URL}/cob, data, {
headers: {
Authorization: token,
'Content-Type': 'application/json',
},
})
.toPromise();
console.log(response);
} catch (error) {
console.log(error);
}
return true;
}
certo, <@!671762828046106646> estou tendo esse erro: Error: read ECONNRESET ao fazer a requisição
Boa tarde gente! Estou utilizando o laravel e estava tentando fazer a configuração do meu webhook agora, porém ele sempre diz que a url retornou o Status Code 500. Algo específico deve ser retornado para dar certo? Não tem nada na minha função para retornar esse código de erro.
Bom dia, estou retomando o projeto pix após a alteração realizada, mas como tem um tempinho que nao atuo...percebo que o Nubank no meu caso esta dando erro na leitura
@Efí, o erro “A requisição na URL informada falhou com o erro: ERR_TLS_CERT_ALTNAME_INVALID” parece estar relacionado com o certificado da Amazon.
Ele ocorre para os dois cenários a seguir:
Webhook COM mTLS hospedado na Amazon, com certificado HTTPS emitido pela Amazon:
https://mtls.menur.app/vbeta1/establishments/mana/pix
Webhook SEM mTLS hospedado na Amazon, com certificado HTTPS emitido pela Amazon:
https://mtls.api.menur.app/vbeta1/establishments/mana/pix
Entretanto se acessar SEM mTLS com hospedagem no Heroku e certificado Let’s Encrypt o erro que dá é esperado:
https://api.menur.app/vbeta1/establishments/mana/pix
"A autenticação de TLS mútuo não está configurada na URL informada"
E agora? Vocês poderiam verificar o motivo? Obrigado!
Opa, boa tarde, fiz a consulta no endpoint /pix, mas está retornando esse erro. Estou passando apenas os parametros inicio e fim
Pronto. Propagou o DNS rapidão. Agora o CN tá correto. Mas o erro ERR_TLS_CERT_ALTNAME_INVALID continua.
Foi isso que fiz. Mas o erro parece ter sido por uma falha na configuração no DNS. Estou resolvendo isso e dou um feedback aqui.
Olá, @Efí
Ainda na labuta do Webhook em ambiente PaaS. Fiz os seguintes passos e creio estar quase lá:
- Criei uma conta na Amazon para o projeto
- Cadastrei o cartão de crédito
- Provisionei o Amazon API Gateway
- Configurei um custom domain nele
- Configurei o domínio no meu Registrar
- Habilitei o custom domain no API Gateway
- Criei certificado e habilitei o HTTPS
- Baixei o cert webhook da Gerencianet
- Criei uma Trust Store PKCS12
- Coloquei a cadeia da GN lá
- Converti a TS para o formato PEM
- Provisionei um armazenamento Amazon S3
- Subi a TS.pem
- Finalizei a configuração do custom domain
- Ativei o mTLS neste domínio
- Criei uma rota de API para o meu server
- Associei a rota ao custom domain com mTLS
Fui configurando e testando a cada passo. Quase tudo funcionando. A única coisa que não consigo é fazer uma requisição client para testar o mTLS já que não tenho o cert client do webhook.
Então…
- Invoquei o serviço PUT /webhook/{chave} passando no body a url e recebi o seguinte body com o status 400:
{
"nome": "webhook_invalido",
"mensagem": "A requisição na URL informada falhou com o erro: ERR_TLS_CERT_ALTNAME_INVALID"
}
Supus ser algum erro no pem que usei para configurar o mTLS. E já experimentei o seguinte:
- Usei exatamente o CRT que baixei das docs da GN
- Fiz a conversão como citei acima (criando a TS)
Se vocês puderem fazer uma requisição mTLS com o certificado client correto para testar, a UTR é esta:
POST https://mtls.menur.app/vbeta1/establishments/mana/pix
O serviço está retornando 204 fixo para qualquer body json (não obrigatório).
Alguma luz? 🙏
Na verdade a solução seria a mesma. Tanto é que, atualmente, é preciso que seja feita uma requisição antes sem o certificado onde o erro é esperado. Para só então repetir a requisição com os dados corretos. O mesmo poderia ser feito com o secret. A primeira sem o secret e esperar o erro. Depois repetir. Só seria MUITO mais simples de configurar, de implementar, de manter, além de ser mais compatível por ser menos dependente de configuração de ambiente.
Mostrando que dá erro HTTP 500 caso o grant_type seja submetido via content-type: application/x-www-form-urlencoded ao invés de application/json. Por isso a configuração OAuth2 não consegue fazer o Fetch Tokens.
Pessoal, seria possível fazer com que o serviço https://api-pix.gerencianet.com.br/oauth/token aceitasse o content-type: application/x-www-form-urlencoded ? Desta forma evitaria o erro HTTP 500 ao enviar o body grant_type=client_credentials que é mais compatível com REST Clients como o Insomnia e até o próprio Postman na seção de autenticação OAuth2 usando o grant type "client credentials".
Se você tentar fazer essa requisição pelo Postman, provavelmente vai aparecer a mensagem: "A requisição na URL informada falhou com o erro: ECONNREFUSED"
ambiente de homologação
eu faço um get para /loc/:id /qrcode
e recebo esse erro
Unable to read data from the transport connection: Foi forçado o cancelamento de uma conexão existente pelo host remoto..
to usando o exemplo que consta na documentação do postman