Histórico de mensagens sobre cobranças em pix

Bom dia! Tudo bem? Exatamente. Todo cliente que emitir cobranças Pix precisará enviar as credenciais de acesso e o certificado (gerado na conta Efí) para autenticação na API

Não, não tem painel com as cobranças. Parece o tipo de relatório a se fazer internamente, não ?

As cobranças são criadas através do endpoint /v2/cob

Boa noite, pessoal! Ao gerar uma cobrança via Pix, há algum painel que eu possa ver todas estas cobranças geradas? Exceto via API que eu consigo consultar atualmente.

Perdão!
Devo ter me confundido.
Estou precisando do retorno das cobranças que irei gerar.

Você pode testar o fluxo do webhook Pix emitindo cobranças entre R$ 0,01 e R$ 10,00

boa noite, alguém pode me informar se, na api pix (cobranças imediatas) o NOME e CPF do devedor, passados no objeto para criar a charge DEVE ser os mesmos de quem vai efetuar o pagamento ?

Para consultar, você pode utilizar o endpoint de Consultar lista de cobranças(GET /v2/cob) passando um período como filtro. Ele te dará todas as informações dos Pix ja gerados, e pelo sttaus você consegue saber se ja foi pago ou não. Ou você consultar pix já recebidos (GET /v2/pix) passando um período como filtro.

O CPF/CNPJ não é um atributo obrigatório em casos de cobranças Pix, porém, se enviado o atributo devedor, deverá necessariamente enviar o nome e documento.

Oi, @admthunder. Bom dia! Tudo bem?
No link de visualização da cobrança Pix, sempre mostraremos o endereço. Se o endereço comercial não estiver ativado em Configurações de conta > Configurações de cobranças > Dados de exibição, será exibido o endereço cadastrado na conta.

Mas é a mesma coisa. Diferente da API de Cobranças, no webhook a notificação tem os mesmos dados que se pode obter no GET de /pix. Mesmo objeto, mesmos campos, mesmos tudo.

A ideia é esta mesmo, @alissonmaciel_32335. Você irá utilizar este endpoint PUT/v2/webhook/:chave para associar sua URL de notificação a sua chave Pix. E então as cobranças Pix que tiverem um txid e sua chave Pix, nós iremos enviar a notificação para a URL registrada. Essa configuração pode ser feita uma única vez.

Pontuando que para registrar sua URL de notificação, é importante que seu servidor tenha algumas configurações para atender a comunicação com mTLS para segurança da sua aplicação. Você encontra mais detalhes em nossa documentação e nos vídeos a seguir: https://dev.gerencianet.com.br/docs/api-pix-endpoints#webhooks
https://youtu.be/hdyUHzNwVLY?list=PLRqvcUTH2VsWufBmzOdTVeLEOTGrPNoiu
https://youtu.be/XB9bcZFTV3M?list=PLRqvcUTH2VsWufBmzOdTVeLEOTGrPNoiu

Então se você passar https://exemplo.com.br , o teste durante a ativação vai ser feito para https://exemplo.com.br, e os Pix efetivamente virão para https://exemplo.com.br/pix .

E isso você pode ver em homologação também, criando cobranças de até R$ 10 que depois de alguns segundos geram requisições no webhook como se tivessem sido pagas.

Quando você ouve alguém dizer "meu Pix é ..." o que vem depois é a chave Pix. Para geração de cobranças Pix o mais interessante é usar a chave aleatória exatamente por ela não poder sofrer portabilidade.

Dessa forma na maioria dos casos, onde há 1 elemento você não terá nenhuma falha e nem nos casos onde houver mais de 1 elemento.
Mas reforço que essa é apenas uma medida de segurança, acredito que se você lidar com apenas o primeiro item não irá ter quaisquer problemas, uma vez que não houveram relatos de acontecimentos como esse por aqui (2 cobranças na mesma notificação)

A gente cria milhares de cobranças Pix por dia e não temos notado problemas...

e acabei de verificar as cobranças que criei tem uma do dia 27 q ainda tá ativa

Boa tarde, tudo bem? As notificações da API Pix funcionam de maneira diferente da API de cobranças. No caso do Pix, você cadastra um webhook para sua chave e, toda vez que houver um recebimento, uma notificação será enviada para esse webhook que foi cadastrado anteriormente

Boa tarde @guilhermeoliveira91! Tudo bem? A quantidade maxima de cobv que pode ser emitida em lote são 200 cobranças.

A diferença do endpoint PATCH para o endpoint PUT, é que o PATCH admite um array cobsv com menos solicitações de criação ou alteração de cobranças do que o array atribuído na requisição originária do lote.