Payment QR code amount not prefilled

Where each scheme carries the amount

"The amount doesn't come up" has one diagnosis path across all three major schemes: decode the code, and look for the scheme's amount field.

Scheme	Amount lives in	Format	Example	Regenerate
UPI	am= query parameter	Positive, max 2 decimals	am=149.99	UPI generator
PIX	EMV TLV tag 54	Fixed 2 decimals	540635.90	PIX generator
EPC (Girocode)	Line 8 of the payload	EUR + amount, 0.01–999999999.99	EUR12.50	EPC generator

If the field is missing from the decoded payload, the app has nothing to prefill. It will show the payee and ask the payer to type an amount. That is legal in all three schemes: the amount is optional in a static code, and open-amount codes are a legitimate pattern for tips, donations and pay-what-you-owe counters.

Cause 1: the field was never encoded

The most common case by far. The generator's amount box was optional, someone left it blank, and the resulting code is an open-amount code. Decode with our scanner and check: no am=, no tag 54, an empty line where EUR… should be. The fix is a regeneration with the amount filled in, using the links in the table.

Cause 2: the field is there, but malformed

Each scheme is strict about number format, and a malformed amount is typically ignored rather than flagged:

• Thousands separators: am=1,499.00 is not a number to a UPI parser. Digits and one decimal point only.
• Too many decimals: three decimal places breaks all three schemes; UPI and PIX and EPC all specify at most 2.
• Currency symbols in the value: am=₹150 fails; the currency travels separately (cu=INR for UPI, tag 53 = 986 for PIX, the literal EUR prefix for EPC).
• PIX only: the payload's CRC16 checksum must be recalculated after any change, a hand-edited amount with a stale checksum invalidates the whole code.

UseQR's builders enforce all of this: amounts are validated as positive decimals with at most 2 places, PIX amounts are emitted in tag 54 with the checksum recomputed, and EPC amounts are rendered as EUR plus a 2-decimal value within the scheme's 0.01 to 999,999,999.99 range.

Cause 3: the app treats static amounts as editable

Even with a perfect payload, some apps present the amount as a prefilled but editable field on static codes: the payer can change it before paying. UPI apps commonly behave this way with static merchant codes, and static PIX codes are explicitly open to payer edits in many banking apps. This is scheme behaviour, not a bug you can encode around. If the amount must be non-negotiable (invoices, exact-price goods) the honest answer is a dynamic, transaction-generated code from your bank or payment provider, which binds the amount server-side. The trade-offs between the schemes' static and dynamic modes are compared in QR payment standards compared and, for UPI specifically, in static vs dynamic UPI QR.

The check before printing

Decode the finished code and read the field against the table above, then test-scan with the actual app your payers use and confirm the amount appears. Two minutes now saves a standee reprint later.

FAQ

Why does my UPI QR code not show the amount?

Either the am= parameter is missing or malformed (commas, symbols, more than 2 decimals), or the app is treating a static code's amount as editable. Decode the code: if am= is absent, regenerate with the amount; if present and correct, it is app behaviour.

Can the payer change the amount on a static payment QR?

Often yes. Many UPI and PIX apps present static-code amounts as editable before payment. If the amount must be fixed, use a dynamic code generated per transaction by your bank or payment provider, which enforces the amount server-side.

Where does a PIX code store the amount?

In EMV TLV tag 54, as a fixed two-decimal value, for example 5406 followed by 35.90. Editing it by hand invalidates the CRC16 checksum at the end of the payload, so always regenerate rather than editing the string.

What is the amount format in an EPC (Girocode) QR?

A dedicated line reading EUR followed by the amount with up to two decimals (EUR12.50) valid from 0.01 to 999999999.99. Left empty, the banking app asks the payer to enter the amount manually.