Add UPI ID

The name shown to the payer. Most apps OVERRIDE this with the name their own system holds for the VPA, so a mismatch here is usually invisible — and is worth testing for exactly that reason.
Google Pay and PhonePe have both been observed to display the bank-registered name instead of this value. Some apps reject names containing characters outside a narrow set.

Transaction amount in rupees, decimal, two places. Absent means the payer types the amount.
Whether the amount is EDITABLE by the payer differs by app and by whether mam/mode are present. Recording "amount editable" separately from "amount correct" is why the result recorder has both.

ISO 4217 currency. UPI is INR-only today; the field exists in the specification and some validators insist on it.
Only INR is meaningful. A non-INR value is a good negative test: several apps ignore it rather than refusing.

A free-text note shown to the payer and usually carried into the bank statement narration.
Length limits differ sharply by app; values over ~50 characters are frequently truncated. Some apps strip punctuation.

The MERCHANT'S OWN reference for this collection. The lab generates a fresh one for every run, which is what makes two runs distinguishable in a bank statement.
Required by several apps when mc is present. Uppercase alphanumeric is the subset accepted everywhere; lowercase and separators have both been observed to be rejected.

The ISO 18245 four-digit category of the merchant. It describes what KIND of business is being paid.
PRESENCE OF mc CHANGES APP BEHAVIOUR. Several apps switch from a P2P flow to a merchant flow when it appears, which changes limits, the fee display and sometimes whether the amount is editable. An arbitrary mc does NOT make you a registered merchant and the lab never treats it as proof of one.

A floor the payer may not go below when the amount is editable.
Only semantically meaningful when the amount is editable. Supplying mam together with a fixed am is contradictory and the lab warns about it rather than silently sending it.

An https URL the payer's app may show as "invoice" or "order details".
Must be https. Several apps silently drop a non-https value, and at least one refuses the whole intent. The lab refuses anything but https here because a http:// value turns a payment link into a downgrade vector.

The merchant identifier issued by the acquiring bank or aggregator.
Only valid when it is the value your acquirer actually assigned you. Present in many bank-issued QRs alongside msid/mtid.

Identifies WHICH STORE of a multi-location merchant is being paid.
Meaningless without a matching mid. Reconciliation on the acquirer side keys on the triple mid/msid/mtid.

Identifies WHICH TERMINAL or counter within a store took the payment.
Meaningless without mid. A soundbox or static placard usually carries one.

How the payment was initiated — the two-digit code that tells the PSP whether this came from a QR, an intent, a collect request and so on.
Mode codes are assigned by NPCI and are meaningful only in combination with the channel that actually initiated the payment. Declaring a mode the lab did not actually use is a false statement to the PSP, so the lab offers only the codes that match the launch mechanism of the method being run, and defaults to omitting it.

The NPCI-assigned identifier of the organisation that SIGNED this payload.
ISSUED, NOT CHOSEN. The lab will never generate one. It can only be imported from a QR you were given, or typed in by someone who genuinely holds it. An orgid without a matching valid sign is not a signed payload.

A base64 signature over the payload, generated by the bank or PSP that issued it.
THE LAB NEVER CREATES, MODIFIES, RE-DERIVES OR BYPASSES A SIGNATURE. It can carry an imported one through byte-for-byte, and it will tell you plainly when an edit you made has invalidated it. There is no mode in which the lab claims a modified signed payload is still valid.

A transaction identifier generated by the PSP — not by the merchant and not by this lab.
Distinct from tr. tr is yours; tid is theirs. The lab will not invent one, because a fabricated tid either collides with a real transaction or is rejected, and neither outcome tells you anything useful.

A single-character purpose indicator used by some flows.
Rarely honoured by consumer apps. Included so an imported payload carrying one is understood rather than listed as unknown.

The payee's GST identification number.
Case-sensitive key: gstIn, not gstin. Most payment apps ignore these entirely; they matter to the acquirer, not the payer.

The invoice this collection settles.
Carried through to some acquirer reconciliation reports. Most payment apps ignore these entirely; they matter to the acquirer, not the payer.

Date of the invoice, ISO-8601.
Format varies in the wild; ISO-8601 is the safest. Most payment apps ignore these entirely; they matter to the acquirer, not the payer.

Tax split, pipe-delimited, as issued by the invoicing system.
Case-sensitive key with an unusual capitalisation; a lowercased copy is silently ignored. Most payment apps ignore these entirely; they matter to the acquirer, not the payer.

Paytm's own identifier for a QR it issued.
Preserved exactly when imported. The lab will not generate one and cannot tell you what a given value means — only Paytm can.

An app-assigned identifier seen in some issued payloads.
Preserved on import; never generated.