A UPI QR code with a fixed amount

What a fixed amount does

Add am to the UPI deep link and the payer's app opens with the amount already filled in:

upi://pay?pa=school@okaxis&pn=Sunrise%20School&am=15000.00&tn=Term%202%20fees&cu=INR

The behavioural detail that matters: the payer cannot edit a pre-filled amount. UPI apps treat am as merchant-set — the customer either confirms ₹15,000.00 or cancels. There is no field to retype, which means no mis-keyed digits, but also no flexibility if the price on the code is wrong.

am accepts up to two decimal places and rides with cu=INR — UPI settles in rupees only. A malformed amount (three decimals, a comma, a currency symbol) is the quickest way to produce a code that some apps silently refuse; if a code opens with an empty amount box, see payment QR amount not prefilled.

When fixing the amount is right

A fixed amount earns its place when the price is genuinely stable and the typo cost is real:

• Tickets and passes — one code per ticket tier, printed on the ticket or shown at the gate.
• Tuition and fees — a term fee of ₹15,000 mis-keyed as ₹1,500 is a reconciliation headache; locked amounts remove the failure mode entirely.
• Price lists and fixed menus — a code beside each item, each carrying that item's price.
• Parking, tolls, entry fees — posted single rates that change rarely and come with new signage when they do.

The common thread is that the amount is per thing, not per conversation. If the customer decides the total (a shop counter, a tip jar, a donation box), use an open-amount code instead.

The permanence trap

A printed fixed amount is as permanent as the paper it is on. Change the price and every standee, sticker and flyer carrying the old am is now wrong — and unlike a wrong menu, customers cannot override it. This is the core argument in static vs dynamic UPI QR codes: print fixed amounts only where the price and the signage change together.

Screens do not have this problem. A till or checkout page that generates a code per transaction can fix the exact bill every time, which is where fixed amounts do their best work.

One code per price, generated together

A price list needs one code per item. Build a CSV with a row per item — VPA, name, amount, and a distinct note — and generate the whole set with the bulk tool:

pa	pn	am	tn
stall@upi	Dosa Corner	60.00	Masala dosa
stall@upi	Dosa Corner	40.00	Filter coffee
stall@upi	Dosa Corner	100.00	Combo

The tn value appears on the payer's screen and in your statement, so settlement tells you what sold. For anything that needs per-transaction tracking — tickets especially — add a unique tr as well; see transaction references.

Each code is generated client-side and can be decode-verified before you print a hundred of them.

FAQ

Can the customer change the amount on a UPI QR code?

Not when the code sets am. UPI apps treat a pre-filled amount as merchant-set and lock the field — the payer can only confirm or cancel. To let customers choose the amount, generate the code without am.

How do I make a UPI QR code with a fixed amount?

Enter your VPA, payee name and the amount in a UPI QR generator. The amount becomes the am parameter of the upi://pay link, with up to two decimal places, and every scan pre-fills it.

Should my shop standee have a fixed amount?

Usually no. A printed amount becomes wrong the first time your price changes, and customers cannot override it. Fix amounts on per-item or per-ticket codes; keep the general counter code open.

Can a fixed-amount UPI code include paise?

Yes. The am parameter accepts up to two decimal places, so 149.50 is valid. More than two decimal places is invalid and some apps will reject the code outright.