Histórico de mensagens sobre pix

Neste caso não, pois mesmo que você não veja, está sendo gerado com o txid.
Sendo assim, estes PIX associados a um txid serão notificados em seu webhook.

Mas a melhor forma é acionando o webhook com um Pix pago.
Ou seja, você criará uma cobrança com um txid com sua chave Pix. E ao pagar será acionado seu webhook lhe enviando uma requisição semelhante ao exemplo que mencionei anteriormente.

Você pode criar uma request no Postman, com método POST para sua URL webhook, enviando o certificado para mTLS e body, um exemplo de um Pix pago:

Para que libere o a utilização do endpoint envio de Pix (POST /v2/pix) é necessário entrar em contato com a nossa equipe comercial por qualquer um dos canais oficiais (https://gerencianet.com.br/artigo/entrar-em-contato/) e assinar um termo contratual. Mais detalhes sobre o termo vocês conseguem com a própria equipe comercial.

obrigado, realmente nao achei o valor do pix para transferencia bancária

//Para habilitar o end-point pix/enviar é necessário entrar em contato
//com a equipe Comercial da Gerencianet para novo anexo contratual.

Qual seria a seguência para conseguir enviar pix dinâmico pela Gerencianet?]

Pode me ajudar a entender a API Pix <@!775350441965649951> ?

Olá Pessoal, boa tarde!
Beixei a SDK php para fazerum teste mas estou passando por problemas com o certificado. Erro abaixo:

Fatal error: Uncaught Error: cURL error 58: could not load PEM client certificate, OpenSSL error error:0200100D:system library:fopen:Permission denied, (no key found, wrong pass phrase, or wrong file format?) (see https://curl.haxx.se/libcurl/c/libcurl-errors.html) in /var/www/localhost/htdocs/gerencianet/examples/pix/oauth/generateAuth.php:29 Stack trace: #0 {main} thrown in /var/www/localhost/htdocs/gerencianet/examples/pix/oauth/generateAuth.php on line 29

Boa tarde, <@!816096457361981490>!
Isto ocorre quando a requisição para a criação da cobrança retorna algum erro. Verifique as credencias, certificado e ambiente que está utilizando.
Você pode dar um var_dump na variável $dadosPix para saber o que retorna da função emitePix()

Implantei hoje a integração da minha plataforma para os clientes pagarem com Pix, dando baixa direta nos pedidos. Tudo foi muito bem, exceto por uma coisa estranha com o Bradesco. Os clientes que tentaram pagar o Pix Copia e Cola pelo Bradesco receberam a mensagem: “não foi possível ler o código”. Com todos os outros bancos funcionou perfeitamente. Alguém já teve este mesmo problema?

De um exemplo da <@!671763456487325717> :

{ "pix":
[ { "endToEndId": "E29236120202103041739s0349633KVD",
"txid": "4dsaa337777a4a479ef8005eea80e097",
"chave": "1a5806f6-74ba5-4d81-ba73-aff8f87327f7",
"valor": "0.01",
"horario": "2021-03-04T17:39:50.000Z"
}
]
}

o body que eu vou receber seria isso: $body = $_POST['pix']; ?

GN boa noite tudo bem? qual a taxa (ou valor) que a GN esta cobrando para fazer pix por API?. Eu preciso fazer pix por api (da minha conta GN para terceiros).

Entendi. Então você tá apoiando por que é melhor pro EC e por que vai na linha da API do BACEN, apesar da minha sugestão ter sido motivada, principalmente, pela economia de recursos da GN para processar os dados em um formato que tenha as chaves pix como índice. Apenas motivações diferentes.

é muito mais legível uma estrutura assim:

Você achar mais "entendível" um objeto não ter o seu identificador (a chave Pix) como índice e ser um elemento interno / propriedade do próprio objeto, só demonstra que você está aplicando um argumento válido (o formato deve ser entendível para quem vai consumir a API, concordo) num local onde ele não faz sentido (o formato que escolheram não é o mais entendível e não é prático de se trabalhar, mesmo do ponto de vista do EC).

A minha preocupação foi 0% em relação ao EC. Foi 100% do lado da GN em relação ao desempenho que ela vai ganhar não precisando iterar esse array em todo recebimento. Todo array que depende de um loop que o percorra para que seus elementos internos sejam identificados (e condicionantes sejam aplicadas) é um array "burro". O identificador deve ser a chave do elemento, sempre que possível. Verificar se pix[chaves][123] existe não exige que eu leia todos os elementos em chaves (e muito menos todos os seus valores internos). Ganha-se absurdamente em velocidade e em consumo de memória - e isso mesmo quando só houver 1 elemento no array. Um teste array_key_exists() tem um processamento ínfimo perto de qualquer tipo de loop. Isso pode ser comparado à uma busca em banco de dados em diferentes colunas, uma com índice e a outra sem.

quando vocês irão concertar o código do pix copia e cola que aparece todo bagunçado quando o cliente compra pelo celular?

Hoje eu só vi reclamação de Pix no Itaú não estar funcionando, mas até aí isso é um dia normal no sistema financeiro.