Free EMV QR code generator

Build an EMVCo merchant-presented payment QR from a form. The TLV payload and its CRC-16 checksum are assembled in the order the specification requires, the symbol is rendered at error-correction level M, and Dynamsoft Barcode Reader reads the result back.

Test symbols, not real payments. The merchant identifiers and GUIDs here are illustrative and resolve to nobody, so a wallet will decline these codes — Randomize invents valid-but-fictional data, never an account. This generator covers merchant-presented mode only — consumer-presented mode, where the payer's phone shows the QR, is a different structure. Feed the downloaded PNG to the online EMV QR scanner to test the round trip.

Merchant and transaction

Shown verbatim — an unknown GUID is not an error.
ISO 18245, four digits.
Two fraction digits. Omitted on a static code.

Payment QR

EMVCo MPM v1.1

Not yet verified The payload above is rendered as a QR Code. To prove it scans, the symbol is decoded back and compared byte for byte.

Payload

Decoded field by field

Tag Field Value

What this covers

  • Merchant-presented mode. The merchant shows the QR and the customer scans it. This is the mode behind Pix, PromptPay, UPI, SGQR, DuitNow and most national schemes.
  • CRC-16/CCITT-FALSE. Computed over the payload including the literal 6304 that introduces it, but not the four hex characters it protects. Getting that order wrong yields a code that looks perfect and is rejected everywhere.
  • Ascending tag order. The specification requires top-level objects in ascending tag order, so the form does not choose the sequence — the model does.
  • The 99-character limit. TLV lengths are written as two digits, so no single field value can exceed 99 characters. Long merchant names fail here rather than in a wallet.
  • Error-correction level M. What EMVCo specifies for payment QR codes.

To read a real payment QR rather than make one, use the online EMV QR scanner, which parses the TLV payload field by field and checks the checksum.