Static vs. dynamic payment QR codes in EMV merchant-presented mode
A static merchant-presented payment QR code is intended to be shown for more than one transaction. A dynamic code is intended to be newly shown for each transaction. In EMVCo’s merchant-presented format, root field 01 uses 11 for static and 12 for dynamic when the field is present.
Compare two checkout examples
Picture a fictional café with a printed test code on the counter. The first code stays on the counter for the next customer. At a second test station, the checkout creates a new code for each sale. The first setup illustrates reuse, while the second illustrates per-transaction presentation.
Both examples are merchant-presented because the seller displays the code and the customer scans it. The static or dynamic distinction describes how often a new code is shown.
Read field 01 in the outer payload
In a test fragment, 010211 means field 01, a length of 02 and a value of 11. The corresponding dynamic fragment is 010212. Each fragment illustrates just one field and cannot be used as a payment code.
Use the field breakdown to find 01 at the root level. For example, an 01 inside the additional data template can have a different meaning. Searching for the digits anywhere in the raw text can pick up part of a different field.
The base EMVCo specification makes root field 01 optional. If it is missing, record that field 01 is absent and consult the relevant payment scheme before drawing a conclusion.
Compare two authorized fixtures in EMV QR Reader
Open your two test codes in EMV QR Reader and look at the reported static or dynamic information and tag breakdown. Compare what the reader reports with the fixture’s expected root field and the way your test checkout generated it.
For each sample, record the expected behavior and the value found. If the two differ, check whether you selected the intended fixture or read a field within a template.
Check the amount and transaction separately
Read the transaction amount in its own field. A static or dynamic label alone does not establish the amount, expiry, reuse enforcement or whether a transaction succeeded. Use the payment provider’s transaction record to check an actual payment.
Questions
Does a dynamic code always include an amount?
Read the amount separately. The point-of-initiation value describes how the code is shown, and the applicable payment scheme can define additional rules.
What if field 01 is missing?
In the base merchant-presented specification the field is optional. Record its absence and check the applicable scheme before assigning a type.