QR Code Pix estático ou dinâmico: qual libera o acesso

Quem vende acesso a um grupo fechado tropeça nessa escolha sem saber que ela tem nome. A decisão entre QR Code Pix estático ou dinâmico parece estética, porque os dois viram um quadradinho e os dois podem ser copiados como texto, e na verdade ela decide se um pagamento consegue virar acesso sem você olhar o extrato.

Resposta primeiro: o estático guarda todos os dados dentro de si e aceita cinco configurações, das quais só a chave Pix é obrigatória. O dinâmico guarda uma URL que é lida no momento do pagamento, e é por essa URL que chegam valor, vencimento e identificador da transação. A consequência prática está escrita com todas as letras no Manual de Padrões para Iniciação do Pix, do Banco Central: "Somente Pix associados a um txid serão informados via a funcionalidade webhook".

Ou seja, a diferença não é o desenho. É que um dos dois nasce registrado, com identificador único, e por isso pode disparar um aviso automático quando o dinheiro cai. O outro não avisa ninguém.

QR Code Pix estático ou dinâmico: o que cada um carrega

Resposta primeiro: o manual descreve o estático como um código de "rol de funcionalidades restrito", com "apenas cinco opções para configuração". A primeira é obrigatória, que é informar uma chave válida no diretório de contas. As outras quatro são opcionais: identificador da transação, campo de texto livre, valor do pagamento e identificação do facilitador de saque.

O dinâmico inverte a lógica. Segundo o mesmo documento, ele "em sua estrutura interna, é configurado com uma URL que é acessada no momento de sua leitura", e "contém somente as informações básicas do usuário recebedor", porque "o restante das informações é obtido no endpoint do PSP do recebedor indicado por esta URL".

O que a venda precisa	QR estático	QR dinâmico
Valor por venda	Opcional, fixo no código	Vem da URL
Identificador da transação	Opcional, até 25 caracteres	Obrigatório, 26 a 35
Unicidade garantida pelo banco	Não	Sim, por recebedor
Aviso automático (webhook)	Só se houver txid	Sim
Deixa de aceitar pagamento	Nunca	Pode responder 410
Quem consegue gerar	Você, no app do banco	API Pix, via gateway

A linha que decide quase tudo é a terceira. Tudo o que vem depois dela, no fluxo de uma venda automatizada, depende de o banco poder garantir que aquele identificador não se repete.

Por que só um dos dois avisa que o pagamento caiu

Resposta primeiro: o aviso automático é um recurso chamado webhook, e o manual o define como "um recurso técnico que permite que o PSP Recebedor informe diretamente o usuário recebedor quando um Pix associado a um txid foi creditado na sua conta transacional". Em seguida, vem a frase que encerra o assunto: "Somente Pix associados a um txid serão informados via a funcionalidade webhook".

Repare no que isso faz com a operação de quem vende acesso. Sem webhook, a ferramenta não tem como saber que o pagamento entrou, então ela precisa perguntar ao banco de tempo em tempo, ou depender de você conferir. O manual descreve essa inversão com clareza: o recebedor "deixa de consultar o PSP Recebedor a todo momento (polling) e passa a ser informado na ocorrência de uma liquidação".

É por isso que chave Pix colada na bio e liberação automática de acesso não combinam. Não é limitação da ferramenta, é o desenho do arranjo. O caminho que funciona está descrito no artigo sobre como o Pix automático libera o acesso em três passos, e este artigo é a parte de baixo dele: qual tipo de QR Code o padrão exige para que aqueles três passos sejam possíveis.

O txid é o que o banco garante, e só nas cobranças

Resposta primeiro: txid é o identificador da transação na perspectiva de quem recebe, e a diferença entre os dois tipos de QR está em quem garante que ele não se repete.

Nas cobranças criadas pela API Pix, o manual determina que "o PSP Recebedor deve assegurar que não exista repetição do txid para o mesmo usuário recebedor" e que "o conjunto CNPJ ou CPF e txid deve ser único para um dado PSP". Reforça ainda que "o txId deve ser sempre único, não podendo ser repetido, ainda que a cobrança original tenha sido cancelada ou baixada". O tamanho é fechado: "no mínimo, 26 caracteres e, no máximo, 35 caracteres", com os caracteres aceitos limitados a A-Z, a-z e 0-9.

No QR estático, a garantia desaparece, e o manual explica por quê: "o PSP Recebedor não tem a possibilidade de assegurar que o txid não se repita em QR Codes estáticos, uma vez que eles não são gerados por meio da API Pix e, portanto, não são previamente registrados pelo PSP recebedor". O campo equivalente no padrão BR Code, o 62-05, "é limitado a 25 caracteres", e quando o gerador decide não usá-lo o valor que entra é ***.

A frase que fecha o tema é a que mais importa para quem vende: em QR estático, diz o manual, "a consistência dos pagamentos realizados por meio de QR Codes estáticos fica totalmente a cargo do usuário recebedor". Em português de operação: a conferência é sua, com o seu olho, no seu tempo.

Exemplo trabalhado para dimensionar. Uma venda de R$ 40 por acesso, 6 vendas por dia, 3 minutos para receber o comprovante, achar no extrato, conferir e liberar. São 18 minutos por dia, 9 horas por mês de trabalho que não aparece em nenhum relatório. A taxa de transação dessas 180 vendas, a R$ 0,69 fixos, soma R$ 124,20. Nove horas do seu mês valem mais do que isso em praticamente qualquer cenário, e é essa a conta real por trás da escolha do QR Code.

O QR dinâmico não é algo que você gera no app do banco

Resposta primeiro: esta é a parte que costuma surpreender. O manual diz que "o QR Code dinâmico no Pix deve ser gerado pelo usuário recebedor por meio da API Pix", e é mais específico sobre automação: "em um contexto de integração automatizada, não pode ser criado diretamente pelo usuário recebedor. É preciso que o usuário recebedor, em seu software de automação comercial / TEF / Gateway configure o endpoint que será responsável por retornar as informações relativas à cobrança". E acrescenta que "a API Pix NÃO retorna um arquivo com o QR Code gerado".

Vale dizer que essa API não é caixa-preta de fornecedor. O próprio manual aponta, em nota, para o repositório oficial da API Pix, mantido pelo Banco Central, que se apresenta como o lugar onde estão "as especificações funcionais em formato OpenAPI 3.0 referentes à API Pix". Dá para conferir, endpoint por endpoint, o que uma cobrança registrada carrega, antes de contratar quem vai criá-la por você.

Daí vem a divisão de trabalho que existe no mercado. O criador tem a conta e a chave; quem fala a API Pix é a instituição de pagamento; e quem transforma "assinou o plano de R$ 40" em uma cobrança registrada com txid único é o software de vendas. É o mesmo arranjo que a explicação de pagamento pass-through descreve do lado do dinheiro: a ferramenta cria a cobrança e o valor cai na conta do criador.

Contra-argumento honesto: existe geração de QR dinâmico pelo aplicativo do banco em alguns casos, e o manual registra essa exceção. Só que ela é manual por definição, uma cobrança de cada vez, e não resolve venda automatizada. Serve para cobrar um cliente avulso, não para atender quem comprou às três da manhã.

Cobrança concluída não quer dizer obrigação paga

Resposta primeiro: aqui mora um detalhe que engana até quem já integrou. O manual avisa, em nota, que o estado CONCLUÍDA "refere-se à Cobrança gerada e não à obrigação associada", de forma que "esse estado não indica a liquidação da obrigação em si, mas apenas que aquela Cobrança não admite novos pagamentos".

Traduzindo para a sua operação: cobrança concluída significa que aquele link específico morreu, não necessariamente que você recebeu. Quem decide a liberação do acesso pelo estado da cobrança, e não pelo aviso de liquidação, libera errado em algum momento.

O outro lado disso é a vantagem da cobrança dinâmica. O manual prevê que "payloads que representem cobranças já concluídas, expiradas ou removidas podem retornar um HTTP status que apresente semântica adequada", citando 410 e 404 como exemplos. A cobrança tem fim. O QR estático não tem: a mesma imagem aceita pagamento amanhã, depois de amanhã e no ano que vem, com o valor que o pagador digitar. É exatamente por isso que print antigo volta a circular, e o caminho de investigar esse tipo de caso está em pagou e não entrou no grupo.

Quando o QR estático continua sendo a escolha certa

Resposta primeiro: quando não existe nada para liberar. O manual reconhece que "há casos de uso em que a repetição de um txid em QR Codes estáticos é desejável", e dá como exemplo o pagamento no ato da compra com código fixo e sem valor definido.

Três situações de quem vende conteúdo caem nessa descrição:

• Gorjeta e valor livre. Não há acesso a conceder, e o valor é escolha do pagador. A mecânica de cobrar por fora da assinatura está em gorjeta no Telegram.
• Cobrança pontual e negociada no privado. Um pedido sob encomenda, combinado por mensagem, com você acompanhando a conversa de ponta a ponta.
• Recebimento fora do fluxo de vendas. Reembolso de custo, divisão de despesa, pagamento entre parceiros.

E existe um caso intermediário que o manual resolve com um recurso próprio: o QR impresso que precisa mudar de valor. A descrição do PayloadLocation fala de "um recurso que permite ao PSP Recebedor reusar uma URL, retornando diferentes cobranças (payloads JSON) ao longo do tempo, mas apenas uma por vez", usado "quando o usuário recebedor precisa apresentar um QR Code impresso, mas que seja dinâmico".

Erros comuns

• Achar que o formato visual informa o tipo. O manual diz que o copia e cola vale para estático, dinâmico e composto. A sequência de caracteres não revela qual é.
• Colocar o valor no QR estático e considerar o problema resolvido. Valor travado não cria identificador, e sem identificador não há aviso automático.
• Usar o mesmo código para todos os assinantes. Dois pagamentos iguais no mesmo minuto ficam indistinguíveis no extrato, e a conferência sai errada.
• Confiar no comprovante enviado pelo cliente. A confirmação precisa vir da instituição que processou o pagamento, como explica segurança ao vender no Telegram.
• Liberar acesso pelo estado da cobrança. Concluída é sobre o link, não sobre o crédito na conta.
• Tratar o cadastro de chave como integração. Ter chave Pix é requisito para receber, e não o mecanismo que gera cobrança registrada.

Conclusão

A escolha entre QR estático e dinâmico não é de aparência nem de preferência: é sobre quem garante que aquele pagamento tem um identificador único. O estático aceita cinco configurações e deixa a conferência por sua conta, nas palavras do próprio manual do Banco Central. O dinâmico nasce na API Pix, com txid de 26 a 35 caracteres e unicidade garantida pelo banco, e é essa condição que permite ao aviso automático existir.

O próximo passo leva cinco minutos: olhe como a sua venda é cobrada hoje. Se o cliente recebe uma chave ou um código sempre igual, cada venda está cobrando quatro passos seus, e o acesso depende de você estar acordada. Se quiser ver como fica do outro lado, a página de preço da Afroditte mostra a taxa fixa de R$ 0,69 por transação sem mensalidade, e criar sua conta leva menos tempo do que conferir o extrato de um dia de vendas.