Histórico de mensagens sobre cobranças

Você conseguiu receber a parte que informa a lista de cobranças contendo o txid e e2eid ou nem isso?

<@!671762828046106646> não tem um jeito de vcs oferecerem o ambiente completo em homologação? Não conseguimos enviar callbacks para o ambiente webhook no ambiente de homologação, o que impede testes pra validar o setup mTLS, por exemplo. Eu preferiria não ter que mexer no ambiente produção antes de certificar que o ambiente de homologação funciona. Da forma como está hoje, o ambiente de homologação é bem pouco interessante, pois a criação de cobranças sem possibilidade de testar os callbacks vindos diretamente da GN não tem muita serventia.

No retorno das consultas de cobranças vem no formato array mesmo. Só no exemplo do callback do webhook que notei que tinha um objeto no lugar do array

No callbacks está diferente a resposta mesmo, vou alterar. Estava verificando o exemplo de consultar lista de cobranças

No retorno que você enviou o devolucoes não está como um array, nesse caso sugiro fazer a correção. Na documentação em consultar lista de cobranças tem um exemplo da resposta com o devolucoes utilizando um array.

O problema é que todos os testes possíveis hoje no ambiente de homologação não incluem liquidação de cobranças.

Bom dia <@!257617133595262977>, se você esta se referindo à Api Pix, é necessário o certificado sim. Se for utilizar nossa API para gerar cobranças do tipo boleto ou cartão, por exemplo, não é necessário o certificado. Como o Renato mencionou, se não estiver relacionado ao Pix, você só precisa do par de chaves client_id e client_secret.

Boa noite. Você se refere à API Pix? Ela, sim, precisa de certificados (mesmo em homologação). A API principal de cobranças da GN (para boleto e cartão) só precisam do token e/ou do par de credenciais (Client_ID e Client_Secret), pelo que eu pude ver no SDK: https://dev.gerencianet.com.br/docs/instalacao-sdk-php

Mais não precisa ser várias cobranças de 10.000 , é só gerar uma de muitos milhões mesmo, como não tem limite, kkkkkkkkkkkkkkkkkk.

fique rico: gere várias cobranças de 10.000 e pague com 0.01 via Ame.

Como mencionado pelo Rubens, no momento, não tem como simular o "pagamento" de uma cobrança. Sugerimos realizar em produção com cobranças no valor de R$0,01

agora é gerar cobranças em produção (e com elas, vc não terá problema de forbidden, o qrcodes-pix não tem o problema de acesso restrito que o qrcodes-pix-h tem)

Boa noite. Quero propor uma mudança no Art. 1º da Lei 7.089/1983 (http://www.planalto.gov.br/ccivil_03/LEIS/L7089.htm). Ele determina que títulos com vencimento em sábados, domingos e feriados podem ser pagos no primeiro dia [útil] subsequente sem juros de mora.

Os PSPs (prestadores de serviços de pagamento) que estão implantando o recurso de cobranças Pix (com vencimento, regras de multa/juros, etc, similar a um boleto registrado) estão com uma dificuldade absurda de implantar isso por causa dessa lei.

A minha proposta é que a redação da lei seja atualizada para o que ela efetivamente propunha em 1983: que os títulos possam ser pagos no primeiro dia útil subsequente ao vencimento quando da impossibilidade de fazê-lo por indisponibilidade do meio de pagamento (ex: bancos simplesmente não podem acatar o pagamento de boletos aos fds/feriados pois não há processo de compensação nestes dias). O Pix é diferente e funciona 24/7/365.

Se a lei for alterada, quem gerar cobranças com possibilidade de pagamento por Pix + boleto, se o pagamento cair num feriado, o boleto continuaria pagável no dia útil subsequente sem juros. O Pix, no entanto, está disponível nos feriados normalmente, então se a cobrança for paga especificamente por Pix no dia útil subsequente ao vencimento, seria cobrado 1 dia de juros normalmente (em outras palavras: o conceito de dia útil/não útil deixaria de valer para o cálculo de juros no Pix - e qualquer outro meio de pagamento 24//7/365).

Pode parecer um retrocesso para o consumidor, mas simplesmente não existe um banco de dados com os feriados municipais de todo o país disponível de forma pública. Somente fontes não oficiais, pagas, que dificultam enormemente a gestão das cobranças e o correto acolhimento dos pagamentos por parte dos PSPs que trabalham com o Pix e encarecerão o uso do Pix para os PSPs e para as empresas, que repassarão esse custo para o consumidor. Detalhes: https://github.com/bacen/pix-api/issues/225 . Obrigado!

a questão é que cobranças assim, o cliente ja esta ciente e tem que pagar, se ele abrir a fatura na segunda, gera nos conforme

Simulando o seu cenário, o retorno é um array "cobs" vazio. Veja o resultado da consulta da página 3 em uma consulta que tem páginas 0, 1 e 2 (21 cobranças com 10 cobranças por página) => {"parametros":{"inicio":"2020-11-24T16:35:39.000Z","fim":"2020-12-05T16:35:39.000Z","paginacao":{"paginaAtual":3,"itensPorPagina":10,"quantidadeDePaginas":3,"quantidadeTotalDeItens":21}},"cobs":[]}

caso não tenha + de 100 cobranças só mudar o valor total da paginacao tmb...

O cenário é: se tem 101 cobranças, deveria aparecer duas páginas, caso o total por página seja 100

<@!255777388829343745> se você perdeu mais cedo, https://youtu.be/6Es3i2eH5K4 esse vídeo saiu hj 20h e detalha como criar cobranças com a API da GN (vídeo inicial: https://www.youtube.com/watch?v=eO11iFgrdCA). Se travar em alguma parte com SDK da GN, esses vídeos podem te ajudar.

Não sei até que ponto é preciso e disponível, mas achei uma API de feriados:
http://www.calendario.com.br/api_feriados_municipais_estaduais_nacionais.php

Para as cobranças com vencimento, uma infeliz necessidade...

um txid pode ter múltiplos e2eid quando você receber múltiplos pagamentos para um mesmo txid (cenário mais comum no caso dos qr codes estáticos, não associados a cobranças)