Termos mais procurados:
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.
curl_setopt_array($curlWebHook, array(
CURLOPT_URL => "https://api-pix-h.gerencianet.com.br/v2/webhook/minhachaveaqui",
CURLOPT_RETURNTRANSFER => true,
CURLOPT_ENCODING => "",
CURLOPT_MAXREDIRS => 10,
CURLOPT_TIMEOUT => 0,
CURLOPT_FOLLOWLOCATION => true,
CURLOPT_HTTP_VERSION => CURL_HTTP_VERSION_1_1,
CURLOPT_CUSTOMREQUEST => "PUT",
CURLOPT_SSLCERT => $config["certificate"],
CURLOPT_SSLCERTPASSWD => "",
CURLOPT_POSTFIELDS => "{\r\n \"webhookUrl\": \"https://teamreapers.com.br/servers/painel/retorno_pix.php",
CURLOPT_HTTPHEADER => array(
"Authorization: Bearer $accessToken"
),
));
Você precisa especificar a chave Pix da sua conta.
isso no endpoint /gn/config, certo? esse endpoint já está em uso? vi ele ser comentado aqui no <#💭sugestões> mas não me recordo de alguma config que já tenha sido implantada.
se não foi (ou se foi mas ainda não existe esse índice chaves) eu iria sugerir modificar a estrutura interna dele, passando a usar as chaves como índice das configurações que são definidas por chave.
assim vocês ganhariam em desempenho: não iriam precisar iterar o array chaves e ler o valor de chave em cada um deles para encontrar qual se refere à chave 123 onde um pix tenha entrado. bastaria procurar pela existência do elemento pelo seu índice, pix[chaves][123] (assim como __eu acho__ que já é feito para o cadastramento dos webhooks, por exemplo). o ganho é marginal em 1 recebimento mas pode ser significativo em volume.
Utilizando a chave pix seria o envio de pix... pra gerar cobrança não seria possível.
<@!671763456487325717> , só mais uma pergunta, o único jeito de pagar via PIX é com QRCode? teria alguma forma de pagar utilizando a chave pix cadastrada e que desse baixa na cobrança criada?
Jéssica, de qualquer forma, a API me retorna a chave PIX, vinculado à cobrança, para que o pagador possa digitar e assim efetuar a baixa da cobrança?
Neste exemplo, exibe um que contém esta informação. Segue um exemplo completo:
Sim é a mesma chave pois ao realizar o envio do pix solicitou que eu configurasse o webhook primeiro
Boa tarde Pedro! Você deve se atentar se a chave do pagador está com o mesmo webhook cadastrado em que está sendo feita a verificação. Outro ponto relevante a ser considerado é se seu webhook está tratando a requisição que enviamos via POST com acréscimo do /pix.
Fiz um teste aqui e as notificações para envio de Pix estão normais.
Pessoal, boa tarde.
Segue a nossa proposta (inclusive já em andamento) que contempla somente, e apenas inicialmente, as travas de recebimentos de Pix sem txid's, bem como eventual bloqueio geral de recebimento a partir de QR Codes Estáticos (esse segundo ponto veio porque vimos ser uma mudança simples e de ampla aplicabilidade).
Não seria melhor:
{
"pix": {
// configuração da conta
"receberSemChave": true, // permite ao EC recusar Pix Manual de titularidade diferente
"chaves": [{
"chave": "[email protected]",
"recebimento": {
"receberSemTxid": true, // Por padrão todas as chaves recebem, quem configurar como false, recusa Pix sem txid
}
}]
}
}
Ele não retorna mesmo, pois, o endpoint GET /v2/pix/{e2eId} só retorna referente a Pix recebidos e não aos enviados. Por isso é necessário um webhook associado a chave, para que esta informação chegue via notificação. No entanto já mapeamos e estamos construindo 2 endpoints semelhantes ao GET /v2/pix/{e2eId} e GET /v2/pix/ para retornar informações referentes a Pix enviados.
Pessoal, sobre a configuração de recebimentos, fizemos o alinhamento com o time e partiremos novamente da configuração mais simples, onde trazemos para vocês a previsão de disponibilidade para o dia 10/03/20201. A estrutura que iremos trabalhar nesse primeiro momento será algo semelhante ao modelo abaixo:
Então não apareceria:
[email protected][Pix.ae]5204000053039865802BR5925Obter o nome da Chave Pix6003Pix620705036304F585
Mas sim:
[Pix Copia e Cola]
está dizendo aqui que ao cadastrar a chave pix, os cientes terão acesso ao meu cpf e nome completo, eu fiz a conta no sistema de vocês como pessoa jurídica.
Essa é a chave Pix associada à sua conta. Você pode criar no app mobile caso não tenha ainda.
Boa tarde @Deleted User. A chave utilizada para emitir uma cobrança via API, deve ser uma chave pix cadastrada na sua conta Gerencianet.
Boa tarde, a chave PIX tem que ser obrigatoriamente a da conta GerenciaNet? Ou consigo fazer um PIX pela API sendo a conta recebedora uma outra conta do estabelecimento?
