pix-api
pix-api copied to clipboard
bacen
Diversos participantes falhando ao ler QRCode
Boa tarde, Estamos implementando no Banco Arbi as soluções PIX e recentemente fomos aprovados em todos os testes do QRTester, porém alguns grandes bancos do mercado retornam erro ao ler o copia e cola. Alguém está sofrendo deste problema também?
Pix copia e cola (QRCode dinâmico imediato): 00020101021226840014BR.GOV.BCB.PIX2562qrcode.bancoarbi.com.br/gi/v2/0d79dd1920434e39a536026da88fa86b5204000053039865802BR5915Juan Jose Ramos6013RIO DE JANEIR61082192002062070503***63049D8E
| Participante | Resultado |
|---|---|
| Bradesco | OK |
| NuBank | OK |
| Ame | OK |
| C6 Bank | OK |
| Caixa Econômica | Falha na leitura |
| Itaú | Falha na leitura |
| Santander | Falha na leitura |
00020101021226840014BR.GOV.BCB.PIX2562qrcode.bancoarbi.com.br/gi/v2/0d79dd1920434e39a536026da88fa86b5204000053039865802BR5915Juan Jose Ramos6013RIO DE JANEIR61082192002062070503***63049D8E
No seu payload JWS tem algo estranho no header:
"x5t#S256": "MQayiPOzG8yZnUf9PdDVzjnjEP1aL_a6Ptv4FidOYrw",
"jku": "https://qrcode.bancoarbi.com.br/gi",
"kid": "1",
"alg": "RS256"
}```
Nunca vi esse #S256 em outro payload, então não sei se o JWT permite isso... mas parece exótico.
@rubenskuhl o x5t#S256 é o Thumbprint SHA-256 e o x5t é o Thumbprint SHA-1. Ambos são permitidos pela RFC. Outros players utilizam esse campo sem problemas.
@Raphael-Afonso de qualquer forma, eu tentaria adicionar também no payload e no JKU o campo x5t, uma vez que um dos documentos do BACEN o menciona explicitamente.
Infelizmente para garantir a questão de interoperabilidade ainda é preciso fazer esse processo de testes/ajustes com outras instituições.
Seria interessante também revisar se o certificado do domínio que serve o payload foi devidamente submetido à interface ARQ. Se esse processo foi recente, também é possível que alguns PSPs ainda não tenham atualizado a lista.
Eu tentaria também incluir o campo 54 no BRCode, ainda que seja opcional, algum PSP pode estar esperando a presença dele. E imagino que você tenha testado, mas vale testar valores maiores que R$ 0,01.
@rubenskuhl o
x5t#S256é o Thumbprint SHA-256 e ox5té o Thumbprint SHA-1. Ambos são permitidos pela RFC. Outros players utilizam esse campo sem problemas.
As RFCs sim, a questão é o arranjo Pix.
@Raphael-Afonso , também recomendo acionar a caixa pix.
@ninrod , poderia nos falar sobre se SHA-1 ou SHA-256 são permitidos ou se um deles é obrigatório no arranjo Pix ?
BRCode
O campo 54 não seria o TransactionAmount? Mesmo informando com valores mais altos recebemos erro.
BRCode
O campo 54 não seria o TransactionAmount? Mesmo informando com valores mais altos recebemos erro.
Sim, é que não está presente no BRCode que vc enviou, apesar de estar presente no payload. Ele é opcional, mencionei apenas como mais uma opção para testar e entender se algum dos PSPs está rejeitando pela falta dele.
@ninrod , poderia nos falar sobre se SHA-1 ou SHA-256 são permitidos ou se um deles é obrigatório no arranjo Pix ?
@rubenskuhl , sim. Pode-se utilizar o x5t ou, alternativamente, o x5t#S256. Entendo que não há problemas em se utilizar os dois ao mesmo tempo, mas tem que existir um dos dois atributos.
fonte: Manual de segurança do Pix, página 22:
estou tendo o mesmo problema exemplo de um brcode: 00020101021126670014br.gov.bcb.pix0136216d10c2-8146-47dc-884b-e7dba1718e2a0205teste52040000530398654041.895802BR5920DOUGLAS A M DE SOUZA6006CUIABA62100506abc12363043845
00020101021126670014br.gov.bcb.pix0136216d10c2-8146-47dc-884b-e7dba1718e2a0205teste52040000530398654041.895802BR5920DOUGLAS A M DE SOUZA6006CUIABA62100506abc12363043845
Não encontrei nenhum erro nesse QR-Code estático, e o C6 entendeu perfeitamente esse QR-Code (o PSP recebedor é o Banco Inter). Em que PSPs você teve problemas ?
00020101021126670014br.gov.bcb.pix0136216d10c2-8146-47dc-884b-e7dba1718e2a0205teste52040000530398654041.895802BR5920DOUGLAS A M DE SOUZA6006CUIABA62100506abc12363043845
Também consegui ler normalmente aqui no Arbi.
Eu estou com problemas apenas dos QRCodes dinâmicos.
00020101021126670014br.gov.bcb.pix0136216d10c2-8146-47dc-884b-e7dba1718e2a0205teste52040000530398654041.895802BR5920DOUGLAS A M DE SOUZA6006CUIABA62100506abc12363043845
Não encontrei nenhum erro nesse QR-Code estático, e o C6 entendeu perfeitamente esse QR-Code (o PSP recebedor é o Banco Inter). Em que PSPs você teve problemas ?
estou tendo problema com itau,sicoob,nubank
00020101021126670014br.gov.bcb.pix0136216d10c2-8146-47dc-884b-e7dba1718e2a0205teste52040000530398654041.895802BR5920DOUGLAS A M DE SOUZA6006CUIABA62100506abc12363043845
Não encontrei nenhum erro nesse QR-Code estático, e o C6 entendeu perfeitamente esse QR-Code (o PSP recebedor é o Banco Inter). Em que PSPs você teve problemas ?
estou tendo problema com itau,sicoob,nubank
Consegui ler seu QRCode no Itaú sem problemas.
00020101021126670014br.gov.bcb.pix0136216d10c2-8146-47dc-884b-e7dba1718e2a0205teste52040000530398654041.895802BR5920DOUGLAS A M DE SOUZA6006CUIABA62100506abc12363043845
Não encontrei nenhum erro nesse QR-Code estático, e o C6 entendeu perfeitamente esse QR-Code (o PSP recebedor é o Banco Inter). Em que PSPs você teve problemas ?
estou tendo problema com itau,sicoob,nubank
Consegui ler seu QRCode no Itaú sem problemas.
nesse caso o problema era a geração da imagem do QrCode(ja resolvi), nos outros casos que tive problema foi porque eu estava gerando o txid com "-" no meio, removi e foi tudo resolvido.
00020101021126670014br.gov.bcb.pix0136216d10c2-8146-47dc-884b-e7dba1718e2a0205teste52040000530398654041.895802BR5920DOUGLAS A M DE SOUZA6006CUIABA62100506abc12363043845
Não encontrei nenhum erro nesse QR-Code estático, e o C6 entendeu perfeitamente esse QR-Code (o PSP recebedor é o Banco Inter). Em que PSPs você teve problemas ?
estou tendo problema com itau,sicoob,nubank
Consegui ler seu QRCode no Itaú sem problemas.
nesse caso o problema era a geração da imagem do QrCode(ja resolvi), nos outros casos que tive problema foi porque eu estava gerando o txid com "-" no meio, removi e foi tudo resolvido.
Você está conseguindo passar QRCode dinâmico?
Pessoal, estou com problemas tbm. O erro persiste para vocês? Nossos QRs são os mesmos na produção desde a última atualização dia 30abril.
santander, itaú e bb com erro.
Pessoal, estou com problemas tbm. O erro persiste para vocês? Nossos QRs são os mesmos na produção desde a última atualização dia 30abril.
santander, itaú e bb com erro.
Seguimos com problemas de aceitação nos grandes bancos.
@Raphael-Afonso, vocês usam o campo modalidadeAlteracao e se sim, com valor = 1?
@Raphael-Afonso, vocês usam o campo modalidadeAlteracao e se sim, com valor = 1?
Não utilizamos Leo.
@ninrod Há algum posicionamento do DECEM? O problema ainda persiste em alguns bancos...
pessoal, recomendo entrar em contato diretamente com o DECEM em [email protected] e [email protected].
@ninrod Há algum posicionamento do DECEM? O problema ainda persiste em alguns bancos...
Mas vocês já resolveram os problemas de encoding do JWT ? Acho que o primeiro passo é esse, e só quando estiver tudo certinho, reclamar dos outros.
@ninrod Há algum posicionamento do DECEM? O problema ainda persiste em alguns bancos...
Mas vocês já resolveram os problemas de encoding do JWT ? Acho que o primeiro passo é esse, e só quando estiver tudo certinho, reclamar dos outros.
Rubens, qual problema você identificou no nosso JWT? Estamos passando em todos os testes do QRTester, o item que você havia mencionado anteriormente o @ninrod disse que não haveria problemas.
@ninrod Há algum posicionamento do DECEM? O problema ainda persiste em alguns bancos...
Mas vocês já resolveram os problemas de encoding do JWT ? Acho que o primeiro passo é esse, e só quando estiver tudo certinho, reclamar dos outros.
Rubens, qual problema você identificou no nosso JWT? Estamos passando em todos os testes do QRTester, o item que você havia mencionado anteriormente o @ninrod disse que não haveria problemas.
Sim, mas como o @mliberato comentou, há uma menção específica ao x5t. Então para melhor interoperabilidade, seria prudente ter ambos x5t e x5t#S256.
@rubenskuhl Mas vocês já resolveram os problemas de encoding do JWT ? Acho que o primeiro passo é esse, e só quando estiver tudo certinho, reclamar dos outros.
also @rubenskuhl Sim, mas como o @mliberato comentou, há uma menção específica ao x5t. Então para melhor interoperabilidade, seria prudente ter ambos x5t e x5t#S256.
@rubenskuhl Seria prudente, sim, mas não é um problema de quem está reclamando dos demais. É um problema dos demais participantes que não estão seguindo a documentação, já que deveriam aceitar x5t#S256.
@ninrod Há algum posicionamento do DECEM? O problema ainda persiste em alguns bancos...
Mas vocês já resolveram os problemas de encoding do JWT ? Acho que o primeiro passo é esse, e só quando estiver tudo certinho, reclamar dos outros.
Rubens, qual problema você identificou no nosso JWT? Estamos passando em todos os testes do QRTester, o item que você havia mencionado anteriormente o @ninrod disse que não haveria problemas.
Sim, mas como o @mliberato comentou, há uma menção específica ao x5t. Então para melhor interoperabilidade, seria prudente ter ambos x5t e x5t#S256.
Rubens, na minha visão para garantir a interoperabilidade todos precisam seguir a documentação a risca, e a princípio parece que não é o que está acontecendo, entretanto levantarei esse ponto internamente no Arbi.
@ninrod Há algum posicionamento do DECEM? O problema ainda persiste em alguns bancos...
Mas vocês já resolveram os problemas de encoding do JWT ? Acho que o primeiro passo é esse, e só quando estiver tudo certinho, reclamar dos outros.
Rubens, qual problema você identificou no nosso JWT? Estamos passando em todos os testes do QRTester, o item que você havia mencionado anteriormente o @ninrod disse que não haveria problemas.
Sim, mas como o @mliberato comentou, há uma menção específica ao x5t. Então para melhor interoperabilidade, seria prudente ter ambos x5t e x5t#S256.
Rubens, na minha visão para garantir a interoperabilidade todos precisam seguir a documentação a risca, e a princípio parece que não é o que está acontecendo, entretanto levantarei esse ponto internamente no Arbi.
O princípio da robustez já foi citado bastante aqui no repositório, e ele opera exatamente sob o mantra de cada um ir além do básico para se buscar interoperabilidade.
O princípio da robustez é válido. Só estou apontando a forma como você falou: não há um problema no JWT do participante em questão. O problema está nos demais, que simplesmente não estão seguindo a documentação.