Histórico de mensagens sobre pagamentos em pix

qual a probabilidade de 30 pagamentos em 1300 (2,3%) serem desses 3 bancos? kkk

se tudo der certo, meu projeto pode ter até 1300 pagamentos em um só mês.. se der problema em 30 já não me compensa mais

no seu cenário, não cabe orientar os clientes que ainda não tem baixa automática nos pagamentos realizados via Cora, Neon e Sofisa?

se bloquear, não vai dar pra saber quando estiver corrigido (e acho que o BACEN veta esse tipo de ação, apesar do erro não ser da GN). e ao que me consta, o correntista da GN que quiser evitar recebimentos sem txid, pode fazer isso programaticamente, devolvendo os pagamentos pela própria API ou pedindo à GN que recuse recebimentos sem txid para uma determinada chave ou para a conta toda

Um testador de pagamentos no modo DEV, para pagar BRCodes. Ai recebo o retorno do webhook e testo, mais rapido , do que ter que entrar em modo produção, abrir aplicativo, digitar ou escanear, colocar senha, pagar, e ter o retorno do webhook para testar, um botao faz isso agora.

O Nubank funciona perfeito nos meus pagamentos

A mesma que já existe hoje. O protesto é do título, não dos meios de pagamentos que ele contém. Pode ter QR-Code, barcode ou ambos.

https://gerencianet.com.br/tarifas/ - Nova página de tarifas. Ficou show!

Só me restaram 2 dúvidas:

1. a GN já notifica os pagamentos de QR estático com txid no webhook? (ainda não tenho cert. de produção, solicitei agora)

2. os recebimentos desses QR estáticos gerados sem a API (mas de forma autônoma, sem usar o App da Gerencianet), também serão gratuitos? A página de tarifas ainda não esclareceu esse ponto, citando apenas especificamente os QR estáticos gerados pelo app:

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!

obs: tem uma função de ler QR na tela principal do PicPay que é só "intra pagamentos" (entre usuários). precisa ir em Pix > QR. lá funciona

Entendi, o meu está no modo produção, pois quando pedi o certificado não me atentei ao ambiente. Quando recebi o certificado de produção decidi testar no modo de produção mesmo, pois controlo quem pode ter acesso a tela de pagamentos via PIX. Daí passei testar com valor de 0,01

Sim, sim, mais ate la, temos que achar uma solução paliativa. pois os pagamentos estão ocorrendo.

<@!543477021221715968> como você está conciliando os pagamentos estáticos?

até o momento, estava concentrado na parte pública do https://pix.ae, a partir de amanhã vou começar a integração para receber pagamentos (para o próprio pix.ae e para outros projetos).

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)

Magno, se vc tá usando hospedagem compartilhada, não vai conseguir resolver isso no chat. Só mandando ticket mesmo. E torcendo muito, pois em hospedagem compartilhada buscam não sair dos padrões. Uma reconfiguração interna qualquer lá que envolva reconstrução dos VirtualHost e sua configuração vai pro saco, aí você vai querer processar a hospedagem por lucros cessantes se a sua loja deixar de receber pagamentos... isso tem que ser configurado em um ambiente cujo responsável seja você (para a sua segurança e segurança do seu host).

Pois é. Se esse problema não for resolvido rápido, talvez eu coloque o meu sistema em produção com uma instrução bem explícita para que ninguém faça pagamentos com o Banco Inter e Sofisa. O problema é que o Banco Inter é muito usado pelos meus clientes

Consegui fazer a implementação da API no meu sistema, mas enquanto não for resolvido esta lista de bancos não vou publicar versão com a opção de pagamento via PIX. Pagamentos via QR Code pelo Banco Inter não dão baixa nas cobranças, pois na GN o pagamento aparece como pagamento via chave Pix e não via Qr Code

o e2eid do Pix já aparece pro pagador no app dele (na tela de confirmação e/ou no comprovante), acho que não tem nada de mais expôr em mais algum local. seria uma forma do cliente "conciliar" seus pagamentos, inclusive

É o plano sim aceitar pagamentos via Pix nos pagamentos que hoje podem ser feitos com boletos. Posteriormente outros serviços que hoje requerem depósitos.