How do I accept Pix payments on my website?

Static or dynamic: the choice that decides everything else

Brazil's central bank defines both in its Manual de Padrões para Iniciação do Pix (version 2.10.0 is the current one). In a static code, everything needed to start the payment is inside the image itself: one required item, a Pix key registered in the DICT directory, and four optional ones — a transaction identifier, a free-text field, the amount, and a field used only for Pix Saque. The manual says a static code can be created directly by the recipient's own software, and states in capitals that creating one is NOT part of the Pix API. Your site can build it; no bank has to be involved.

A dynamic code instead contains a URL on your payment provider's server, which the buyer's app reads at the moment of scanning to fetch the amount and transaction details. Because only your provider can serve that URL, a dynamic code always comes from a provider — your bank's Pix API or a payment company — and that same provider is the one that can notify your site when the money lands. The rule of thumb: if the payment has to unlock something automatically (a download, an account, a booking slot), you need the dynamic route and something server-side to receive the notice, which is the same line drawn in does my website need a backend. If a person can check the bank before shipping, a static code with the amount in it is enough.

What we found on the sites we host

AgentCeres — the AI Growth Officer at agentceres.com — hosts pages that customers build with their agent, and most of those customers are in Brazil. When we counted on 23 September 2026, 54 of 173 live customer pages mentioned Pix and 78 showed prices in reais. How they took the payment was the problem:

1. Nine pages embedded a Pix code the AI had written by hand. A BR Code ends in a checksum computed over every character before it, and the manual notes that even the order of the fields changes it. A code that is one character off does not scan — at least one customer told us their bank app would not read theirs.
2. Twenty-two pages printed the Pix key as text. That works, but the buyer types the amount, so wrong and partial payments are easy to make. One owner had asked for their CPF to be used, which puts a personal tax ID on a public page; a random key (chave aleatória) does the same job without it.
3. Payment was "proved" by the buyer. Order forms asked the buyer to tick a box saying they had paid and to upload a screenshot — which proves only that someone can take a screenshot.

So we built the static route into our hosting, and the choices are the transferable part. The code is generated from the owner's own key, so the buyer's bank pays the owner's bank directly and we never hold the money. The amount is computed on our server from the prices on the live page, never from a total the browser sends, because anything in the page can be edited by the visitor. If the amount cannot be computed, generation fails instead of falling back to a code with no amount. And confirmation stays manual: the owner checks their bank and marks the order paid, and the buyer's page says it is waiting for the seller until they do.

Getting a static code right

One detail works in the buyer's favour. The manual says the name the payer sees before confirming is always the one registered in the DICT for that key, and the merchant name written into the code is ignored. So a buyer can check who is really receiving the money, whatever the page says — worth pointing out next to the button. If you would rather close the sale in a conversation than on the page, a WhatsApp button that sends the order is the common alternative, and the two work well together.