Como recebo pagamentos por Pix no meu site?

Estático ou dinâmico: a escolha que decide todo o resto

O Banco Central define os dois no Manual de Padrões para Iniciação do Pix (a versão atual é a 2.10.0). No código estático, tudo o que é preciso para iniciar o pagamento está dentro da própria imagem: um item obrigatório, uma chave Pix registrada no DICT, e quatro opcionais — um identificador da transação, um campo de texto livre, o valor e um campo usado só pelo Pix Saque. O manual diz que o código estático pode ser criado diretamente pela automação do próprio recebedor e afirma, em maiúsculas, que criá-lo NÃO faz parte da API Pix. O seu site pode montá-lo; nenhum banco precisa participar.

Já o código dinâmico contém uma URL no servidor do seu provedor de pagamentos, que o aplicativo do comprador consulta no momento da leitura para buscar o valor e os dados da transação. Como só o seu provedor pode servir essa URL, o código dinâmico sempre vem de um provedor — a API Pix do seu banco ou uma empresa de pagamentos — e é esse mesmo provedor que pode avisar o seu site quando o dinheiro entra. A regra prática: se o pagamento precisa liberar algo automaticamente (um download, uma conta, um horário agendado), você precisa do caminho dinâmico e de algo no servidor para receber o aviso, a mesma linha traçada em meu site precisa de backend. Se uma pessoa pode conferir o banco antes de entregar, um código estático com o valor já basta.

O que encontramos nos sites que hospedamos

A AgentCeres — o AI Growth Officer em agentceres.com — hospeda páginas que os clientes constroem com o agente dela, e a maioria desses clientes está no Brasil. Quando contamos, em 23 de setembro de 2026, 54 de 173 páginas de clientes no ar mencionavam Pix e 78 mostravam preços em reais. O problema estava em como recebiam:

1. Nove páginas traziam um código Pix que a IA tinha escrito à mão. Um BR Code termina com um dígito verificador calculado sobre todos os caracteres anteriores, e o manual observa que até a ordem dos campos o altera. Um código com um caractere errado não é lido — pelo menos um cliente nos contou que o aplicativo do banco não conseguia escanear o dele.
2. Vinte e duas páginas exibiam a chave Pix como texto. Funciona, mas o comprador digita o valor, e pagamentos errados ou parciais ficam fáceis. Um dono tinha pedido para usar o CPF, o que coloca um documento pessoal numa página pública; uma chave aleatória faz o mesmo papel sem isso.
3. O pagamento era "comprovado" pelo comprador. Os formulários de pedido pediam que o comprador marcasse uma caixa dizendo que tinha pagado e enviasse um print — o que só prova que alguém sabe tirar print.

Então colocamos o caminho estático na nossa hospedagem, e as escolhas são a parte que serve para qualquer um. O código é gerado a partir da chave do próprio dono, então o banco do comprador paga direto o banco do dono e nunca ficamos com o dinheiro. O valor é calculado no nosso servidor a partir dos preços da página publicada, nunca de um total enviado pelo navegador, porque qualquer coisa na página pode ser alterada pelo visitante. Se o valor não pode ser calculado, a geração falha em vez de cair num código sem valor. E a confirmação continua manual: o dono confere o banco e marca o pedido como pago, e a página do comprador diz que está aguardando o vendedor até isso acontecer.

Como acertar um código estático

Um detalhe joga a favor do comprador. O manual diz que o nome que o pagador vê antes de confirmar é sempre o registrado no DICT para aquela chave, e o nome do recebedor escrito no código é ignorado. Então o comprador pode conferir quem de fato vai receber o dinheiro, diga a página o que disser — vale avisar isso perto do botão. Se você prefere fechar a venda numa conversa em vez de na página, um botão de WhatsApp que envia o pedido é a alternativa comum, e os dois funcionam bem juntos.