Histórico de mensagens em pix

Saquei. Na experiência que estamos construindo aqui essa validação é essencial. É algo que está no roadmap ou algo que podemos ajudar a implementar?

Não, e por isso que sugeri a possibilidade de especificar tanto chave Pix quanto CPF/CNPJ, e aí a GN verificaria antes de enviar o Pix.

Pessoal, uma dúvida (olhando a documentação não identifiquei). Existe algum endpoint para validação dos dados bancários? Ex.: pretendo fazer pix usando, inicialmente, os dados bancários da pessoa. Eu consigo validar esses dados (e titularidade) antes de enviar no /v2/pix/enviar ?

Blz.. apliquei a correção aqui, valeu a explicação!

não, seguia a regra do campo 54 (amount)

Que maravilha heim.. rsrrs e no caso sem o 63 o usuário poderia digitar qualquer valor?

PSPs que validam o CRC: exibiam qr code inválido;
PSPs que não validam o CRC: alguns exibiam qr code inválido (por conter 3 caracteres num campo que deveria ter 4); outros ignoravam a regra a tal ponto que o campo 63 era totalmente descartado e o QR era considerá válido (pagável)

No caso o PSP lia o qrcode e apresentava um erro? Tipo aquele erro que acontecia com os centavos ou erro é qrcode inválido?

a validação de CRC é importante principalmente nos QR codes estáticos. pois um caractere lido errado pode ocasionar (extrapoladas as probabilidades, mas ainda é possível) um pagamento pro destinatário correto (verificável pelo pagador na tela do app) com txid incorreto (difícil ou até impossível de ser verificado, se não tiver essa referência fora do próprio QR pra ele conferir), ou recebedor + txid correto mas valor incorreto, etc...

nos QR codes dinâmicos o conjunto recebedor + txid + valor vem todo do payload, então se a leitura do QR for errada, vai carregar um conjunto todo diferente, o que é um problema muito menor

cara, tem 2 regras:

- o campo 63 precisa ter 4 caracteres
- o CRC16 é calculado em cima de toda a string (incluindo 6304)

então o certo é comparar seguindo a norma:

- pega a string e retira apenas o valor do campo 63 (mantém 6304)
- calcula o CRC em cima do que sobrou

se o CRC do que sobrou é "924" (ou "0924", dependendo da função que vc use pra calcular o CRC já é normal o "0" à esquerda estar presente) o valor do campo tem que ser considerado um "match"

- se algum PSP não considerar a string com "0924" match, tá errado
- se algum PSP considerar a string com "924" match, também tá errado (pq o campo tem que ter 4 caracteres e essa regra já estaria quebrada independentemente do teste de CRC)

inclusive a remoção do txid no primeiro caso leva a C568, que é o maior dos CRCs, para uma string que é menor:

Eu fiz alguns testes aqui, mesmo esse estático com 88 gerou "7AA1"
Mas me diz uma coisa, se fosse 03924 passaria?
- pergunto isso porque penso que para que seja adicionado o 0 na frente do 924, a implementação de quem vai checar também tem que adicionar o 0

o valor do CRC não tem ligação direta com o tamanho final da string

<@!783359762917752843>

estático, menor possível

solicitei agr

um estático com chave email de 6 caracteres, [email protected] seria o menor brcode possível

monta um brcode com o menor tamanho possível (somente campos obrigatórios), com o valor mais curto que fizer sentido, e vc vai ter uma noção

<@!387276532193689600>, o certificado você pode solicitar através do ticket, informando o número da conta e o nome da aplicação em que deseja ativar o Pix.

como faço pra pegar o certificado de produção ?

lembra se esse código tem um mínimo de caracteres? Digo todo o brcode..