Histórico de mensagens sobre PSP em pix

Tentativa de lidar com PSPs que não mandam o txid, talvez ? Bem pensado.

<@!780500321994539068> Eu havia entendido que o EMV e o QR de um dinâmico deveriam conter "" (sem as aspas), mas um PSP disse que entende que não, e está colocando o TxID de 26 a 35 caracteres no campo 62 05 do EMV. Porém, o BRcode impõe limite de 25 caracteres... @ninrod e @dmkamers poderiam confirmar o que vai no EMV e imagem QR de um dinâmico ?

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 situação atual que o BACEN impõe aos PSPs é a seguinte:

toda essa questão de feriados não muda nada pra emissores de cobrança. muda para os PSPs. eles é que vão ter que lidar com o imbróglio todo...

como pode o BACEN obrigar uma determinada funcionalidade por parte dos PSPs para a qual não se tem solução técnica disponível?!

Ah sim, não estou comparando com outros PSPs mas sim com outras features, como a cobrança imediata. Essa já está bem mais resolvida.

E que cá entre nós, vai dar um trabalho cão para os PSPs (como a GN) implementarem... por causa de complexidades decorrentes de requisitos legais.

Agora os meus pesadelos são os PSPs que querem br.gov.bcb.pix ou BR.GOV.BCB.PIX ao invés de aceitarem os dois e com os que não mandam TxID.

o estático tem todas as informações (chave, valor(opcional), descrição(opcional), nome do recebedor(precisa estar presente mas pode ser "Pix"), cidade do recebedor(precisa estar presente mas pode ser "Pix"), txid(opcional).

o dinâmico é associado a uma cobrança gerada via API e só contém o URL de location de onde o PSP do pagador (quando ele ler o QR) vai obter os detalhes da cobrança (outras informações podem estar no QR mas são opcionais e serão descartadas, invariavelmente).

se alguém tiver algum QR dinâmico de outro PSP que não seja a GN eu posso testar. (obs: o MP acabou de atualizar o app, pode ser que estava lendo e parou)

Acho que só em 2022 pra ter algo estável em todos os PSPs kkkk

Na teoria não, mas vai depender de como foi implementado no sistema do PSP, aí faz diferença

Pessoal, o GUI seguindo as normas do próprio Bacen é case insensitive https://gnetbr.com/rkgVpkQdjv . Vamos levar o questionamento ao Bacen informando sobre essas divergências entre os PSPs.

Acho que para quem integra a única coisa é o REMOVIDO x REMOVIDA. A questão de status afeta mais os PSPs pagadores, apesar deles terem colocado em muitas chamadas.

Pessoal, em relação a consulta do Pix em que uns contém o txid e outros não, é referente ao PSP que realizou o pagamento do Pix. Quando o PSP pagador não envia o txid, ocorre essa falha(ausência do txid). Por norma do Banco Central os PSPs tem que enviar o txid e os que não estão se adequando no momento podem até sofrer alguma punição posteriormente.

Esse issue em particular é um que seria bem legal ser equacionado. As mensagens de erro nos PSPs pagadores não ajudam em nada no momento quando uma cobrança está expirada.

E as falhas no qrcodes-pix-h dificultam também a resolução de problemas de interoperabilidade. Um PSP que ainda está recusando GN pediu um código de homologação e eu passei, mas a chance de ter tido problema no download é significativa.

ele é obrigatório, mas o PSP recebedor deve ignorar no contexto do Pix

você não precisa abrir e ler esse URL do payload do seu lado. apenas o banco do cliente precisa conseguir ler um QR que o contenha.. é só colocar ele no QR e dar pro cliente pagar. o meu cenário é específico e eu preciso conseguir ler por estar fora do fluxo que gera/lê o payload "recebedor -> psp recebedor -> psp pagador" (app externo que gerencia os qr codes e precisa ler os detalhes da cobrança como se fosse um app de PSP recebedor para poder montar a página da fatura) (https://pix.ae) -- no ambiente produção tá funcional, então beleza. o problema é justamente a minha clientela que quer homologar a GN e não tá conseguindo. a fatura não abre pq o payload retorna 403 a partir do meu servidor