Method · 10 min read
UPI QR codes for a small business: what to print and what to check
What a UPI QR code really contains, when to bake in an amount and when not to, and the four-minute check that stops a printed counter code failing at the till.
A shopkeeper prints a UPI QR from a free site, tapes it to the counter, and for three weeks it is fine. Then one customer says the code will not scan at all, another says their app came up with ₹450 when they owed ₹120, and nobody behind the counter can work out whether those are the same problem. They are not, and both were avoidable before anything went to the printer.
This is about the mechanics: what a UPI QR actually contains, when to bake in an amount and when not to, how to check your own code before it is printed a hundred times, and how to tell a scanning fault from a banking one. It is not advice about fees, settlement, limits for your particular account or which kind of account you should hold. Your bank answers those.
What is actually inside the code
A UPI QR code holds one line of text. That is the whole thing. No account is created, nothing is registered with anyone, and there is no server in the middle. The line looks like this:
upi://pay?pa=priya@okaxis&pn=Priya%20Sharma&cu=INR
A phone camera reads that text, sees the upi:// prefix and hands it to whichever UPI app is installed. The app reads the fields and fills in its own payment screen. There are only six fields worth knowing:
| Field | What it is |
|---|---|
| pa | Payee address — your UPI ID, the name@bank string. Required. This one field is the code; everything else is presentation. |
| pn | Payee name. Required. What the customer sees on the confirmation screen before they approve. |
| am | Amount in rupees. Optional. Digits with up to two decimals, so 250 or 250.00. |
| cu | Currency. INR, and only INR. |
| tn | Transaction note. Optional short text that appears in the app and on the statement. |
| tr | Reference. Optional. Your own invoice or order number, for matching payments later. |
Two things follow from that. The code cannot expire, because it holds nothing but your own UPI ID — there is no redirect to switch off and no trial to run out. And it cannot be edited after printing, so the day your UPI ID changes, every printed copy becomes scrap.
Amount baked in, or amount typed by the customer
This is the one decision that actually matters, and the right answer is different at a counter and on an invoice.
| Where it goes | Amount |
|---|---|
| Shop counter, table tent, delivery rider’s card | Leave it blank. One code serves every sale. The customer types what you tell them. |
| An invoice, a quote, a one-off job | Bake it in, and add the invoice number in tr. The code is printed once, for one amount, and then thrown away. |
| One fixed-price thing — an entry fee, a single ticket, a deposit | Bake it in, one code per price, each labelled with the price in large text next to it. |
Why a permanent counter code should not carry an amount
- It will be wrong. Prices change. The laminated card does not. A printed amount is a price list you cannot update, in the one place where being wrong costs you money.
- Customers stop reading. Once someone learns that the code fills itself in, they stop checking the number and approve whatever appears. You have trained them out of the only safeguard on the screen.
- Real transactions are not one price. Part cash, part UPI. A rounded-down total. Two items instead of one. A fixed amount forces the customer to fight the screen for every sale that is not the exact printed figure.
- It does not even guarantee the number. Whether a prefilled amount can be edited before approval varies by app and version. That is exactly the sort of thing a till should not depend on.
The sensible exception is a second, separate code for one genuinely fixed item, clearly labelled. Two codes on a counter is fine. Six is a mess, and the customer will scan the wrong one.
Verify the code before you print it
This is the step everybody skips and everybody then discovers at the till, usually with a queue. It takes about four minutes.
- Read the decoded payload, character by character. The UPI generator in QR Studio shows the exact string it is about to encode. Read the pa field the way you would read an account number, because that is what it is. okaxis and oksbi look identical when you are in a hurry and belong to different banks.
- Check the payee name is a name. The pn field is what the customer sees. If it matches the shop sign, they can cross-check it. If it says “Shop”, they have nothing to compare against, which is the gap every QR-swap scam lives in.
- Scan it on screen, from a second phone. Before any printing at all. If you have only one phone, scan it from a laptop screen with that phone.
- Send yourself ₹1. This is the only step that proves the money reaches the account you believe it does. A code can scan perfectly, show the right name, and point at a UPI ID that was deactivated when you changed banks. Then check the ₹1 actually arrived.
- Print one, and scan the print. Paper is not a monitor. Ink bleed, thin lines, low contrast and a glossy finish all fail on paper and never fail on screen.
Then order fifty.
Printing and placement
A counter code is read by a tired person holding a phone at arm’s length in bad light. Design for that person, not for the mock-up.
| Thing | Number |
|---|---|
| Size | Roughly a tenth of the reading distance. A counter is read from 30–40 cm, so 30–40 mm is the floor. Print 50–60 mm; it costs nothing more and covers cracked screens and old cameras. |
| Quiet zone | Four modules of blank light border on all four sides. Never crop tight to the pattern. |
| Contrast | Dark pattern on a light ground, 4.5:1 or better. Not white-on-black: iPhones read inverted codes, many Android scanners do not. Not bright red either — it reads as light to a lot of phone cameras. Maroon is safe. |
| Logo in the middle | Under about a fifth of the area, and only with error correction raised to H. At the usual level M the budget is nearer 7%. |
| Lamination | Matte. Gloss under a tube light produces exactly the white blowout that hides a third of the pattern. The film costs the same. |
Content length changes the density, and density changes how far away the code can be read. A bare pa plus pn code comes out at 29×29 modules. Add a long transaction note and a reference and the same code becomes 49×49 — nearly three times as many modules in the same physical square, so each one is much smaller and the scan distance drops. Leave tn empty on anything permanent.
Mount it vertically, at chest height, facing the customer. Flat on the counter is worse: they have to lean over it and their own head casts the shadow. Keep it off the glass of a display case, away from a downlight, and not beside the card machine where the queue blocks it.
Print your UPI ID and payee name as plain text underneath. It does two jobs: a customer whose camera has given up can type the ID by hand, and anyone who wants to check the name their app showed has something to check it against.
Keep a laminated spare behind the counter. Printed codes get spilled on, peeled at the corner, and covered by somebody else’s sticker.
When a payment fails, find out which half broke
Failures split cleanly in two, and the dividing line is simple: did the app ever show your name?
| What the customer sees | Where the fault is |
|---|---|
| Camera never finds a code | The print. Glare, too small, cropped quiet zone, scratched surface. Hand them the spare and look at the mounted one afterwards. |
| App opens and says the code is invalid | The payload. Decode it and read it. Usually a mangled UPI ID, or an amount in a format the app rejects. |
| App shows a name that is not yours | The wrong code is on your counter. Take it down now and check it against your own print before anyone pays. |
| App shows your name, then fails at the PIN or after it | Their app, their bank or the network. The QR code did its whole job the moment your name appeared. Ask them to retry or pay another way. |
| App says success, you see nothing yet | Neither. Check your own statement before doubting the code. |
The sticker-over-your-code scam works precisely because a customer cannot tell the third row from the first. Look at your own code every morning, with your own phone. It is a physical object on a public surface and it deserves the same check as the till.
The honest bits
- The UPI ID must be yours, and verified by a real payment. Not one someone messaged you, not one a generator left in as an example, not one you typed from memory. A ₹1 test payment that you then confirm arrived is the only proof.
- No third-party generator can sign a UPI code. Signing needs a payment service provider’s key. UPI apps accept unsigned codes, and the vast majority of printed shop codes are unsigned. But if a bank or a platform tells you it requires a signed code for something, that has to come from them.
- Limits exist and they depend on your account. They differ by UPI ID, by bank and by the type of account behind it. Ask your bank what yours are before a busy Saturday finds out for you.
- Whether a personal UPI ID is the right thing to take business payments into is a question about your account, your bank and your bookkeeping. We are not the people to ask, and neither is a QR generator.
Everything else about styling, contrast checks and print sizes is the same as for any other code, and QR Studio shows the decoded payload and the warnings before you download rather than after.
Checklist
- Counter code: UPI ID and name only, no amount, no note.
- Invoice code: amount baked in, invoice number in the reference field.
- Read the decoded payload character by character before downloading.
- Payee name must be recognisable to a customer.
- Scan it on screen from another phone.
- Send ₹1 to yourself and confirm it arrived.
- Print one and scan the print, not just the file.
- 50–60 mm across, four-module quiet zone, dark on light, matte laminate.
- Vertical, chest height, out of the glare, with the UPI ID in text below.
- Laminated spare behind the counter, and a look at the mounted code every morning.