Histórico de mensagens sobre n

Notar que não adianta ser sub-domínio, pq o certificado de sub-domínio é publicado no Certificate Transparency. Tem que ser path. (só para quem buscar este conteúdo notar isso)

Só a questão de checar o IP mesmo que não fiz.

Checar a chave Pix do webhook e comparar com a chave da cobrança daquele txid. -> Isso está sendo feito também no servidor.;

Colocar a URL do webhook num diretório não óbvio, tipo api.exemplo.com.br/sduasiduasiduai . Aí quem sabe é pq foi informado pela GN. -> Isso eu fiz pra "AJUDAR" na segurança;

Com o pix.ae especificamente dá para fazer algumas coisas:
- Colocar a URL do webhook num diretório não óbvio, tipo api.exemplo.com.br/sduasiduasiduai . Aí quem sabe é pq foi informado pela GN.
- Checar o IP de conexão para ver se é o IP que você já costuma receber.
- Checar a chave Pix do webhook e comparar com a chave da cobrança daquele txid.

Com AWS dá pra fechar melhor, sim, mas dá para mitigar um pouco via pix.ae mesmo.

Mas como o prazo de liberação estava estourado e o negócio não funcionava de jeito nenhum, liberei assim para que assim que encontrasse uma solução, implementasse

Essa validação que não tem como fazer, fica um furo de segurança.

Mas pelo menos deu para decifrar o mistério... como você está conferindo se é o pix.ae mesmo ?

Obrigado Rubens, mas liberei o projeto usando o PIX.ae mesmo.

Boa tarde, @.antoniogregorio. A mensagem de retorno contida na documentação estava desatualizada, o correto é retornar o segundo json mencionado por você.

Nomes DNS não podem ter _

@Consultoria Técnica sabem se não é possível utilizar subdomínios como callback?

Enquanto isso não melhorar, talvez fazer um /v2/gn/saldo ? Aí você sabe se a causa foi essa.

o que me deixa incapaz de verificar o erro correto pelo nome, me forçando a verificar pela mensagem