Static vs Dynamic QR
Static means the same printed code is scanned many times. Dynamic means a new payload is minted for a ticket. EMVCo encodes that as Tag 01 = 11 or 12. The Point of Initiation article is the on-the-wire companion to this operations page.
Static operations
Low setup: print once. Customer types amount. Reconciliation is weaker because every payment shares the same destination with no invoice in the QR unless you add Tag 62 later (unusual on paper).
Two synthetic examples
Static shape (Tag 01 = 11): amount is usually absent so the payer types it. Example fragment: …010211… without Tag 54.
Dynamic shape (Tag 01 = 12): include Tag 54 with a billed amount such as 5406125.00 (Tag 54, length 06, value 125.00). If you keep Tag 01 = 11 and also emit Tag 54, many wallets treat that as a defective sticker.
Dynamic operations
POS or app creates POI 12 plus Tag 54. Better matching to orders, more moving parts, must recompute CRC every time.
Try both in the studio
Generate 11 without amount and 12 with amount, decode both, scan both. That ten-minute test beats another paragraph of theory.
Recon and refunds
Static QR refunds often need the original issuer RRN from the acquirer, not something in the QR. Dynamic QR with a bill number in Tag 62 can match your order id immediately. Choose based on how you refund, not based on which page ranked on Google.
When static is the wrong product
High-value electronics, table-service restaurants with itemized bills, and any flow that already has an order id should not rely on the customer typing 1850 versus 18500. Use dynamic 12.
When dynamic is wasted cost
A tea stall with no POS and no order numbers does not need a billed QR. Static 11 plus staff watching the amount screen is enough if overlay risk is managed.
Mapping to Tag 01
Read the Point of Initiation page before you ship. This page will not repeat the 11/12 bit table; it will keep repeating that operations and bits must match.
Choose from refunds and tickets, not from SEO
Static 11-codes are cheap and survive a power cut. Refunds usually need the acquirer RRN, not something in the QR. Dynamic 12-codes with Tag 54 and a Tag 62 bill number match your order id immediately and reduce “customer typed 18500 instead of 1850.” High-value electronics and itemized table service should not rely on keypad amounts. A tea stall with no POS often should.
The wrong reason to pick dynamic is “Google likes the word dynamic.” The wrong reason to pick static is “we already printed 400 stickers” if those stickers are collecting amount disputes. Operations owns the choice; Tag 01 must match it.
Leaving both codes on the counter
The day you turn on billed QR you must change Tag 01 to 12, start sending 54, and retire the old 11 plate. Guests will scan whichever symbol is closer to the till. Dual live codes are an incident, not a migration strategy. Cover or destroy the sticker the same day the POS screen goes live.
Screen QR that still encodes 11 without 54 is not “dynamic” just because pixels move. Dynamic means the payload is for one transaction (method 12) and the amount is in the string. Animate a static payload and you have a blinking sticker.
Idempotency and fraud monitoring differ
Hosts should treat 12-codes as single-use even if the customer scans twice. Static 11-codes are inherently multi-use; monitoring then looks at velocity toward one MAI, not at QR uniqueness. Mixing those models in a fraud engine produces either false declines on stickers or replays on billed QR.
Test both shapes in the studio. Keep two QA payloads labelled 11-no-amount and 12-with-amount. Re-scan after every generator release. Mapping to bits is on the Point of Initiation page; this page stays on the shop-floor choice.
Print cost versus dispute cost
Static looks cheaper until you count keypad mistakes and overlay replacement. Dynamic looks expensive until you count the POS you already run. Write the expected ticket value and dispute rate on the same slide as Tag 01. Then implement the bits. EMVCo’s QR specs describe the encoding; they do not tell you which product to sell. We do not either — we show both so you can verify them.
Finance and ops on the same slide
Static lowers print cost; dynamic lowers keypad dispute cost. Put both numbers on the same decision memo with Tag 01 written explicitly. If finance picks static but the POS already prints tickets with totals, you will collect “customer paid wrong amount” tickets forever. If ops picks dynamic but the shop has no order ids, Tag 62 will be empty and recon will still be painful. The encoding follows the business choice, not the other way around.
Seasonal and campaign QR
Pop-up stalls and festival booths often want static stickers for speed. Ticketed events with assigned seats often want dynamic billed QR tied to Tag 62. A campaign that prints static codes but advertises fixed prices on a menu board is still static — do not call it dynamic because the menu changed. Rename the business model, then rename Tag 01.
Metrics that should move when you switch
After moving static → dynamic, keypad amount disputes should fall and Tag 62 match rate in settlement should rise. If neither moves, you probably left 11 on the sticker. Measure before blaming wallets.
Sticker inventory
Treat obsolete static plates like obsolete keys: collect and destroy them when billed QR goes live so night staff cannot accidentally display the wrong POI.
Tag 01 is a two-character method, not a slogan
Value 11: the same payload is intended to be reused. Value 12: the payload is generated for one transaction. Other values are not for merchant-presented stickers. If Tag 01 is missing, many parsers assume nothing and some wallets reject the QR.
Tag 54 coupling
Static 11: omit Tag 54 so the customer types the amount, unless your scheme documents a fixed-price static QR (rare). Dynamic 12: include Tag 54 with the exact amount. Putting both 11 and Tag 54 causes apps to disagree — some lock the amount, some ignore it, some error.
Worked fragments
Static start: 000201010211… (00=01, 01=11). Dynamic start: 000201010212… then later 5405 followed by the amount characters. After any edit, recompute Tag 63.
Testing
Generate one 11 payload without amount and one 12 payload with amount in the EMV studio. Decode both and confirm Tag 01. Scan both with a wallet: 11 should prompt for amount; 12 should show the embedded amount.
Spec source
Point of Initiation Method is defined in EMVCo’s QR Code Specification for Payment Systems. This site is independent of EMVCo and only explains how our generator/decoder treat 11 and 12.
Why wallets care
A wallet uses Tag 01 to decide whether to show an amount keypad. If you lie with 11 but include 54, some wallets hide the keypad and some ignore 54. That is not interoperability; that is undefined behavior you caused.
Migrating a shop from sticker to POS
The day you turn on billed QR you must change Tag 01 to 12, start sending 54, and stop printing the old 11 plate. Leaving both codes on the counter is how guests pay the wrong one.
Test record
Keep two payloads in your QA notes labelled 11-no-amount and 12-with-amount. Re-scan after every generator release. See also static vs dynamic for the business choice.
Tag 01 is the method the wallet branches on
Value 11: reusable, customer typically types the amount. Value 12: one-time / billed, Tag 54 should lock the amount. Wallets use this bit to decide whether to show a keypad. If you lie — 11 with 54, or 12 without — some apps hide the keypad, some ignore 54, some refuse. That inconsistency is not “interop”; it is undefined behaviour you caused.
This is different from the Static vs Dynamic explainer, which is about shop operations (stickers versus POS tickets). This page is about the two-character field. You need both pages: bits without operations still print the wrong object; operations without bits still encode the wrong method.
Worked fragments you can paste into Decode
A static fragment starts …010211… and has no 54 later. A billed fragment starts …010212… and includes a Tag 54 such as 5406125.00 for 125.00 in the Tag 53 currency. After you generate a full string in the studio, confirm those substrings match the product you meant. If you see 010211 and 54 in the same payload, fail the release.
Optional Tag 62 bill number does not turn a static code into a billed one. Only Tag 01=12 plus amount does. Bill number is recon metadata. Mixing those jobs is how cashiers think “we are dynamic” while customers still type totals.
Migrating a shop without a week of double-pay
Ship the POS change, switch Tag 01 to 12, emit 54, and physically retire the 11 sticker the same day. Leaving both on the counter is how guests pay the old plate. Train staff that a screen showing a QR is not automatically billed — they should glance at whether the amount is locked in the customer’s app.
Keep two payloads in QA notes labelled 11-no-amount and 12-with-amount. Re-scan after every generator release. Spec source: EMVCo QR documents on emvco.com. We implement the bits; we are not affiliated.
Training cashiers in one sentence
If the customer must type the amount, the code must be static 11 without 54. If the amount is on the receipt and must not change, the code must be billed 12 with 54. Anything else is a training failure waiting for a dispute. Post that sentence next to the till, not a paragraph about EMVCo.
Spec quotes belong on emvco.com
We do not paste normative POI text here. We describe behaviour wallets exhibit: 11 → keypad, 12 → locked Tag 54. When your legal team wants the exact wording, download QRCPS. When your QA team wants a test, use the studio and Decode on this site with labelled 11-no-amount and 12-with-amount fixtures.
Audit POI in production
Sample live stickers monthly: decode three random codes from the field. If any show 11+54 or 12 without 54, stop rollout and retrain stores. POI drift happens when marketing reprints without engineering review.
One-line QA gate
CI should fail if Tag 01 is not 11 or 12, or if (01==11 and Tag54 present) or (01==12 and Tag54 absent). That single rule prevents more production incidents than any CRC tweak.
