EMV QR Testing
Testing is not “it scanned on my phone.” It is a matrix: payload rules plus the apps your customers have. Academy samples are drills, not merchants.
Payload checks
CRC valid. Tag 00 = 01. Tag 01 matches amount policy. Tag 53 numeric. Name/city lengths. MAI GUID is the production value.
App checks
Two local wallets, one bank app. Static amount entry vs dynamic locked amount. Photograph the success screen; do not rely on memory.
Negative tests
Bad CRC, alphabetic currency, 11+54 conflict, truncated city. Each should fail closed.
Tools
Generate here, decode here, scan devices. Scheme cert tools from your acquirer still apply.
Environment matrix
Test on at least one Android and one iOS wallet where both exist in your market. Camera quality changes truncation risk. Brightness changes screen QR contrast. A test that only uses this site’s decoder is incomplete.
Data that must differ per build
GUID, merchant name, and city should be your test merchant, not EMVQRHUB. If two builds share the cookbook sample, you cannot tell whether a wallet cached the first scan.
Regression set
Keep a folder of strings: last known good static, last known good dynamic, last known CRC fail, last known alphabetic Tag 53. Run them after every generator change. That is cheaper than rediscovering Tag 53 bugs in production.
When to involve the acquirer
If CRC, POI, and currency are correct and two independent wallets still refuse, it is almost always membership or AID. Escalate with the decoded MAI, not with a screenshot of the pretty QR.
What a payload-only test cannot prove
A CRC-valid string in Decode only proves the envelope is well-formed. It does not prove that a wallet in your market will open a pay screen, that the GUID is on that wallet’s allow-list, or that the acquirer will post to the intended merchant file. Treat decoder green as gate one. Gate two is at least two live apps. Gate three is a settlement report that matches Tag 59, MCC, and any Tag 62 bill number you sent.
Write those three gates into the test plan so a “QR looks fine” screenshot never closes a ticket. EMVCo publishes the QR specification family and testing programmes on emvco.com; this site is not a substitute for those programmes. We only give you a local encode/decode bench.
Camera, print, and screen as first-class variables
Phone cameras disagree on contrast, glare, and minimum module size. A payload that Decode accepts from a pasted string can still fail when the same payload is a 2 cm sticker under a plastic standee. Print at the size you will deploy, scan from a typical queue distance, then repeat with a second device. Screen QR on a dim POS needs a longer dwell; if cashiers rush the customer, you will collect “app cannot read” tickets that are lighting bugs, not TLV bugs.
Keep a photo of the official print in the operations folder. Overlay fraud and accidental reprints are easier to catch when staff can compare the live standee to a known-good image. Testing is not only CI; it is the physical object the camera will see.
Wallet matrix that actually matches customers
List the apps that together cover most of your tickets — not the apps your engineers prefer. One Android super-app plus one bank iOS wallet is a common minimum. If tourists are material, add one inbound wallet that is known to be picky about GUID. Record app name, OS version, and whether the scan used the in-app camera or a system camera hand-off; those paths parse the same string but surface errors differently.
When two wallets disagree, paste the same string into Decode and export the tag table. If CRC, Tag 01, Tag 53, and MAI look legal, the disagreement is membership or UX, not a reason to rewrite CRC code. Escalate with the raw payload, not with a cropped JPEG of the symbol.
Negative cases that belong in every release
Keep fixtures for: alphabetic Tag 53, Tag 01=11 with Tag 54 present, Tag 01=12 with Tag 54 missing, CRC last nibble flipped, Tag 63 not last, MAI outer length one character too long, and Tag 58 written as a country name. Each fixture should have an expected Decode verdict. If a generator change makes a negative fixture pass, you shipped a silent relaxation.
Do not reuse cookbook merchant names like EMVQRHUB in a certification build. Wallets and reviewers treat placeholder names as a smell, and you cannot tell whether a wallet cached an earlier scan of the same sample. Mint a test merchant whose MCC and city match the file the acquirer expects.
When the lab should stop and call the scheme
If CRC, POI, currency, country, and nested MAI parse cleanly on this site, and two independent production wallets still refuse, further TLV edits will not help. The next artefact is the GUID and AID the scheme registered for that merchant. Send the decoded MAI subtree, the raw string, and the wallet error text. Do not send a regenerated payload that “might work” unless you version it; otherwise the partner debugs a moving target.
Official pass/fail for a national QR programme still comes from that programme’s kit and from EMVCo’s published QR documents, not from emvqrhub.com. Use this academy to isolate grammar defects quickly so you only involve the switch when the grammar is already honest.
Definition of done
Done means: Decode pass, two-wallet pass, stored payload matches print, negative fixtures still fail, and a human signed the ops photo. Anything less is a demo, not a launch.