Histórico de mensagens sobre App em pix

e a outra, sobre os recebimentos por meio da chave Pix (não associados a cobrança) serem ou não tarifados, que não fica claro na página de tarifas (como já falei diversas vezes, não existe esse negócio de "Pix recebido pelo app"... o Pix é recebido pela conta transacional, não "pelo app" ou "pela api").

pensa no fluxo de envio através do app. você não escolhe a chave que tá enviando o pix

Aí o servidor HTTP que você colocar para ser o application server só pode atender na loopback (127.0.0.1). Aí externamente só funciona o acesso via HTTPS.

const config = {
method: 'put',
url: https://api-pix.gerencianet.com.br/v2/webhook/${pixkey},
headers: {
Authorization: Bearer ${token},
'Content-Type': 'application/json',
'x-skip-mtls-checking': false
},
httpsAgent: this.#agentPix,
body: {
webhookUrl: 'https://meucallback/api/pagamento/pix/callbackPix'
}
};

<@!781937354507943938> tive este mesmo problema teu só que uso a biblioteca WebRequest do C#


ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12 | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls;

var httpWeb = (HttpWebRequest)WebRequest.Create(Autenticacao._Host + "/v2/pix");

httpWeb.ClientCertificates.Add(Autenticacao.Servico.GetCertificado());
httpWeb.ContentType = "application/json";
httpWeb.Method = "POST";
httpWeb.Headers.Add("Authorization", "Bearer " + Autenticacao.Servico.GetToken());

O onboarding é similar a de outras contas digitais: cadastrar no app, mandar documentos, confirmar celular/e-mail, foto etc. Não há custo de setup nem para a conta nem para a API Pix.
Pela experiência que vejo aqui no grupo em alguns dias é usual já ter passado por todos os passos, mas vale checar se as atividades dos clientes não colidem com a lista do item 9.4 de https://gerencianet.com.br/termos-de-uso/

Bom dia a todos! No app do PagBank quando vou fazer um pix para um cpf e esse cpf não é uma chave pix, recebo uma mensagem dizendo "A chave da pessoa que você quer transferir não existe", como é feita essa validação?

Pois é, não ter na API mas ter no app e no CNAB 750 é uma incongruência que já foi apontada ao BACEN, mas baixou o ativismo LGPD por lá.

curl_setopt_array($curl, array(
CURLOPT_URL => $_ENV["PIX_URL_AUTH"], // 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 =>"{\r\n \"grant_type\": \"client_credentials\"\r\n}",
CURLOPT_SSLCERT => $arq_certificado, // Caminho do certificado
CURLOPT_SSLCERTPASSWD => "",
CURLOPT_HTTPHEADER => array(
"Authorization: Basic $authorization",
"Content-Type: application/json",
),
));

<@!788954143658082304> valeu, mas isso não muda a ideia de que eu preciso ter um ambiente em pé para receber a notficação do api gateway mesmo ele servindo só como um bypass pro meu app, porque se o o GN manda a notificação para o api gateway eu ainda teria que receber um callback de la pra fazer alguma mudança no meu db e não é possivel localmente, faz sentido?

Aqui eu pego o token;

Normalmente é enviado instantaneamente <@!788954143658082304>.
É feito um POST, então em seu servidor deve ter esta app route, assim como em nosso exemplo: https://dev.gerencianet.com.br/docs/api-pix#section-exemplos-de-uma-configura-o-de-servidor-
A seguir um exemplo do que é enviado no caso do enviar PIX:

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.

- 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"
),
));