Histórico de mensagens sobre cobranças em pix

Ola <@!710205440956563536> como estais fazendo? Uma contar centralizadora e na criação das cobranças pix indicas a chave da loja que ira receber?

Boa tarde! Tem como detalhar melhor? No caso, para seu cliente gerar transações para a chave dele, vai ser necessário antes fazer a autenticação com o certificado e com as credenciais dele. Neste cenários você teria que ter acesso a essas informações para gerar as cobranças.

Normal <@!291558720670924801>. Estes registros de transação são para cobranças via boleto e cartão.
Nosso time de desenvolvimento já está trabalhando para disponibilizar estes registros do Pix.

Então fica a sugestão de produto "boleto híbrido"... boleto com barcode e QR-Code, o primeiro que pagar inativa o outro. É inclusive o que vários bancos vão oferecer antes da API Pix. Só que isso combina melhor com as cobranças Pix com vencimento (cobv), então possivelmente não seja ainda o momento de viabilidade.

<@!257617133595262977> Esta chave PIX deve ser mesmo uma chave vinculada à conta Gerencianet. Mas como o Renato citou, as cobranças geradas em Homologação não são pagáveis.

acho que a chave precisa ser real, existente na sua conta GN. mas as cobranças criadas no ambiente de homologação não são pagáveis

eu descobri isso porque vi que tinha nos métodos de consulta, mas faltava no método de criação de 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.

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":[]}