Histórico de mensagens sobre cobrança de api em pix

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.

Bom dia, <@!624237116238594078>. Como vai?
Exatamente conforme mencionado pelo <@!780500321994539068>

Para utilizar a integração com o Pix é necessário ter um PSP. Sendo assim, criando sua conta na Gerencianet, você terá acesso à API Pix da Gerencianet, que lhe fornece os endpoints no contexto do arranjo Pix, como criação de cobrança, verificação de Pix recebidos, devolução e conciliação.

Com sua conta criada, acesse nosso site, no menu API > Minhas aplicações você criará uma aplicação que são gerados 2 pares de chaves Client_Id e Client_Secret, sendo um par para utilização em ambiente de Produção e outro para Homologação. Estas credenciais que você utilizará para a autenticação.

Para utilizar a API PIX você precisará também de um certificado gerado por nós. Para isso basta acessar o link https://sistema.gerencianet.com.br/tickets/criar, e criar um ticket solicitando o certificado para integração, informando o número da sua conta, nome da aplicação e ambiente que irá desenvolver (produção/homologação).

Nesse caso a primeira (sem txid) não seria tarifada, entende-se como cobrança manual. Lembrando que nesse caso não envolve nenhum fluxo de API.
Pro segundo caso (com txid) será tarifado.

e a outra, sobre os recebimentos por meio da chave Pix (não associados a cobrança) serem ou não tarifados, que não fica claro na página de tarifas (como já falei diversas vezes, não existe esse negócio de "Pix recebido pelo app"... o Pix é recebido pela conta transacional, não "pelo app" ou "pela api").

- Toda cobrança tem expiração, se o atributo não for inserido o valor default vai ser o 86400 (segundos)
- Sim, uma cobrança dinâmica pode ser alterada via API sem afetar o QRCode gerado

chave => vc cadastra no app. um sistema integrado normalmente só vai usar 1 chave pra tudo.

txid => vc cria um txid para cada cobrança (literalmente você, não a GN). vc escolhe qual deve ser o txid de uma cobrança e cria ela pela API (passando o txid que vc criou + a chave da sua preferência)

a notificação é enviada pra uma URL fixa (vinculada à chave); e a cada notificação recebida você terá a chave + o txid.

<@!704694550631022592> Bom dia!
Não se preocupe, este canal é mesmo para tirar suas dúvidas! 😉
Primeiramente, para quaisquer consumo dos endpoints do Pix, é necessário realizar uma autenticação com suas credenciais client_id, client_secret e certificado. Para isso, seu primeiro consumo será na rota POST /oauth/token. Segue exemplos em algumas linguagens: https://dev.gerencianet.com.br/docs/api-pix#section-exemplos-de-autentica-o-utilizando-o-certificado-p12

Após a autenticação, você utilizará o endpoint para criar uma cobrança PUT /v2/cob/{txid}. Documentação: https://dev.gerencianet.com.br/docs/api-pix#section-criar-cobran-a-

Para acompanhar as mudanças de status de um pix, você pode configurar um webhook, que reúne endpoints para gerenciamento destas notificações. https://dev.gerencianet.com.br/docs/api-pix#section-webhook

Utilize também nossa Collection da Gerencianet com todos os endpoints já configurados para o consumo (https://dev.gerencianet.com.br/docs#section-collection-postman-gerencianet-api-pix).
A respeito do seu certificado, logo lhe retornaremos através do ticket.

Isto <@!558328193438973972>. Só podem ser pagos Pix que forem gerados em produção
Sugerimos utilizar em produção com cobranças de baixo valor. Até o dia 30/04/2021 não haverá cobranças pelo consumo via API

Mas para isso teriam que mudar a política de cobrança, pois a tabela de tarifas precifica recebimentos gerados via API, mas não mencionam recebimentos gerados fora da API

<@!375094642238029824> , a API da GN só gera cobranças (que vc representa com qr dinâmicos para o devedor escanear/copiar e pagar). QR codes estáticos são gerados no aplicativo do banco do recebedor ou por você, de forma autônoma (sem API alguma).

e só dá pra gerar cobranças para chaves na sua conta, mas QR codes estáticos (independentes de API) vc pode gerar pra qualquer conta

Há uma anomalia no endpoint /v2/pix para o método "Consultar Pix recebidos".
Estou filtrando algumas cobranças para analisar os pagamentos e está acontencendo o seguinte:
Ao filtrar os PIX recebidos em um determinado período, a API informou um total de 16 pix recebidos.

Os status das cobranças da API-Pix são os mesmo definidos pelo BACEN. Os status da API para boleto e cartão são diferentes e também estão definidos em nossa documentação.

a API de geração e de baixa de cobranças Pix, existe. e programaticamente, dá pra "baixar" ou cancelar boletos pela API, também. então de alguma maneira, dá. mas não como uma solução pronta. tem que desenvolver em cima das duas API e fazer funcionar como você quer

na verdade, a opção que sugeriram acho que era baseada na pré-existência de uma cobrança (ou seja, a conta ficaria limitada a receber apenas QR dinâmico). mas eu insistiria na opção de barrar qualquer coisa sem txid e continuar recebendo estáticos. que ainda podem ser úteis em alguns cenários, mesmo pra quem tem sistema com a API implantada.

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!

será que eles vão tarifar os recebimentos com qr estático? achei mal explicada essa questão. um QR que eu gero pelo app (estático e que pode, inclusive, ter txid) e um QR que eu gero por uma ferramenta externa, não diferem em nada tecnicamente. então fica difícil saber se enquadra no "receber via app" da tabela de tarifas (que seria gratuito) e, ao mesmo tempo, também não se enquadra no "Pix via API" da tabela, pois o recebimento em si não se dá pela API (nem no caso das cobranças, só a geração delas é pela API).

também deveria ser modificada a nomenclatura: "tarifa por pix pago", quando na verdade pagamos por receber, não por pagar. (observe que as tarifas de cartão de crédito estão definidas como sendo "de recebimento", adequadamente).

e por fim, não gostei da "escada" de tarifas, com vários degraus. um pix de R$ 3,00 paga R$ 0,06 (R$ 2,94 líquido) e um de R$ 3,01 paga R$ 0,20 (R$ 2,81 líquido).. atrapalha totalmente o cenário de micro-transações (receber menos quando se vende mais caro, não faz nenhum sentido). acho que a tarifa poderia ser simplificado como "X%, com mínimo de R$ 0,01 e máximo de R$ 0,89". continuaria progressivo e nos daria uma flexibilidade adequada na estipulação dos preços para micro-transações. com base nos R$ 30,00 do valor da tarifa máxima (R$ 0,89), esses X% seriam 3% (mas se for menor, melhor! rsrs)

Vamos lá... Primeiro solicitamos o token com as nossas credenciais dadas pela GN. Depois geramos a cobrança. Depois geramos o BRCode. Informamos via api Webhook a GN a nossa url de retorno de mudança de status da cobrança. A GN envia o retorno para esta url cadastrada, o seu sistema valida o retorno e da baixa na cobrança. Em resumo é assim, na prática precisa de um mestrado, uma especialização e um doutorado na criação destes passos em cada linguagem. Estudando aqui. Estou falando em modo produção.

Ok, vamo lá.
- Primeiro, ao pagar os QRCodes Gerados em produção, percebi que apenas QRs pagos no Nubank exibem o txid na tela e quando o pagamento é efetuado e consulto a cobraça, muda corretamente o status da cobrança para CONCLUIDA
- No entanto, quando faço pagamentos pelo banco Inter ou Sofisa, eles simplesmente ignoram o txid (não exibem na tela de confirmação) e quando é pago consequentemente não muda o status da cobrança para CONCLUIDA, o status permanece ATIVA
- Uma das hipóteses desses 2 bancos não estarem considerando o txid pode ser o fato de que o txid padrão criado pena GN tem no mínimo 26 caracteres e segundo a documentação do banco central deve conter de 1 a 25
- Outra hipótese é erros do próprio banco psp pagador que não está considerando o txid porém, seria válido testar também a outra hipótese
- Como a API de gerar cobrança da GN não permite criar cobranças com txtid com caracteres abaixo dos 26 eu como desenvolvedor não consigo testar

Se está tudo ok em sua integração, solicita via ticket o certificado de produção que você consegue realizar os testes, com cobranças de R$0,01 por exemplo. Lembrando que antes de 16/01/2021 não há cobranças na API Pix.