Termos mais procurados:
Um dos problemas da documentação do BACEN é que ela mistura um pouco o ponto de vista funcional com o regulatório. Neste caso, imagino que o BACEN quisesse dizer que se vier a infoPagador na mensagem ISO 20022 (que lá se chama RemittanceInformation ), o PSP tem que repassar isso na API Pix.
Aí o próximo passo é que muito da documentação da GN é copy-paste da do BACEN... 😉
$file = file_get_contents(__DIR__ . '/../../../app/cert/config.json');
$options = json_decode($file, true);
$body = [
"calendario" => [
"expiracao" => 3600
],
"devedor" => [
"cpf" => "09488986743",
"nome" => "Francisco da Silva"
],
"valor" => [
"original" => "0.01"
],
"chave" => "04055053000160", // Chave pix da conta Gerencianet do recebedor
"solicitacaoPagador" => "123",
"infoAdicionais" => [
[
"nome" => "Campo 1", // Nome do campo string (Nome) ≤ 50 characters
"valor" => "000000" // Dados do campo string (Valor) ≤ 200 characters
],
[
"nome" => "Campo 2",
"valor" => "Informação Adicional2 do PSP-Recebedor"
]
]
];
Temos sim um modo sandbox para geração do QR code, mas esse QR Code não pode ser lido por outro PSP
Não foi a escolha do Banco Central, por isso não existe o status de expirada. Podem ter pensado em normalização de dados, podem ter pensado em carga nos PSPs para expirar as cobranças... mas fato é que a API Pix padrão não é assim.
Fato é que não obedecer ao padrão da API Pix era desqualificação imediata na seleção de PSPs que fizemos. E que hoje usamos Gerencianet, mas como é um padrão, temos liberdade para mudar se quisermos. Quem usa os não padrão, tem um custo de mudança elevado.
Boa tarde, <@!697531663495856170>! Esta falha ocorre quando a chave Pix não pertence a conta Gerencianet em que você está utilizando as credenciais e certificado, ou seja, você deve utilizar uma chave Pix gerada em sua conta Gerencianet e não de outro PSP e/ou outra conta Gerencianet.
A experiência indireta via APIs e apps dos PSPs sugere uma disponibilidade bastante alta do SPI (liquidação) e DICT ("DNS das contas"). Eu só lembro de um episódio de falha desde o lançamento do Pix em 20.11.2020.
Boa tarde, <@!910707960232149043>! Sim, hoje os PSPs podem utilizar diferentes maneiras de completar uma transação Pix, seja via chave, confirmação de pagamento pelo QRCode, dados bancários, etc...
No cenário do BACEN em que o QRCode foi pago, o correto seria pela leitura do txid e o pagamento chega como realizado por meio do QRCode.
Na realidade, quando eu gerava o QRCode dinâmico, se eu não colocasse o valor em alguns PSP permitia editar. Então hoje no meu QRCode dinâmico eu por padrão faço isso coloco a propriedade do valor (não lembro qual é agora)
Que o padrão do BACEN para QR-Code dinâmico sem o parâmetro de alterar valor diz para rejeitar, e a GN diz que segue isso. Mas que para testar, precisa de um PSP pagador que não verifique alteração do valor entre o QR-Code e o payload.
O payload é usado para comunicar os parâmetros da cobrança do PSP recebedor para o PSP pagador. É algo que os devs dos PSPs precisam se importar, não você...
Você esta fazendo a leitura do QrCode através do aplicativo de algum PSP? A cobrança Pix foi emitida em homologação ou produção?
Tem que entrar no app mobile da Gerencianet depois de ter feito o pedido de portabilidade no novo PSP, e autorizar que a portabilidade se complete.
Precisa pedir a portabilidade no PSP novo, autorizar na Gerencianet. Se fizer só uma das duas coisas, não completa.
Há um incentivo negativo para os PSPs pagadores fazerem validação... pq quando dá problema, o cliente deles liga para eles, não para o merchant ou para o PSP do merchant. Então muitos não fazem crítica do QR-Code ou do payload.
Você pode ver como problemas em geral dão em só um ou outro PSP, mesmo sendo falhas de construção do EMV ou do Payload em outros exemplos:
https://github.com/renatofrota/pix-pendencias/issues
