KHQR Code Decoder & Validator — Decode Bakong QR

About this tool

The KHQR Decoder takes a KHQR (Bakong) payment payload — the string of digits and letters behind a scanned QR code — and breaks it down into its readable fields: the Bakong account ID, merchant name, city, currency, amount, and any additional data such as bill number or store label. It also verifies the CRC-16 checksum so you can see whether the payload is intact or may have been corrupted or tampered with. Everything runs in your browser; the payload you paste is parsed locally and never sent to a server. It is a reading and validation tool, not a payment tool: it does not move money, does not contact the Bakong network, and cannot confirm that an account ID inside the payload actually exists or belongs to the merchant named in it. Use it to inspect a code you received, check a generated payload before printing, or learn what each part of a KHQR string means.

How it works

The decoder parses the payload as TLV (tag-length-value) fields and verifies the CRC-16 checksum computed over the payload. It first strips the trailing CRC field (last eight characters, tag 63) and parses the remaining fields; it then checks the mandatory structure: payload format indicator 01, merchant account information (tag 29 for individual accounts, tag 30 for merchant accounts, or any tag in the EMVCo 02–51 range), merchant name (tag 59), currency (tag 53) and country code KH (tag 58). Known fields are labelled with their EMVCo/KHQR names and sub-fields inside the merchant-account, additional-data and language templates are expanded. The result reports whether the payload is valid, whether the checksum passed, and lists any missing or unexpected fields as errors. There is no network call, so nothing is verified against Bakong — validation here means structural and checksum validation only.

Use cases

• A merchant checking a KHQR payload a developer generated before printing payment labels
• A customer inspecting a QR code from an invoice to see the merchant name and amount before paying
• A developer debugging a KHQR implementation by decoding payloads field by field
• A cashier verifying that a displayed payment QR carries the store’s expected account and bill number
• A student learning the KHQR TLV structure by decoding real payloads
• An accountant checking whether a received QR contains a bill number that matches an invoice

Frequently asked questions

• Does a valid checksum mean the account is real or the payment will work?

  No. The CRC-16 checksum only proves the payload was not corrupted or altered after it was assembled. A payload can be perfectly valid and still contain a wrong, expired or non-existent Bakong account ID. Only your bank or the Bakong network can confirm the account, and only a real payment attempt proves the code works.

• Is this decoder official or connected to the Bakong network?

  It is an unofficial, fully local decoder. It follows the publicly published KHQR Content Guideline and the EMVCo merchant-presented QR structure, but it makes no call to any bank or to Bakong. If you need an official verification, use the Bakong app or the SDK published by the National Bank of Cambodia.

• What does an invalid CRC mean?

  It means the checksum recomputed from the payload does not match the checksum stored in the code, so the string was likely corrupted, truncated, or altered after it was created — or it was never a valid KHQR payload to begin with. Treat such a code as untrustworthy: do not scan it for payment without checking the source another way.

• Why does the decoder accept merchant-account tags other than 29?

  The KHQR guideline places the Bakong merchant-account template at tag 29 for individual accounts and tag 30 for merchant accounts, but EMVCo reserves the whole 02–51 range for merchant-account templates used by other schemes. The decoder accepts any tag in that range so it can also read non-Bakong EMVCo QR codes, and labels the tag it found.

• Does the decoder show the amount and currency?

  Yes. When present, tag 54 (transaction amount) and tag 53 (currency — 116 for KHR, 840 for USD) are decoded and shown with their human-readable values. A static KHQR has no amount field, which the decoder reports as simply absent rather than zero.

• What happens if I paste something that is not KHQR at all?

  The decoder reports the errors it found — for example a missing payload format indicator, missing merchant account information, an unexpected country code, or an unparseable TLV structure — and marks the payload invalid. It also verifies the checksum separately, so you can see whether the payload is structurally wrong or only corrupted.

Data and accuracy

Content last reviewed 13 October 2026