Can I make my own DuitNow, PayNow or QRIS merchant code?

No. Merchant payment codes carry an identifier issued by a licensed bank or payment provider, tied to a settlement account under a merchant agreement. Apply through your bank. A personal receiving code, where the scheme supports one, is generated inside your own banking app.

Why does one code work in some apps and not others?

Each app reads the merchant identifiers belonging to networks it participates in and ignores the rest. Unified schemes such as SGQR and QRIS exist precisely to solve this by carrying multiple identifiers, or by mandating one standard everyone must accept.

Can I pay a Thai merchant with a Malaysian app?

Only where the two national operators have established a cross-border link, and usually only through participating banks. It works because of a specific bilateral arrangement rather than because both use the EMVCo format. Check with your bank before travelling and assume nothing.

How do I avoid a tampered payment QR?

Read the payee name your app shows before confirming — it comes from the code and will be wrong if the sticker was swapped. Be wary of a code pasted over another, and check the amount. Merchants should periodically verify the sticker on the counter is still their own.

Is UPI different from the others?

Structurally, yes. UPI encodes a upi:// URI with query parameters rather than EMVCo's tag format, so scanning it triggers an app intent on the device. The others follow the EMVCo tag specification, which is why they can be combined into a single unified label.

Payment QR codes across Asia

Asia settled on QR codes for payments while much of the world was still tapping cards, and the result is a set of national schemes that look identical and are not interchangeable. Malaysia's DuitNow QR, Singapore's PayNow and SGQR, India's UPI, Thailand's PromptPay and Indonesia's QRIS each encode payment instructions that only their own banking apps understand. Most are built on the same EMVCo specification, which is why they look alike; UPI is the outlier, using a URI scheme rather than EMVCo's tag structure. The practical thing to know before you try to make one: a merchant payment QR must be issued through a licensed bank or payment provider, because it carries a registered merchant identifier that only they can allocate. A generic QR generator cannot produce one, and any tool claiming otherwise is producing something that will not work.

The common foundation: EMVCo

Most of these schemes implement the EMVCo QR Code Specification for Payment Systems, which defines a compact format of numbered tags: a payload format indicator, whether the code is static or dynamic, one or more merchant account identifiers, a merchant category code, the transaction currency as an ISO 4217 number, an optional amount, the country code, the merchant name and city, and a CRC checksum at the end.

That shared structure is why a Malaysian and a Thai payment QR look the same to a camera and why a single printed code can carry several schemes at once — the format allows multiple merchant account identifiers, each tagged for a different network. Singapore's SGQR is the clearest example, combining many schemes into one label.

What it does not give you is interoperability by default. A banking app reads the identifiers it recognises and ignores the rest. Cross-border acceptance — a Malaysian app paying a Thai merchant — exists where the two operators have specifically linked their networks, not as a property of the format.

The national schemes

DuitNow QR (Malaysia), operated by PayNet, is the national standard: one code accepted by every participating Malaysian banking and e-wallet app. Merchant codes are issued through banks and acquirers; consumers can also display a personal DuitNow QR from their banking app for transfers between individuals.

PayNow and SGQR (Singapore) route payments to a mobile number, NRIC or entity registration number rather than an account number. SGQR is the unified label that combines PayNow with other accepted schemes on a single sticker.

UPI (India), run by NPCI, is the structural outlier. A UPI QR encodes a upi://pay URI with parameters — pa for the payee address (the Virtual Payment Address, like name@bank), pn for the payee name, am for an amount, tn for a note. Because it is a URI, scanning it opens whichever UPI app is installed via an intent, which is why the ecosystem is so app-diverse.

PromptPay (Thailand) follows EMVCo and links payments to a mobile number, national ID or tax ID. QRIS (Indonesia), mandated by Bank Indonesia, unified a fragmented wallet market into one standard that every provider must accept — a single merchant code works with every Indonesian wallet.

Static and dynamic, in the payments sense

Payment QR codes use "static" and "dynamic" differently from the general QR meaning, and confusing the two causes real errors.

A static payment QR is the printed sticker on the counter. It identifies the merchant but carries no amount, so the customer types it in. One code serves every transaction forever, which is cheap and simple, and shifts the risk of a mistyped amount to the customer.

A dynamic payment QR is generated per transaction with the amount and a reference already in it, usually shown on a terminal or phone screen. The customer cannot mistype, and reconciliation is automatic because the reference ties the payment to the sale. This has nothing to do with a redirect service — the data is still fully encoded in the pattern.

For anything above trivial volume, dynamic is what you want, and it is what an acquirer's terminal or payment SDK produces.

Why you cannot generate a merchant code yourself

A merchant payment QR contains a merchant identifier allocated by an acquiring bank or licensed payment provider, tied to a settlement account, under a merchant agreement, subject to KYC. That identifier is what tells the network where money goes. It is not a value you can invent, and no generator can allocate one.

So a tool that offers to "generate a DuitNow QR" from a name and a phone number is producing a pattern that is either malformed or points nowhere. The correct route to a merchant code is your bank or a licensed payment provider, who will issue the code and the sticker.

Personal transfer codes are different: your own banking app can display a personal receiving QR, generated by the bank against your own account. That is the app's job, not a third-party generator's, and you should be sceptical of any site asking for banking details to make one for you.

The security point that follows is the one worth passing on: QR sticker replacement fraud is common across every one of these markets. Someone pastes their own code over a merchant's. Because the customer's app shows the payee name before confirming, the defence is simply to read that name — and for merchants, to check periodically that the sticker on the counter is still theirs.

What generic QR tools are legitimately for

Plenty of useful codes are not payment instructions, and those you can and should make yourself: a link to your online ordering page, your menu, a review or feedback form, your WiFi credentials for customers, your business contact details as a vCard.

These are static codes in the ordinary sense — the data is in the pattern, nothing expires, and no intermediary is involved. Pairing a bank-issued payment code with a self-made link code covers most of what a small business actually needs at the counter.

If you are printing either, test with more than one phone before committing to a print run, and leave the quiet zone — the blank margin around the pattern — intact. Crowding it is the most common reason a technically valid code fails to scan.

Last updated: 2026-08-07

Make a QR code for your link, menu or WiFi

For payment codes, go to your bank — these are the ones you can make yourself.

Frequently asked questions

Can I make my own DuitNow, PayNow or QRIS merchant code?: No. Merchant payment codes carry an identifier issued by a licensed bank or payment provider, tied to a settlement account under a merchant agreement. Apply through your bank. A personal receiving code, where the scheme supports one, is generated inside your own banking app.
Why does one code work in some apps and not others?: Each app reads the merchant identifiers belonging to networks it participates in and ignores the rest. Unified schemes such as SGQR and QRIS exist precisely to solve this by carrying multiple identifiers, or by mandating one standard everyone must accept.
Can I pay a Thai merchant with a Malaysian app?: Only where the two national operators have established a cross-border link, and usually only through participating banks. It works because of a specific bilateral arrangement rather than because both use the EMVCo format. Check with your bank before travelling and assume nothing.
How do I avoid a tampered payment QR?: Read the payee name your app shows before confirming — it comes from the code and will be wrong if the sticker was swapped. Be wary of a code pasted over another, and check the amount. Merchants should periodically verify the sticker on the counter is still their own.
Is UPI different from the others?: Structurally, yes. UPI encodes a upi:// URI with query parameters rather than EMVCo's tag format, so scanning it triggers an app intent on the device. The others follow the EMVCo tag specification, which is why they can be combined into a single unified label.