Histórico de mensagens sobre pix em pix

É por questões de compatibilidade com a API do BACEN. De fato não é necessário no arranjo Pix ter chave Pix para envio.

É utilizada uma chave Pix no envio de pix? 🤔

Algo que não é obrigatório mas eu acho recomendável é criar uma chave só para o envio de Pix. Aí você não confunde os webhooks de recebimento de cobrança com os de confirmação de envio.

E corrigindo essa minha mensagem: eu não sou muito familiarizado com Node, mas parece que tem como, sim, validar o certificado da GN usando Node, de acordo com a documentação da GN no link abaixo (tem uma aba "Node" com código de exemplo). Mas não sei se isso é possível num ambiente controlado por terceiros como a Heroku. Em todo caso, o mtls.pix.ae permanecerá sempre gratuito. Boas almas como o <@!535222756837556244> ajudam a financiar 💟

https://dev.gerencianet.com.br/docs/api-pix-endpoints#section-exemplos-de-configura-es-de-servidor

Bom dia! Estou bem, e vc? Sim. E tb já foi liberado pelo comercial o pix.send. Estou testando em modo produção.

Json que envio:
let body = {
'valor': dados.valor,
'pagador': {
'chave': Config.chavePix,
'infoPagador': dados.infoPagador
},
'favorecido': {
'chave': dados.chavePixDestino
}
}

Bom dia! Estou com problemas ao usar o pix.send. Retorna o seguinte erro: {
"nome": "json_invalido",
"mensagem": "Valores ou tipos de campo inválidos",
"erros": [
{
"chave": "required",
"caminho": "",
"mensagem": "deve ter a propriedade obrigatória body"
}
]
}

a menos que vc configure diretamente no seu virtualhost a validação do certificado da GN, você não tem como saber lá no Node se o request veio com o certificado ou não. é aí que entra o mtls.pix.ae. ele se encarrega de rejeitar os requests sem o certificado da GN

usando o mtls.pix.ae o primeiro será respondido com 403 por não ter a chave da GN (não vai nem chegar até você). você só vai receber o segundo (que deve ser respondido com http status 200)

Então eles querem se certificar desde já que você tem controle sobre a validação nos requests que chegam sem o /pix, também, já que isso sinaliza que você poderia receber requests em outros endpois baseados na webhookUrl ( webhookhUrl/pix, webhookUrl/novo-recurso, etc).

<@!535222756837556244> peço desculpas. Revisei a documentação e a GN adiciona o /pix somente nas notificações de transação de fato. No teste de cadastramento vai sem o /pix. Isso porque o BACEN sinalizou que o intuito de adicionar o /pix no fim da URL é permitir outros tipos de notificações/recursos no futuro usando outros endpoints baseados na webhookUrl principal.

E o mesmo comportamento qdo eu prefixo com mtls.pix.ae

log => 2021-06-18T13:17:33.129720+00:00 app[web.1]: rota webhook sem o /pix Request

async webhook ({ request, response }) {
console.log('rota webhook sem o /pix', request)
response.status(403).end()
}

async webhookPix ({ request, response }) {
console.log('rota webhook com o /pix', request)
response.status(200).end()
}

O teste chegou na rota sem o /pix

estranho. faz o mesmo teste cadastrando https://cardapio-api.herokuapp.com/ (sem o mtls.pix.ae). você deve receber o primeiro request de confirmação - que deveria ser respondido pelo seu servidor/app com 403 por não ter o certificado da GN para vc verificar. confere se vem com o append /pix

Mas está chegando em https://mtls.pix.ae/cardapioo-api.herokuapp.com/ sem o /pix

nesse caso vc deve receber um request de confirmação em https://cardapio-api.herokuapp.com//pix

https://mtls.pix.ae/cardapioo-api.herokuapp.com/

<@!440035527127990273> Ao tentar cadastrar o webhookUrl pelo Postman, eu recebo um request sem o append /pix e o erro HPE_INVALID_CONSTANT é exibido na mensagem