UPI QR code generator
A payment QR that opens the payment sheet correctly in Google Pay, PhonePe, Paytm, BHIM and Amazon Pay — validated against how each app actually parses the URI, before you print it.
upi://pay?pa=cafeandheri@example&pn=Cafe%20Andheri&am=250.00&cu=INRCurrency locked to uppercase INR — Google Pay silently uppercases, so we encode it correctly from the start.
Google Pay✓ Opens
PhonePe✓ Opens
Paytm✓ Opens
BHIM✓ Opens
Amazon Pay✓ Opens
The cross-app compatibility matrix
Every wallet parses upi:// URIs differently. We simulate the documented behaviour of each before you download — and the matrix never shows a pass for something that fails.
These verdicts are about parsing: whether each wallet opens this URI and fills the payee and amount in correctly. Nobody can be paid by the sample above — its address is a reserved example, so it resolves to no bank — and no column on this table would tell you that, because none of them measures whether money moves.
| Parser behaviour | Google Pay | PhonePe | Paytm |
|---|---|---|---|
| Malformed URI | Rejects outright | Attempts repair | Rejects |
| Missing payee name (pn) | Refuses to open | Opens | Falls back to VPA |
| Missing currency (cu) | Assumes INR | Tolerates | Requires encoding |
| Unencoded spaces | Rejects | Tolerates | Rejects |
| Amount past 2 decimals | Rejects | Rounds to 2dp | Rejects |
Maintained as a versioned config with a public changelog, re-verified quarterly against the live apps. Every release is manually tested in all five wallets on Android and iOS.
Rules version 2.
Standee formats, print-ready
The sheet sizes and proportions a merchant standee is printed at, composed by our own renderer. We do not check them against NPCI's circular and we do not certify them: the mark's placement and sizing rules are the regulator's, and reviewing a template against them is a manual step that has not been taken. Print these as artwork, not as an assurance.
Payment QR beyond India
The same correctness discipline, applied to every major national standard.
All four are merchant-presented
In EMVCo terms these are merchant-presented mode: you display the code, the customer scans it. Consumer-presented mode — where the customer's wallet shows a rotating code to your scanner — is generated inside the wallet app, not by us, and no printable asset exists for it. If someone asks you for a "CPM QR", they need their payment app, not a print shop.
UPI QR code questions
Why does my UPI QR work in PhonePe but not Google Pay?
Google Pay is the strictest parser — it rejects malformed URIs, requires a payee name, and silently uppercases the currency. PhonePe tolerates most of those mistakes, which is exactly how a broken code passes a casual test and then fails at the counter. We validate against Google Pay first.
Is it safe to print my UPI QR from a website?
The URI is built deterministically from what you type, encoded in your browser, and shown to you in full above the preview. No AI ever generates or modifies a payment payload, and we never hold keys or touch funds.
Fixed amount or open amount?
Fixed suits priced items and invoices — the customer cannot mistype. Open suits counters with variable bills. Either way the amount is enforced to two decimals at input, because the apps disagree about anything else.
Do I need the NPCI standee format?
If you display the BHIM UPI mark, the circular’s placement and sizing rules apply. We have not reviewed our templates against it, so check your printed layout against the current circular before you display the mark.
Can a UPI QR be dynamic?
The payment URI itself is static by design — it must work offline in every wallet. What you can make dynamic is the standee’s companion code (a menu or review link). Never route a payment through a redirect.
We generate payment URIs and print assets. We are not a payment aggregator, PSP or TPAP — no merchant funds pass through us, we hold no keys, and we never touch settlement.