Many payment QR codes in shops follow a format published by EMVCo, the organisation behind the chip-card standards. EMVCo's QR code specifications "standardise the data format of QR codes for payments". They describe what is inside the code. What happens after the scan, such as processing and messaging, is left to the payment providers.

Two modes

  • Merchant-presented: the merchant shows the code (on a sign, a sticker or a till screen) and the customer scans it with a payment app.
  • Consumer-presented: the customer shows a code on their phone and the merchant scans it.

EMVCo lists version 1.1 of both specifications, published 27 November 2020, with later bulletins for individual fields.

What is inside

The content is plain text made of data objects. Each object is a two-digit ID, a two-digit length and then the value. Below is an invented example (a made-up scheme and café, not a real merchant) that is built in this way:

00020101021226240011com.example0105ABC12520458125303978540512.505802BG5909Test Cafe6005Sofia6304B902

IDMeaningIn the example
00Payload format indicator: the version of the template01
01Point of initiation: 11 for a static code, 12 for a dynamic one12
26Merchant account information: defined by the payment scheme, so each scheme has its own structure insidemade up
52Merchant category code (ISO 18245)5812
53Transaction currency, a 3-digit numeric code978
54Amount, present in dynamic codes12.50
58Country code (ISO 3166-1 alpha-2)BG
59Merchant name, up to 25 charactersTest Cafe
60Merchant city, up to 15 charactersSofia
63CRC checksumB902

Static and dynamic

A static code (01 = 11) is printed once and usually has no amount, so the customer types it in. A dynamic code (12) is generated for one payment and can carry the amount. This is a different meaning from "static and dynamic" for ordinary QR codes, which is about whether a link can be changed later; see static vs dynamic QR codes.

The checksum

The last object is a CRC. It uses polynomial 1021 (hex) and the initial value FFFF (hex), and covers all data objects before it, including the ID and length of the CRC itself (6304). If a character is changed, the checksum no longer matches and a payment app can reject the code. The example above was checked with this calculation.

Why a camera app is not enough

EMVCo's page notes that in merchant-presented mode the data is payment-specific, so a dedicated payment app is generally needed; a generic camera app typically cannot use it. Scanning one with the BestQR decoder shows the text, which is useful for learning, not for paying.

What you see before you pay

The standard marks the merchant name as something that should be displayed to the customer. In practice that is the check you have: read the name in your payment app before you confirm. The code is only data; it does not prove who printed or stuck it.

National schemes

Some countries build their own standard on top of this format. The Bank of Tanzania's published TANQR standard is one example: it states that it is based on the EMV merchant-presented QR code and sets its own rules for the scheme-specific fields.

What BestQR does and does not do

BestQR's payment generators make ordinary QR codes that open a payment page or link. They do not produce EMVCo payment payloads, which need to be issued within a payment scheme.

Sources

Last updated and checked against the sources on 13 October 2026. Standards change, so check the source for the current wording.

Frequently asked questions

Is a payment QR code the same as a normal QR code?

The symbol is the same QR code. The content is different: a structured payload that payment apps understand, instead of a web address.

Can I make a payment QR code with BestQR?

No. BestQR makes ordinary QR codes. A payment QR code in this format has to be issued through a payment scheme or your bank.

How do I know a payment code is genuine?

The code only carries data. Check the merchant name your payment app shows before you confirm, and be careful with codes that look stuck over another one.

Related reading