UPI QR code not detected by the payment app

Ranked causes — the payload is not a valid upi:// link (pa is the one mandatory parameter), the specific app rejects formatting it dislikes, the code is BharatQR rather than UPI, or the image is a degraded screenshot-of-a-screenshot. Decode the code, read the string, and regenerate from a spec-correct builder.

First, see what the app sees

Decode the code with our scanner and read the raw string. A working UPI QR contains a upi://pay link, and a correct one looks like this:

upi://pay?pa=merchant@upi&pn=Chai%20Point&am=149.99&tn=Order%2042&cu=INR

Everything below assumes you have this string in front of you. The causes, ranked by how often they are the actual problem:

1. The payload is malformed

pa is the one truly mandatory parameter — the payee's virtual payment address. A payload without it (or with a URL, a phone number, or plain text instead of a upi:// link) is simply not a UPI code, and payment apps ignore it rather than erroring. Common malformations, all visible in the decoded string:

Missing or misspelt scheme: upi:pay?… or UPI//pay?… instead of upi://pay?…
A pa value that is not a valid VPA — the shape is name@handle, like shopname@okaxis
Unencoded spaces or & inside pn or tn, which break parameter parsing
An amount with more than 2 decimal places or with commas (am=1,499)

The full parameter set — pa, pn, am, tn, mc, tr, cu — is documented in the UPI QR code format guide.

2. App-specific parsing quirks

The NPCI spec is one thing; each app's parser is another. Apps differ in how strictly they treat percent-encoding, unknown extra parameters, and reference formats (tr should be at most 35 characters of letters, digits, dots and dashes). A payload that one app tolerates, another rejects silently. The defence is not to chase individual apps but to emit a minimal, strictly spec-shaped payload — which is what UseQR's UPI generator does, validating the VPA shape, percent-encoding the name and note, capping the amount at 2 decimals, and always appending cu=INR.

3. It is BharatQR, not UPI

India has two merchant QR systems. UPI QR is the upi:// deep link above. BharatQR is an EMVCo TLV payload that also carries card rails. They look identical printed on a standee, but they are different formats — an app scanning for one may not accept the other, and bank-issued BharatQR standees are a common source of "my app doesn't detect it" reports. The decoded string settles it instantly: upi://pay?… is UPI; a long digit-led TLV string starting 000201… is EMVCo. The differences are unpacked in BharatQR explained.

4. The image has been degraded

A UPI code that circulates as a WhatsApp-forwarded screenshot of a photo of a printout has been recompressed several times. Each pass adds artefacts at module edges; eventually the finder patterns survive but the data does not, and apps see "a QR-like image" they cannot decode. The same applies to codes shrunk into low-resolution images. This is a generic failure — see image compression breaking codes — but payment codes suffer it most because they get reshared casually. Regenerate from the source and export clean, or print from SVG.

The rebuild

Enter the VPA and payee name in the UPI generator — generation is client-side, so payment details never leave the browser — then verify by decoding the result and, before printing a standee, test-scan from at least two different UPI apps. Printing guidance is in printing a UPI standee.

FAQ

Why does my UPI QR code not scan in GPay or PhonePe?

Decode it and read the string. If it is not a well-formed upi://pay link with a valid pa parameter, apps ignore it silently. Other frequent causes are a BharatQR (EMVCo) payload rather than UPI, or an image degraded by repeated screenshots.

Which UPI parameters are mandatory?

Only pa, the payee VPA, is strictly mandatory; pn (payee name) is expected by apps in practice. Amount (am), note (tn), merchant code (mc) and reference (tr) are optional. A currency of INR (cu=INR) should always be present.

Is a bank-issued shop QR the same as a UPI QR?

Often it is BharatQR — an EMVCo TLV payload carrying card rails as well as UPI — not a upi:// link. Most Indian payment apps handle both, but not all handle both equally, which explains codes that work in one app and not another.

Why does a screenshot of my UPI code fail?

Each screenshot-and-reshare cycle recompresses the image and erodes module edges until the data is unrecoverable. Share the original exported file, or regenerate the code, rather than forwarding photos of photos.