UPI Payment QR Code Generator for Shops, Stalls and Counters

The payment link, parameter by parameter

UPI runs on the rails NPCI operates, and the merchant-presented static code is a payment link in the NPAPI shape: upi://pay followed by parameters joined with ampersands. Your UPI handle is the pa parameter and says whose account the money goes to. The payee name, pn, is the label the payer app shows before anyone authorises anything. Those two are the required pair, and the remaining parameters are optional: am for the amount in rupees, cu for the currency, tn for the note the payer can see and sometimes edit, and tr for a transaction reference that rides along to the bank statement line.

Two details of how this tool assembles that link matter once you start relying on it. The first is that cu is always written as INR, so this is a rupee collection instrument and nothing else. The second is that an optional parameter you left empty is omitted outright instead of being sent as a blank value, which keeps the payload short and stops a payer app from displaying an empty note field.

Every value you type is percent-encoded before it goes in. A shop name with a space, an ampersand or a comma in it would otherwise break the link, because those characters are the delimiters of the format. Encoding turns them into plain data, so "Rao and Sons" arrives as one payee name rather than as a name plus a stray parameter.

A static code is not a payment gateway

This part needs saying plainly, because plenty of counters run on a printed UPI square and treat the buzz of a phone as proof of payment. A static QR is a request. When the payer app reports success, that is the payer side of the transfer, and nothing comes back to this code, to this site or to you. There is no payment confirmation, no callback, no webhook, no notification and no reconciliation. The only way to learn whether the money arrived is to look at your own bank statement or your PSP dashboard, on whatever schedule you check them.

Two consequences follow at the counter. First, a screen turned towards you is suggestive rather than conclusive: ask the payer to confirm the amount and your payee name are visible on that screen, and if you are releasing goods on trust or on credit, check your account before the customer leaves. Second, a day of credits with no names attached is not bookkeeping. If you need to match money to orders, put something identifiable in the reference parameter per order, and make a new code per order, or accept that you will be squinting at a list of identical rupee amounts at closing time.

Fixed amount, or let the payer type it

Leaving the amount empty is the simplest single-code setup: one printed square serves the whole shop, and the customer enters the total. It is also the least reliable. People mistype, they round down when the figure has paise in it, and a busy queue makes both mistakes more likely.

Pre-filling removes the decision entirely. The payer opens the code, sees the sum, and authenticates. The number cannot be wrong, which is why fixed-price items, tickets, deposits and set meals are worth a code each. The cost is that the amount is baked into the print: a new price list means new artwork, so keep each design as an SVG and reprint the whole sheet at once rather than patching one square on the counter and confusing everyone.

A middle path is to pre-fill the amount only where the price is genuinely fixed, and keep one unpriced code for general trade. Label the two squares differently in words, so a customer at a mixed till knows which one to use.

Before a printed code becomes your main till

• Above a small annual-turnover threshold, Indian merchant guidance requires dynamic QR codes with the amount pre-filled rather than one static print used for every sale. The threshold and the wording move, so check the current NPCI and RBI guidance for your turnover band with your bank or PSP before a static code carries all of your trade.
• Pay your own code a rupee and confirm which account the credit landed in. A mistyped handle sends money somewhere else, and recovery is slow.
• Do not lay a logo over the middle of a payment code or tint it. Payers hold the phone at arm length in a queue, and the pattern has to survive one scan, first time.
• Print the payee name in words under the code as well, so a payer who checks the confirmation screen can match it to your sign and is less likely to bail.
• Keep the code free of anything that identifies an account number or a personal handle you use for peer transfers. The VPA on a counter is the one you are happy to receive on.