QR code payment standards around the world: PromptPay, PIX, UPI, and what agencies need to know

A client hands you a stack of materials for a new market launch: a table tent for a restaurant chain expanding into Brazil, a poster for a Singapore pop-up, a flyer for a Bangkok trade show booth. Somewhere on each one sits a QR code that isn't yours. It's a payment code, printed by the client's bank or point-of-sale provider, and the client wants to know two things: can you make it trackable like the marketing codes you build for them, and is it safe to put next to your campaign code on the same page.

Both questions come up more often than the QR code industry's own content admits, because most guides to QR payments are written for developers integrating one payment rail, not for agencies who need to recognise six different national schemes on sight and explain, in plain terms, why they don't work like a marketing QR code. This is that guide: what a payment QR code actually contains, the standard most of them share, how PromptPay, PIX, UPI, PayNow and DuitNow differ from each other and from Zelle, and the honest mechanical answer to "can we track this."

What a payment QR code actually is

A marketing QR code, the kind ScanKit generates, encodes a short URL. The phone's camera reads the URL, opens a browser, and a redirect server decides where to send the scan, optionally logging the scan on the way through. The code is a pointer. Everything interesting happens on the server after the scan.

A payment QR code is different in kind, not just in content. It doesn't point anywhere. It carries the transaction data itself, or enough of it to start one: a payee identifier, a currency, sometimes an amount, sometimes an expiry. When a banking app scans it, there is no redirect and no server lookup at scan time; the app parses the payload directly and shows the payment details it just read out of the code.

That distinction matters because it's the reason a payment QR code can't simply be wrapped in a tracking link the way a website URL can. There's nothing to redirect to. The code has to arrive at the paying app exactly as the bank or scheme operator generated it, or the app can't parse it.

The two codes look identical on the page but split apart the moment they're scanned.

1. The code is scanned. A marketing QR code and a payment QR code are indistinguishable to the eye at this point.
2. A marketing QR code's payload is a URL, looked up on a redirect server the moment it's scanned.
3. A payment QR code's payload is the transaction data itself, read directly by the banking app, with no server involved at all.
4. The marketing scan is logged and the phone lands on a tracked destination page.
5. The payment scan shows a confirmation once the transfer settles, with no scan record created anywhere.

Payment QR codes also split into two directions of use, and the terminology is worth knowing because clients will use it. In merchant-presented mode, the merchant displays a printed or screen-shown code and the customer's phone scans it, which is the mode nearly all agency work touches: table tents, till stickers, invoice codes. In consumer-presented mode, the customer opens their banking app, generates a code on their own screen, and the merchant scans it with a till scanner, the reverse flow used at some retail checkouts and transit gates. Agencies only need to worry about the first.

The standard most national schemes build on

Most of the national "scan to pay" codes an agency will encounter, PIX in Brazil, PromptPay in Thailand, PayNow in Singapore, DuitNow in Malaysia, BharatQR in India, are built on the same base: EMVCo's Merchant-Presented Mode specification, first published in 2017 by the card-network consortium that also governs chip-card standards. Each country then adds its own domestic payment data inside a reserved slot in that base structure, which is why the codes look and behave similarly from country to country even though the underlying bank rails are entirely separate.

Structurally, an EMV payment QR code is built from tagged data blocks, each with a two-digit ID, a length, and a value. An agency doesn't need to read the raw payload, but knowing the shape helps when a client's finance team asks why their code "won't work" with a generic QR generator: the payload carries a point-of-initiation flag that marks the code as static or dynamic, a merchant account information block in the range reserved for domestic scheme data (this is where PIX, PromptPay and the others each register their own identifier format), a currency code, a country code, and a checksum. Change any of that data with a generic tool built for marketing codes and the checksum breaks, and the banking app will reject the code outright rather than silently mis-paying, which is at least the safe failure mode.

Static vs dynamic payment QR codes

The same static-versus-dynamic distinction that matters for marketing QR codes shows up in payment QR codes, but the stakes are different.

A static payment QR code encodes just the payee's account identifier, nothing else. It's printed once, reused indefinitely, on a till sticker or a table tent, and the customer types in the amount themselves inside their banking app after scanning. It's cheap to produce and never expires, which is exactly why it's the version most small merchants use, and exactly why it's the version fraudsters target: a static code carries no amount, no expiry and no transaction reference, so a fraudulent code substituted in its place is functionally indistinguishable from the real one until the money doesn't arrive where it should.

A dynamic payment QR code is generated per transaction, with the amount, a transaction reference and a short expiry baked in, then discarded after use, similar in spirit to a dynamic marketing QR code but generated by a point-of-sale system rather than a marketing platform. It closes the fraud window a static code leaves open, but it has to be regenerated for every sale, which is why it shows up at staffed checkouts with a till system behind it rather than on an unattended table tent.

Neither version is "trackable" in the sense an agency means for a marketing campaign. There's no scan log, no timestamp, no location data, because there's no server involved at scan time to record any of that. Whatever reporting a client gets on a payment QR code comes from their payment processor's settlement data, not from the code itself.

A country-by-country map

The schemes below all handle domestic instant payments, and an agency working across markets will run into most of them eventually.

PIX (Brazil). Brazil's instant-payment scheme, operated by the Banco Central do Brasil, has required its QR payload, known as BR Code, to follow the EMV Merchant-Presented Mode structure since October 2020. A static PIX code carries only the payee's key (a phone number, email, tax ID or random token); a dynamic one adds the amount, a transaction ID and an expiry, and can push payment confirmation back into the merchant's own reconciliation system automatically.

UPI and BharatQR (India). India runs two different QR formats side by side, and conflating them is a common mistake in QR content aimed at agencies. A UPI QR code encodes a upi://pay deep link, a URI intent rather than an EMV payload, and only opens inside UPI-compatible apps such as Google Pay, PhonePe or Paytm. BharatQR is the true EMV-based format, built jointly by India's National Payments Corporation with Visa, Mastercard and Amex, and is interoperable across both card and UPI rails in a single code. UPI QR dominates by volume, roughly ten codes deployed for every one BharatQR code as of early 2025, despite BharatQR being the more universally interoperable of the two.

PromptPay (Thailand). Thailand's national instant-payment rail, run by the Bank of Thailand, uses an EMV-based merchant-presented code for retail and till payments, and was one of the first national schemes to link with a neighbour: PromptPay and Singapore's PayNow began supporting real-time cross-border transfers between the two systems from April 2021.

PayNow / SGQR (Singapore). Singapore's SGQR is explicitly documented by its regulators as built on the EMVCo Merchant-Presented Mode spec, and functions as a unifying label: a single SGQR sticker can consolidate multiple underlying payment schemes (PayNow, plus various card and e-wallet rails) behind one code, so the customer's app picks the right rail automatically rather than the merchant needing to display five separate codes.

DuitNow (Malaysia). Operated by PayNet, the national payment network overseen by Bank Negara Malaysia, DuitNow QR launched in December 2018 and follows the same EMV merchant-presented structure, with Malaysia's country and currency codes and a DuitNow-specific account identifier in the domestic data block.

Zelle (USA). Zelle is the useful contrast case, because it looks similar at a glance but works nothing like the schemes above. It is not EMV-based, not independently scannable by a generic QR reader, and only opens from inside a Zelle-enabled banking app. It identifies a specific person-to-person recipient rather than a merchant payment endpoint, is US-only, and isn't available at every participating bank. If a client asks whether their US payment QR code "is the same standard" as PIX or PromptPay, the honest answer is no: Zelle sits in a different category entirely, a proprietary peer-to-peer intent scheme rather than a national merchant-presented rail.

The pattern worth remembering: national instant-payment QR codes (PIX, PromptPay, PayNow, DuitNow, BharatQR) are merchant-presented, EMV-based, and country-specific but structurally standardised. Bank-app-locked person-to-person codes (Zelle, and functionally UPI QR proper) are proprietary intent schemes, not independently interoperable, and shouldn't be described to a client using the same language.

Can you make a payment QR code trackable?

No, and it's worth explaining why rather than just saying no, because the mechanical reason is what stops a client asking again on the next campaign. A payment QR code's payload is the transaction: the account identifier, the currency, sometimes the amount, is data the paying app reads and acts on directly. A marketing QR code's payload is a URL, and the tracking happens on the server the URL points to, entirely separate from what the phone displays. There's no equivalent step in a payment flow to attach a redirect to. Insert one, and the banking app either fails its checksum validation and rejects the code, or, in the case of a UPI-style URI intent, simply fails to match the expected scheme prefix and won't open at all.

This is the same structural gap covered in more depth for Europe's SEPA-based GiroCode, and the answer generalises: no current standard, anywhere, combines a payment payload with campaign-level scan tracking in one code. What an agency can offer instead is the honest workaround: a marketing QR code, tracked as normal, that leads to a page where the client's actual payment QR code is displayed, or the two codes placed as clearly separate elements on the same piece, one to browse, one to pay. A restaurant menu QR code sitting next to a till's payment code is the everyday version of exactly this pairing, and it works precisely because the two codes are never merged into one.

The fraud risk agencies need to flag before print

A static payment QR code has no server checking it at scan time, which means there's no way to detect or block a tampered code after it's printed. That gap is being actively exploited. US authorities have issued repeated public warnings since January 2022 about criminals placing fraudulent QR stickers over legitimate ones on parking meters, restaurant tables and public signage, redirecting payments (or credentials) to accounts they control. In the UK, reported QR code fraud rose roughly fourteen-fold over five years, and a documented case in Redondo Beach, California found around 150 parking meters fitted with counterfeit QR overlays placed directly beside the legitimate payment stickers.

The practical implication for an agency is that this isn't a problem a QR platform can fix after printing, because the vulnerability lives in the physical print, not in the code's logic. It sits alongside the broader guidance on QR code security for agencies: specify tamper-evident printing for anything carrying a payment code (raised or embossed print, or lamination that visibly tears if a sticker is peeled), keep payment codes checked on-site rather than trusting a single install-and-forget placement, and where the client's payment provider offers dynamic, per-transaction codes over static ones, recommend the dynamic version for anything unattended.

Frequently asked questions

What's the difference between a PromptPay QR code and a marketing QR code?

A PromptPay code encodes the payment data directly, following Thailand's EMV-based merchant-presented format. A marketing QR code encodes a URL that redirects through a tracking server, with no payment information in the code itself.

Can I make a PIX, UPI or PromptPay QR code trackable like a ScanKit code?

No. The code already carries the payee and transaction data the banking app needs; wrapping it in a redirect breaks the checksum or the app's expected format, so the code stops opening.

Is a static or dynamic payment QR code more secure?

Dynamic codes are more secure. They're single-use, amount-locked and short-lived, which closes the window a static, reusable code leaves open for a swapped or counterfeit sticker.

How does a PIX QR code work in Brazil?

PIX uses BR Code, Brazil's EMV-based merchant-presented format. A static PIX code carries only the payee's key and needs the amount entered manually; a dynamic one adds the amount, a transaction ID and an expiry.

What's the difference between UPI QR and BharatQR in India?

UPI QR encodes a upi://pay app-specific link and only opens inside UPI apps. BharatQR is the true EMV-based format, interoperable across card and UPI rails in one code. UPI QR is far more common, by roughly ten to one as of early 2025, despite BharatQR being the more interoperable standard.

Is Zelle's QR code the same as PayNow or PIX?

No. Zelle isn't EMV-based and only opens inside a Zelle-enabled banking app; it identifies a specific person rather than a merchant. PIX, PromptPay, PayNow and DuitNow are national, EMV-based merchant rails; Zelle is a US-only, bank-app-locked peer-to-peer scheme.

What does "merchant-presented" versus "consumer-presented" mean for a QR code?

Merchant-presented means the merchant displays the code and the customer scans it, the mode used for nearly all agency and retail work. Consumer-presented is the reverse: the customer generates a code on their own phone and the merchant scans it.

How can I tell if a payment QR code has been tampered with?

Look for a sticker sitting slightly proud of the surface underneath it, mismatched print quality, or any code positioned somewhere the merchant wouldn't normally place one. Because static codes have no server checking them, physical inspection is the only real-time defence.

Can a single QR code handle both payment and marketing tracking?

Not currently. No widely used standard combines a payment payload with campaign-level scan tracking in one code. The practical fix is two codes placed clearly apart, one tracked marketing code, one payment code, rather than trying to merge them.

What currency and country codes appear in an EMV payment QR code?

Currency is encoded using the numeric ISO 4217 standard (for example, Brazilian real as 986, Malaysian ringgit as 458), and country uses the two-letter ISO 3166-1 code (BR, MY, SG, TH, IN).

Are QR code payments interoperable across borders?

Mostly not, though links exist: Singapore's PayNow and Thailand's PromptPay have supported real-time cross-border transfers since April 2021. Most national schemes otherwise remain domestic-only, so a code generated for one country's rail won't be recognised by another country's banking apps.

The short version

A payment QR code carries the transaction itself; a marketing QR code carries a link to one. That's the whole reason they can't be merged, whatever a client asks. Most national schemes an agency will meet abroad, PIX, PromptPay, PayNow, DuitNow, BharatQR, share the same EMVCo merchant-presented structure with country-specific data inside it, while Zelle and UPI's own app-locked format sit apart as proprietary, bank-app-only schemes. When a static payment code goes up anywhere public, treat it the way you'd treat any unattended sign: specify tamper-evident printing, check it on-site, and keep it visually and functionally separate from the tracked marketing code doing the actual campaign reporting.