Histórico de mensagens sobre dados

No retorno do webhook,conseguimos pegar de alguma forma os dados do pagador?

Pensando na implementação lógica, o fluxo seria mais ou menos esse:

-> se o txid é dinâmico {26,35} a GN valida com base na chave + txid se existe cobrança (talvez isso até já esteja implementado hoje).
-> elseif, txid é nulo, GN consulta a configuração da conta do EC recebedor (ou da chave) se deve acatar Pix com txid nulo.

se a GN tiver como diferenciar quando o Pix foi enviado via "manual" (informando dados bancários) ou com uso da chave DICT, o ideal seria a configuração de aceitar/não os recebimentos com txid nulo ser por chave + uma configuração extra para bloquear todos os recebimentos manuais (que nunca tem txid associado).

se não tiver como diferenciar, a configuração poderia ser global (por conta transacional), com opção de sobrescrever a escolha para chaves individuais (assim poderia bloquear recebimentos com txid nulo para toda a conta [que seria o comportamento padrão] e autorizar o txid nulo em uma chave particular).

e, futuramente:
-> else (txid é estático), valida conforme as regras de aceite do EC (por regex match ou enviando o request de validação para webhookURL/txidmatch, como sugeri acima).

e esse "futuramente" eu não consigo nem ver uma demanda relevante. o importante são as outras funções.

Nesta tabela https://dev.gerencianet.com.br/docs#section-dados-para-gera-o-da-cobran-a o atributo chave está correto?

Bom dia,

Um help rápido. Preciso de saber o número TOTAL de pix recebidos, a consulta é paginada e teria de rodar todas as páginas pra chegar nesse número, tem alguma estratégia pra números consolidados pra report @Efí ?

Já chequei, cliente secret, client id estão conforme os dados lá da minha area restrita do gerenciant.

Tentei alterar apenas os dados do config-pix.php do exemplo passado pelo https://www.youtube.com/watch?v=6Es3i2eH5K4 (obtive os IDs e gerei o arquivo pem seguindo as orientações)

ao tentar pagar usando o que a documentação me indica seção 2.4 para node, estou enviando todos os dados como sao requiridos
Params com o charge_id
{ id: 298279200 }
body
{
payment: {
credit_card: {
installments: 1,
payment_token: '55071f2fd732ce58b0f460dc495912bd0aa8efb9',
billing_address: [Object], // esta igual o exemplo so fiz copiar
customer: [Object] // esta igual o exemplo so fiz copiar
}
}
}
resposta
{
code: 3500010,
error: 'property_does_not_exists',
error_description: {
property: 'payment_token',
message: 'A propriedade [payment_token] informada não existe.'
}
}
oq nao faz sentido, estou requisitando assim
const response = await gerencianet.payCharge(params, body)
esta td devidamente iniciado pois dessa maneira o charge_id funciona normalmente

EM_PROCESSAMENTO é retornado quando os dados bancários e chave estão corretos, mas ainda depende do PSP recebedor se ele vai aceitar ou não a transação, esta resposta definitiva é retornada no webhook.

Boa tarde <@!783359762917752843>, a resposta já vem no momento da requisição, mas o webhook também é acionado com os dados do envio. Você pode configurar sim, mas neste caso o melhor cenário seria ter uma chave para envio de Pix com um webhook e outra chave com o segundo webhook exclusivo para recebimento, pois, cada chave só pode estar associada a um único webhook.

Técnicamente é o seguinte...

- Você cadastra o webhook para seu endpoint "exemplo.com/webhook"
- A GN vai enviar uma primeira requisição para este endpoint sem o certificado, e seu servidor deve RECUSAR
- Em seguida a GN vai enviar outra requisição, dessa vez com com certificado para handshake, mas vai servir apenas para confirmar o PIX gerado, vai enviar um POST com um nome de evento e a data_criacao
- Caso o cliente pagar o PIX, a GN vai enviar uma nova requisição com certificado para handshake para o endpoint mas dessa vez vão adicionar um "/pix" a mais na requisição, ou seja, vai enviar para "exemplo.com/webhook/pix". Você deve deixar este endpoint também disponível e vai receber um POST com os dados do PIX recebido.

https://www1.folha.uol.com.br/mercado/2021/02/banco-central-ainda-nao-se-adaptou-a-lei-de-protecao-de-dados.shtml

Mas a melhor forma para verificar se um boleto foi pago, é recebendo as notificação automáticas. As notificações permitem que você seja informado quando uma transação/boleto tiver seu status alterado para pago, por exemplo.
Para isso, quando criar uma cobrança você irá informar o atributo notification_url, e então a Gerencianet dispara um POST para esta URL a cada mudança no status da cobrança.

Neste POST vai conter apenas uma informação: um token de notificação. Ou seja, se a URL cadastrada estiver preparada para ler o token na variável $_POST['notification'] e consultar essa informação, a resposta será todos os dados informativos sobre a alteração sofrida pela cobrança, como por exemplo, o status anterior e atual da cobrança.

Segue o link com mais detalhes sobre este assunto: https://dev.gerencianet.com.br/docs/notificacoes-recebendo

Bom dia <@!812297338605273098>, respondendo ao questionamento que você fez no 2, sim é possível fazer o envio de Pix de sua conta Gerencianet para uma outra chave/conta via API. Para isto temos o endpoint POST /v2/pix (https://dev.gerencianet.com.br/docs#section-requisitar-envio-de-pix-) que permite o envio para uma outra conta via chave ou dados bancários.
Além disso via API você pode adicionar diversos recursos em seu site como cobranças estáticas e dinâmicas e fazer o controle via endpoints da API. Outro recurso interessante é o webhook que automatiza o seu sistema com os Pix recebidos, sem a necessidade de ter que construir uma rotina que fica realizando consultas na API. Você encontra tudo isso e mais na documentação e caso tenha dúvidas pode mandar aqui canal que te auxiliamos.

<@!715273512688025630> complementando com mais alguns entendimentos:
- A instituição recebedora que aparecerá ao pagador é sempre Gerencianet
- Os dados do estabelecimento do recebedor que aparecerão ao pagador serão: nome fantasia (caso exista) ou razão social.

Importante: não importa o que aparece no BR Code, a informação oficial é a que está no DICT. Ou seja, o correto é que o PSP sempre busque os dados da chave via DICT, ao invés de "confiar" no BR Code. Inclusive, isso é uma questão de segurança. Se o PSP não faz isso, pode acontecer do pagador achar que o pagamento está indo pro A ao invés do B.

Excluir imagem por conter dados sensíveis 🙂

Não, os dados obrigatórios e opcionais você pode encontrar em nossa documentação, detalhados em cada endpoint: https://dev.gerencianet.com.br/docs

e todos esses dados são obrigatórios?

https://www.tecmundo.com.br/seguranca/211303-kabum-corrige-falha-pix-mostra-dados-outros-clientes.htm

Boa tarde <@!671763456487325717> estou precisando de um apoio, não esta vindo no retorno os dados de endereço e preciso dos mesmos pra gerar NFe pra o cliente...sabe me informar o motivo, passamos todos esses dados na geração da cobrança.

Sim, temos os dados completos do veículo.