Histórico de mensagens sobre App

O cadastro das chaves de endereçamento deve ser feito pelo aplicativo.
Para cadastrar suas chaves Pix:
Acesse sua conta pelo app Gerencianet.
No menu lateral, toque em Pix para começar seu cadastro.
Leia as informações que aparecem na tela e clique em Registrar Chave.
Caso esse não seja mais o seu primeiro contato, toque em Minhas Chaves e, em seguida, no ícone (➕).
Selecione os dados que você vai cadastrar como Chave do Pix e toque em avançar – você deve escolher pelo menos 1 das 4 opções de chaves disponíveis (celular, e-mail, CPF e/ou chave aleatória).
Após cadastrar as chaves do Pix desejadas, clique em concluir.

chave => vc cadastra no app. um sistema integrado normalmente só vai usar 1 chave pra tudo.

txid => vc cria um txid para cada cobrança (literalmente você, não a GN). vc escolhe qual deve ser o txid de uma cobrança e cria ela pela API (passando o txid que vc criou + a chave da sua preferência)

a notificação é enviada pra uma URL fixa (vinculada à chave); e a cada notificação recebida você terá a chave + o txid.

é a Chave Pix, que vc cria no app da GN

Bom dia pessoal! Ainda sobre essa questão.
Eu consegui contornar criando um arquivo .php independente, em outro vhost, embora usando o "mesmo arquivo .conf", alterando apenas o subdominio. A conclusão que cheguei, foi a de que, por meu projeto original ser um framework (laravel), o mesmo se utiliza de arquivos .htaccess pra obfuscar a URL. e de alguma forma, isso interfere no processo de handshake da autenticacão mútua.

Então: Criei outro vhost, com certificado proprio no subdominio, recebendo o POST do webhook da GN, e retransmitindo para meu app principal via requisição post. Isso é provisório enquanto descubro o "ponto de falha" entre o framework e o protocolo mTLS.

ou "App deve ler nome no DICT" pra não ficar com aspecto de que é um erro no próprio brcode que eu gero

acho que vou deixar assim pra expor para os clientes que o app tem problemas e forçar os caras a se coçarem

O app da GN poderia suportar links https://pix.ae nativamente: https://github.com/bacen/pix-api/issues/251#issuecomment-761594651

- qual app?
- inválido em que sentido? do ponto de vista do regex previsto pela documentação ( ^[a-zA-Z0-9]{1,25}$ )?

o app do pix, aceitaria um txid invalido ???

C6 já fez um gap analysis do app x manual 3.0 e estão com várias alterações a caminho

curl_setopt_array($curl, array(
CURLOPT_URL => "https://api-pix-h.gerencianet.com.br/oauth/token", // Rota base, desenvolvimento ou produção
CURLOPT_RETURNTRANSFER => true,
CURLOPT_ENCODING => "",
CURLOPT_MAXREDIRS => 10,
CURLOPT_TIMEOUT => 0,
CURLOPT_FOLLOWLOCATION => true,
CURLOPT_HTTP_VERSION => CURL_HTTP_VERSION_1_1,
CURLOPT_CUSTOMREQUEST => "POST",
CURLOPT_POSTFIELDS => '{"grant_type": "client_credentials"}',
CURLOPT_SSLCERT => $config["certificado"], // Caminho do certificado
CURLOPT_SSLCERTPASSWD => "",
CURLOPT_HTTPHEADER => array(
"Authorization: Basic $autorizacao",
"Content-Type: application/json"
),
));

essa recusa que vc recebeu é pq o Itaú tá recusando QR codes "autônomos" que não sejam gerados no app/API deles (no seu caso, com o txid batendo mas com valor diferente, eles recusam da mesma forma)

Esclarecido ai em cima.
O certificado eh do App e não da CC.

Criei o ticket antes de ter essa informação e foi sem o numero da conta e nome do app infelizmente, ticket numero 1791874, caso necessário eu posso criar outro

no app do nubank, diz que ocorreu um erro, tente mais tarde..

eu li no app do bradesco, tá lendo normal..

Essa é a dúvida, isso já ocorre no App da GN.

Boa tarde pessoal. Não sei se já rolou aqui mas é uma dúvida rápida.
Estou gerando o QR dinamico no ambiente de homologação. Mas ao escanear no app da caixa, ele falha pra obter os dados. Em algum lugar li que não é possivel "pagar" uma cobrança feita em homologação. Mas ainda não cheguei ao ponto de pagar. queria apenas validar a integridade do QRCode. Pra isso eu tenho que gerar em produção? Vi também, se não estou enganado, que não é possivel gerar uma cobrança que não seja para o "dono" da conta GN. Então seria este o fator da falha?

o campo infoAdicional é apenas para informação ao pagador, quando ler o QR code, aparecer na tela do app a que se refere o pagamento

eu também acho que essas configurações ficariam melhores no painel (ou até nos apps). uma vez definidas, alterações seriam raras.