Comprovante de PIX falso: o que o arquivo mostra

Só o seu banco confirma um PIX: o dinheiro entrou na conta ou não entrou. O que um comprovante em PDF ainda responde é outra pergunta, se o arquivo foi editado depois de criado. Solte um e veja o que a estrutura dele registra.

O que o arquivo mostra

O arquivo é enviado por HTTPS, processado em memória e descartado quando a resposta é escrita, num servidor em Helsinque, na Finlândia (privacidade). Sem conta.

Solte um comprovante aqui, ou procure

PDF ou foto · Máx. 10 MB · processado em memória, nunca armazenado

Sem um comprovante à mão? Teste as amostras:

Três documentos fictícios: uma fatura de serviços em vez de um comprovante PIX, porque o de um banco real não pode ser publicado, e a mecânica é idêntica: a cópia editada tem uma segunda revisão que alterou o total impresso, e a cópia assinada foi alterada depois da assinatura.

Comece pela única prova que existe

Um pagamento PIX se confirma no app ou no extrato do seu próprio banco, e em nenhum outro lugar. O dinheiro entrou ou não entrou. Numa venda, procure o crédito antes de entregar a mercadoria, nenhum comprovante, por mais convincente, substitui isso.

São duas perguntas com duas autoridades diferentes, e só a segunda mora dentro do arquivo.
um comprovante de PIX na sua mão 1 · O DINHEIRO ENTROU? Responde: o app ou o extrato do seu próprio banco. Nenhuma análise do arquivo responde isto. 2 · O ARQUIVO FOI EDITADO? Responde: a estrutura do PDF revisões, producer, datas, CRC. Segunda opinião: disputa, despesa, auditoria. só então entregue a mercadoria Esta coluna nunca substitui aquela.

Esta página existe porque se busca muito como identificar um comprovante PIX falso, e a maioria dos conselhos para em "olhe com atenção": confira a fonte, o alinhamento, o logotipo. Uma falsificação bem feita sobrevive a tudo isso. O que o olho não lê, e a estrutura do arquivo lê, é a história do próprio documento: se os bytes foram escritos uma vez pelo gerador de um banco, ou escritos e depois escritos de novo por outra coisa.

O que a estrutura mostra: quando o comprovante é um PDF

  • Uma revisão extra anexada depois da criação. O app de um banco escreve o comprovante uma vez. Editores de PDF salvam mudanças acrescentando ao fim do arquivo, deixando os bytes originais no lugar: um comprovante editado carrega duas versões de si mesmo, e o relatório diz o que mudou entre elas.
  • O producer. Geradores de comprovante são bibliotecas de servidor ou do próprio app, e se nomeiam, ou não dizem nada. Um comprovante cujos metadados nomeiam um editor de PDF de consumo carrega um fato que merece explicação, e o relatório distingue ferramentas que criam documentos de ferramentas que consomem um já existente.
  • Datas que não batem. Um carimbo de criação de um momento e um de modificação de outro, ou alegações de metadados que não concordam com a contagem de revisões do próprio arquivo.
  • A aritmética do próprio payload PIX. Quando o comprovante traz o payload copia-e-cola, essa sequência termina em caracteres de verificação calculados a partir do resto dela: um CRC. A família br-identifier-checksum refaz a conta: um valor ou uma chave redigitados dentro do payload contradizem uma aritmética que o sistema emissor já executou, sem precisar de nada para comparar.
Os últimos quatro caracteres do payload são calculados a partir de todo o resto, então um valor redigitado faz a sequência contradizer a si mesma: sem precisar de nada para comparar.
um valor redigitado aqui… cabeçalho valor chave · nome · cidade · id CRC 4 caracteres O emissor já rodou esta conta uma vez, e ela é refeita sobre o texto impresso. …e os quatro caracteres finais deixam de fechar.

Vale só quando o comprovante traz o payload copia-e-cola, e a assimetria é a metade honesta: um CRC que falha é evidência; um CRC que passa não é: qualquer gerador que implemente a regra corretamente produz números que fecham. A família é br-identifier-checksum.

Cada achado sai com a evidência e a explicação benigna: um comprovante que passou por uma ferramenta de carimbo ou arquivamento também ganha uma revisão, honestamente. Sinais, nunca um veredicto.

O que a estrutura não mostra

Um print não tem estrutura de PDF: o que sobra são sinais mais fracos e fáceis de remover, e um print que volta quieto diz muito pouco.
comprovante em PDF print (imagem) cadeia de revisões producer e Creator dois repositórios de metadados payload copia-e-cola, com CRC nenhuma cadeia de revisões nenhum producer de PDF ~histórico de compressão ~metadados da imagem ~ = presente, porém fraco: apps de mensagem removem no envio.
  • Nada sobre um print. A maioria dos comprovantes PIX circula como print, e a imagem de um comprovante não tem estrutura de PDF, sem cadeia de revisões, sem fontes, sem producer. O motor de imagem lê histórico de compressão e metadados da imagem, sinais mais fracos e fáceis de remover; o relatório diz qual motor rodou. Um print que volta quieto diz muito pouco.
  • Se o dinheiro se moveu. Um PDF estruturalmente impecável prova que os bytes foram escritos uma vez, por uma ferramenta. Não prova que a transferência aconteceu, e esta página nunca vai afirmar que prova. Essa resposta mora no seu banco, ponto final.

Onde esta verificação vale a pena

Não no balcão. Ali, o app do seu banco é mais rápido e definitivo. A inspeção do arquivo é uma segunda opinião para os casos em que o próprio arquivo é a pergunta: uma disputa posterior sobre um comprovante supostamente adulterado, um relatório de despesas em revisão interna, uma trilha de auditoria em que o PDF do comprovante é a peça registrada. Nesses casos, o que a estrutura do arquivo registrou na hora de salvar é evidência que nenhum olhar atento alcança. O guia de boleto falso cobre o problema vizinho, onde os dígitos verificadores impressos fazem ainda mais do trabalho.

Rode a verificação num comprovante editado

Abra a amostra "Editado após a criação" . Um documento fictício cujo total impresso foi reduzido por uma segunda revisão anexada depois da criação, com a evidência ao lado de cada sinal. Sem conta, sem cota. O seu próprio comprovante entra no mesmo verificador: o arquivo é enviado por HTTPS, processado em memória e descartado quando a resposta é escrita, num servidor em Helsinque, na Finlândia (privacidade). Revisando em volume, um POST devolve o mesmo relatório em JSON: 50 documentos por mês grátis, sem cartão.

A Tamperlens reporta sinais de risco, não veredictos de autenticidade. Sinais podem ter causas legítimas; combine-os com a sua própria lógica de decisão, e nenhum deles prova que o dinheiro entrou.