Static vs dynamic PIX QR codes — which one your business needs

The distinction lives in one field

Both kinds are EMV BR Codes. Field 01, the point of initiation method, tells them apart:

	Static (01 = 11)	Dynamic (01 = 12)
Contains	PIX key, name, city, optional amount	A URL in field 26.25
Who generates it	Anyone, free	Your bank or PSP, via API
Reusable	Forever	One transaction, then expires
Amount	Fixed in the code or typed by payer	Set server-side per charge
Payment confirmation	You check your statement	Webhook to your system
Can change after printing	No	The URL resolves fresh data each scan
Needs an integration	No	Yes

This is PIX's version of the general static vs dynamic split, with one twist: a dynamic PIX code is not a redirecting link. The URL in 26.25 is fetched by the payer's banking app, which retrieves a signed charge — amount, payer restrictions, expiry — from the PSP before the customer confirms.

What static gets you

A static code is self-contained. Everything the payment needs is in the string, ending in the CRC16 checksum. You can generate one in the PIX builder, print it once, and take payments on it for years at zero cost.

Its limits are equally clear:

• Reconciliation is manual. The txid in a static code defaults to ***; you can set a 1–25 character alphanumeric reference, but every scan of the same print carries the same one. Matching payments to orders means reading your bank or PSP statement.
• No expiry, no per-charge control. You cannot cap, expire or restrict who pays.
• Amount is take-it-or-leave-it. Either fixed in field 54 or typed by the customer.

For a counter, a market stall, a donation box or an invoice with the amount printed on it, none of these limits matter. That is why the small-shop setup is a static code.

What dynamic gets you

Dynamic codes exist for software, not counters. An e-commerce checkout generates one code per order: exact amount, order id as txid, a 15-minute expiry, and a webhook the moment the payment lands — so the order flips to "paid" without anyone reading a statement.

The costs: you need a PSP or bank API integration, each code is single-use, and if the PSP's endpoint is down the code cannot be paid — the payload alone is not enough. A printed dynamic code is a contradiction; by the time it is on paper it has usually expired.

Decision table

Your situation	Use
Counter or stall, customer types the amount	Static, no amount
Fixed-price product or service	Static, amount in field 54
Printed invoice with the total on it	Static with amount, invoice number as txid
E-commerce checkout	Dynamic via your PSP
Recurring billing with per-charge tracking	Dynamic via your PSP
Donations	Static, no amount

What UseQR generates

UseQR builds static codes only, entirely in your browser — the key never touches a server. Dynamic codes are inherently a PSP product because they require the PSP's charge-resolution endpoint; no standalone generator can honestly offer them. If a "free dynamic PIX" tool is not your PSP, ask what URL it is putting in field 26.25 and what happens when that service shuts down.

Whichever you deploy, scan it with a real banking app before printing, and check the displayed name — or decode it with /validate to inspect the fields.

FAQ

How do I tell if a PIX QR code is static or dynamic?

Decode it and read field 01: 11 means static, 12 means dynamic. Dynamic codes also carry a URL in field 26.25 that the banking app resolves; static codes contain the key and data directly.

Do static PIX codes expire?

No. A static code works for as long as the PIX key in it remains registered. Delete or rotate the key and every print of that code stops routing — which is also how you retire one.

Can I get paid notifications with a static PIX code?

Not from the code itself. Payment confirmation for static codes comes from your bank or PSP statement or app notification. Per-transaction webhooks are a dynamic-code feature, because they require a PSP integration.

Is a dynamic PIX code the same as a dynamic QR link?

No. A marketing dynamic QR redirects a browser through a short URL. A dynamic PIX code's URL is fetched by the payer's banking app to retrieve a signed charge with amount and expiry — it is a payments API mechanism, not a redirect.