Histórico de mensagens sobre PSP em pix

$MMHospedagem_PSP_Api->DevolverPagamento($ID_Transacao[1],MMHospedagem_Pix_ID_GerarTransacao(10,'333'),$MMHospedagem_PSP_requisicao);

Segue sugestão de EMV/BRCode para dinâmico:

00:01 (versão)
01:12 (uso único)
26 00:br.gov.bcb.pix (em minúsculas pois é o que parece dar menos problema de não reconhecimento)
26 25:qrcodes-pix.gerencianet.com.br/v2/6387cb2c8dd94ca6b1349f9e825a83e8 (location obtido do PSP, hostname em minúsculas, path conforme PSP)
52:0000 (mcc)
53:986 (reais)
54:"40.00" (ou o valor da fatura em questão, parece útil em alguns PSPs para evitar edição de valor)
59:"Meu Estabelecimento" (é mostrado indevidamente por alguns PSPs)
60:"Sao Paulo" (sem acentuação)
61:"01000000" (CEP sem o -)
62 05:"" (TxID de dinâmico vem no payload)
63:CRC

a data de criação é inferida pelo PSP com base no momento que recebe seu request. não é você que determina "criei ontem" ou "vou criar amanhã". passe apenas a expiração no PUT.

O BACEN emitiu um esclarecimento disso aos PSPs, mas não vi o inteiro teor.

como a GN é um PSP voltado à integrações, por decisão, escolheram não exibir no app a informação

se coisas muito mais básicas não estão funcionando, eu arrisco que isso tá funcionando em 10% dos PSPs ainda

Como a informação de pagador não é mostrada, uma possibilidade seria o PSP pagador usar isso para controle de anti-fraude do lado dele. Se algum está de fato usando, difícil saber... meu palpite é que não.

realmente. é um problema desses PSPs que deve ser corrigido em breve. aí é só pesar, se compensa aumentar um pouquinho o QR pra ter o dado efetivo do nome do recebedor ou não.

Mas, é mostrado por PSPs que não leram direito o manual...
https://github.com/renatofrota/pix-pendencias/issues/2

E o acentuado em "Número" pode dar enrosco. Nem todo PSP está seguindo UTF-8.

(EndToEndId) É um identificador único de cada cobrança, gerado pelo PSP e transmitido durante a operação de consulta)

A pacs.008 é a mensagem XML que transita entre PSPs e BACEN. Mas a sintaxe da API Pix é distinta.

E fica a sugestão de mudar o GUI para br.gov.bcb.pix , por causa de PSPs que não leram a frase "case insensitive" no manual.

Mais um pra lista dos PSPs que não enviam txid: SuperDigital.
https://github.com/renatofrota/pix-pendencias/issues/21

Mas a "boa" notícia é que eles não aceitam QR dinâmicos.
Então só aceitam estáticos, e se tiver txid, não passam o txid adiante.
Prejuízo zero pra quem vai operar com QR dinâmico.

só tem 3 PSPs que não estão enviando o txid no momento: Cora, Neon, Sofisa. Muito pouco utilizados. (e o Neon fica mais fora do ar do que funcionando, inclusive).

Infelizmente nenhum PSP está redondo e vai demorar até que fique.

<@!780500321994539068> <@!778446991692267541> será que dá pra marcar algum dos PSPs com 🆗 ?

PSPinheiro

Estou fazendo uma tabela com uma lista de PSPs e o seu nível de interoperabilidade. Algum PSP pagador (do ponto de vista do recebedor, em questão de conciliação, exibição das informações corretas do qr/cobrança para o pagador) já pode ser considerado "aprovado" em todos esses aspectos?

- leitura/pagamento de QR (câmera) estático
- leitura/pagamento de Pix Copia e Cola estático
- leitura/pagamento de QR (câmera) dinâmico
- leitura/pagamento de Pix Copia e Cola dinâmico

Se adotar algumas precauções na geração do EMV, como br.gov.bcb.pix em minúsculas e preencher o campo valor, está passando em quase todo lugar. Algumas coisas conhecidas não afetam a GN; exemplo, criptografia ES256 no JWT tem poucos PSPs suportando, mas a da GN é PS256.