# Payment QR code amount not prefilled

> Each scheme carries the amount in a different field — UPI uses am=, PIX uses EMV tag 54, and EPC uses an EUR amount line. If the field is absent the app asks the payer to type the amount, and some apps let payers edit static-code amounts regardless. Regenerate with the amount filled.

Source: https://useqr.app/docs/troubleshooting/payment-qr-amount-not-prefilled · Last reviewed 2026-08-21 · UseQR is free forever, MIT licensed, no signup.

---

## 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](/upi-qr-code) |
| PIX | EMV TLV tag `54` | Fixed 2 decimals | `540635.90` | [PIX generator](/pix-qr-code) |
| EPC (Girocode) | Line 8 of the payload | `EUR` + amount, 0.01–999999999.99 | `EUR12.50` | [EPC generator](/epc-qr-code) |

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](/scan) 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](/docs/payments/qr-payment-standards-compared)
and, for UPI specifically, in
[static vs dynamic UPI QR](/docs/payments/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.

## Try it

- https://useqr.app/upi
- https://useqr.app/pix
- https://useqr.app/epc
- https://useqr.app/validate