Histórico de mensagens sobre pix

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

resumidamente, o proxy mtls.pix.ae "derruba" a necessidade de você se preocupar com mtls. se quiser uma garantia de o request entrante é da GN, você tem alternativas:

1- enviar um request de consumo na API Pix da GN pra constatar a informação recebida;

2- anotar o IP usado pelo pix.ae nos requests que recebe e depois validar se estão vindo sempre desse mesmo IP;

3- usar uma rota com uma string aleatória menos previsível do que "/webhookpix" (e não torná-la pública).

no momento eu só não estou tratando timeouts absolutos do seu lado (site totalmente off do seu lado e sem uma cdn ou load balancer pra responder 502, por exemplo). eu vou responder 200 mesmo, depois de uns 10 segundos. pra evitar sobrecarga no servidor do pix.ae com retentativas que provavelmente seriam frustradas de qualquer forma. de resto, tudo que vc responder, eu repasso pra GN.

não precisa retornar nada. a resposta http padrão é 200. só se você responder algo diferente (mandar um header 503 por ex), o mtls.pix.ae vai repassar o mesmo status (pra indicar que eles precisam retentar a notificação mais tarde), por exemplo

Devo retornar a string 200 ou isso é feito pelo pix.ae?