UPI QR Code Generator

A UPI QR code generator built for real payments, not a generic square

Type "UPI QR code generator" into a search bar and most of what comes back is the same tool rebuilt a dozen times: a text box, a QR code that spits out, and no real handling of what makes a UPI code different from any other block of black-and-white squares. A UPI QR code isn't just a link — it's a small, structured payment instruction that a banking app has to parse correctly, which means the fields matter, the format matters, and a payment QR code generator that treats it like plain text will eventually hand someone a code that opens the wrong app, drops the amount, or simply doesn't scan. This page exists for the version of that search that actually needs the details right: a fixed or open amount, a payee name that shows up correctly at the other end, a note field for "Shagun" or "Stall 12," and a UPI ID validated against the format real banking apps expect — not just checked for an @ symbol.

What follows is the part most generators skip entirely: what a UPI code actually contains, how it's different from the QR code printed on your own bank's debit card statement or plastered on a shopkeeper's counter, when to fix the amount versus leave it open, which apps actually read it, and the one security distinction — pay versus collect — that matters more than anything else on this page. If you only read one section, read the one about collect requests below. Everything here applies whether you're printing a single code for a wedding reception desk or handing several to different vendors working the same event, and none of it requires any technical background beyond knowing your own UPI ID.

What a UPI QR code actually encodes

A UPI QR code is a visual encoding of a UPI deep link — a string that starts with upi://pay? followed by a handful of parameters, each one a specific piece of payment information. When a banking app's camera reads the code, it doesn't take a photo and guess; it parses that string directly into the fields on its own payment screen. Four parameters do almost all the work:

• pa (Payee Address) — your UPI ID, also called a VPA (Virtual Payment Address), in the familiar handle@bank format, like riya@okhdfcbank or vendorshop@ybl. This is the only field that's genuinely required — everything else is optional context around it.
• pn (Payee Name) — the name that shows up on the payer's confirmation screen before they approve the transaction. This is what a guest actually sees and trusts, so it's worth setting deliberately rather than leaving it blank and letting the app fall back to whatever's on file for that UPI ID.
• am (Amount) — an optional fixed amount. Set it and the payer's app opens with that number already filled in; leave it out and the app opens with the amount field empty for them to type in themselves.
• tn (Transaction Note) — a short line of text, like "Shagun," "Gift," or "Table 4 order," that appears in the payment confirmation and often in both parties' transaction history afterward. Small detail, genuinely useful for reconciling who paid what later.

That's it — no bank account number, no IFSC code, no card details ever pass through a UPI QR code. The whole point of the UPI ID system is that it's a proxy: your bank maps that handle to your actual account on their end, and the handle is the only thing that ever needs to be shared publicly, printed on a card, or scanned by a stranger. A UPI ID can be safely handed out on a wedding invitation, a shop counter, or a poster the way an account number never should be.

UPI ID formats, and why validation actually matters

A UPI ID always follows the pattern handle@psp — a handle you chose or were assigned, an @ symbol, and a short code identifying the payment service provider or bank behind it. Common endings include @okhdfcbank, @okaxis, @ybl (PhonePe-issued), @oksbi, @paytm, and @upi, among dozens of others banks and apps issue. Where to find yours: open your UPI app, go to your profile or "My QR code" section, and the ID is displayed right there — every UPI-enabled bank account has one, whether or not you've ever needed to look at it.

Loose validation is where a lot of free generators quietly fail. A tool that only checks for the presence of an @ symbol will happily generate a code from notarealid@nowhere — syntactically fine, functionally useless, and the failure only surfaces when a guest scans it at the reception desk and their app can't resolve the payee. Proper validation checks the structure against the actual pattern UPI apps expect: a non-empty handle, an @ symbol, and a recognized PSP suffix. It won't catch a typo in the handle itself — no generator can know your UPI ID is riya and not riyaa — but it will catch the malformed strings that are certain to fail before a single guest ever scans the code. Always test a generated UPI code with a real banking app before it goes anywhere near print, exactly the same discipline as testing any other QR code before a full run.

How a UPI QR code differs from your bank's own QR code

The QR code your bank shows in its app, or the one printed on a shop's counter placard from a bank-issued sticker, encodes the exact same underlying UPI standard this tool does — same upi://pay? format, same fields, same apps able to read it. The difference isn't in what it does; it's in what you're allowed to do with it. A bank-issued code is generally a fixed asset: it's tied to whatever the bank's backend generated, it usually can't be restyled, resized as a clean vector, or have a logo added without it becoming an unreadable mess, and changing anything about it — the amount, the note, the payee display name — usually means going back to the bank's app or portal to regenerate it from scratch.

A UPI QR code generator built for events gives you the same functional code with the presentation layer opened up: match the colors to your wedding invitation, drop in a small monogram or business logo, choose whether the amount is fixed or left open, write your own note text, and export it as a crisp SVG that stays sharp whether it's printed on a 3cm card or a 30cm reception-desk sign. Functionally, a guest's phone can't tell the difference between a code from your bank's app and one from a generator like this — both decode to the same upi://pay?pa=... string. The generator just gives you control over how it looks and what's pre-filled, which a bank's own tool typically doesn't.

Common UPI handle suffixes, in case you're trying to recognize or double-check one:

None of these are exclusive to the app that issues them in the sense of who can pay to them — a @ybl ID can receive money from a Paytm or BHIM user just as easily as from PhonePe, since the suffix only identifies which PSP the receiving account is registered through, not who's allowed to pay into it. It's worth knowing regardless, mainly so a suffix that looks unfamiliar doesn't automatically read as suspicious — it's most likely just a bank or app you don't personally use.

Fixed amount vs. open amount: which one to use

This is one of the first real decisions a UPI code forces, and the right answer depends entirely on the context it's being used in.

When to set a fixed amount

Set the am field whenever the amount is genuinely known ahead of time and non-negotiable: a ticket price at the door, a fixed stall item price, a specific contribution amount you've agreed with a vendor. The payer's app opens with the number already filled in — most apps still let them edit it before confirming, but pre-filling removes the friction of typing it themselves and reduces the chance of an accidental wrong amount. For a small business running a stall at an event — food, crafts, merchandise — a fixed amount per item, or a separate code per price point, moves a line along noticeably faster than everyone typing in their own total.

When to leave it open

Leave the amount field blank for anything where the payer is meant to choose — and shagun is the clearest example of exactly this. A wedding shagun QR code with a fixed amount printed into it can read as presumptuous or oddly specific about how much a guest should give, which runs against the entire point of shagun being a personal, voluntary gesture. Leaving the amount open lets each guest type in whatever they'd like, exactly as they would when handing over a cash envelope, while still getting the convenience of a scan instead of fumbling for exact change or a blank envelope at the door. The same logic applies to a general gift-contribution code, or a tip jar at a vendor's stall — anywhere the amount is genuinely up to the giver rather than fixed by the event.

Where a UPI QR code actually earns its place at an event

Wedding shagun and cash gifts

Shagun has traditionally meant an envelope of cash handed over at the reception — and increasingly, that envelope is being replaced or supplemented by a UPI payment QR code maker placed at the welcome desk or gift table. A guest scans, their app opens with your name already showing as the payee, they type in whatever amount they'd like, add a note if they choose, and confirm — done in under fifteen seconds, with no one at the desk handling cash, counting envelopes, or worrying about a stack of them going missing in the shuffle of a busy reception. It also solves a real logistical problem: out-of-town guests or anyone who simply didn't carry cash can still give in the traditional spirit, just digitally.

Gift contributions and registries

For a group gift — colleagues chipping in for a joint present, a class contributing toward a teacher's farewell gift, friends splitting the cost of something larger — a UPI code posted in a group chat or printed on a card removes the usual back-and-forth of "send it to this number" repeated to every single contributor. One code, one scan, done, with the note field doubling as a lightweight label ("Farewell gift," "Anniversary fund") so it's clear what the payment is for on both ends.

Vendor payments

Event vendors — caterers, decorators, photographers, the mehendi artist — increasingly prefer UPI for the same reason everyone else does: instant settlement, no cash handling, no waiting on a bank transfer's processing time. A vendor's own UPI QR code, generated with their business name as the payee and a note field pre-set to something like "Advance" or "Balance payment," gives an event planner or host a clean way to settle a bill on the spot rather than chasing a bank transfer down after the fact.

Small-business stalls at an event

Any small business or stallholder working an event — a food stall, a craft vendor, a pop-up shop at a fair or a wedding's mehendi station — benefits from the same setup: a UPI code with the business name as payee, either a fixed amount per common item or left open for variable totals, displayed at eye level where it won't get jostled or covered by other signage. For a stall doing repeat sales all day, a laminated, well-lit, correctly-sized code at the counter genuinely speeds up the line compared to everyone typing a UPI ID in by hand.

Which apps actually read a UPI QR code

Any UPI-compliant app can scan and process a standard upi://pay? code — this isn't proprietary to any one platform, and a code generated here isn't tied to or optimized for a specific app over another. In practice, the apps a guest is most likely to be using are:

• Google Pay (GPay) — one of the most widely used UPI apps in India; a GPay QR code generator search usually just means "a UPI code that opens correctly in Google Pay," which any standards-compliant code does, including the ones from this tool.
• PhonePe — similarly dominant, and often the app people mean when they search for a PhonePe QR code generator specifically; again, no special format is needed — a standard UPI code opens in PhonePe exactly the same way it does in any other UPI app.
• Paytm — reads the same standard code, with its own UPI handle format (commonly ending in @paytm) if that's the account being paid into.
• BHIM — the National Payments Corporation of India's own reference UPI app, and the closest thing to a baseline for what "standards-compliant" means in the first place.
• Bank apps — nearly every major Indian bank's own app now includes UPI scan-and-pay built in, reading the same code without needing a separate payments app at all.

Because the format is a shared, NPCI-governed standard rather than something each app implements its own way, a single code generated here works identically across all of them — there's no such thing as "a code that only works with Google Pay" unless something's actually gone wrong in how it was generated. If a guest reports that a code won't open in their specific app while it works fine in yours, the far more likely explanation is a malformed UPI ID or a corrupted scan than an app-specific incompatibility — see the troubleshooting section below.

Security: the difference between a "pay" code and a "collect" request

This is the single most important thing to understand before publicly displaying any UPI QR code, and it's the part most generic QR guides never mention because they're not written with payments in mind.

UPI supports two fundamentally different transaction directions. A pay request — the upi://pay? format this tool generates — is initiated by the payer: they scan your code, their app opens with your details pre-filled, and money moves from their account to yours only after they actively confirm it with their own PIN. This is completely safe to print, display publicly, hand to strangers, or post in a group chat, because the payer is always the one in control of whether the transaction happens at all.

A collect request works the opposite way: it's a request sent from your side asking someone to authorize a payment out of their account to yours. Scanning or approving a fraudulent collect request — often disguised as something else, like a "refund" or a "verification" — can result in money leaving the victim's account, not the requester's. This is the exact mechanism behind the overwhelming majority of UPI-related scams in circulation today: a scammer sends what looks like a routine QR code or link, but it's actually a collect request, and approving it authorizes a payment out rather than confirming one in.

The practical takeaway: only ever generate and display pay-request QR codes — which is the only format this tool produces — never a collect request. If you ever receive a QR code or payment link from someone else and you're not certain which type it is, the safest habit is simple: never scan or approve anything that results in you entering your UPI PIN unless you are the one actively trying to send money, on your own initiative, to someone you already intend to pay. A legitimate payment received by you never requires you to enter your PIN — PIN entry is exclusively for authorizing money leaving your account. If an app ever asks for a PIN to "receive" a payment, that's the clearest possible signal something is wrong.

Displaying a UPI QR code at your event: placement and signage

Where a payment code gets placed matters more than it does for most other QR content types, mostly because paying is a slower, more deliberate action than joining a Wi-Fi network — a guest needs a moment of relative calm to pull out their phone, open a payment app, and confirm a transaction, which isn't the same environment as a quick scan-and-walk-past.

• Reception or welcome desk. The natural home for a shagun code — guests are already stopping there to sign a book or drop off a card, so a payment code sitting alongside doesn't add a detour. Print it at roughly 5-8cm across on a small standee or card holder, large enough to scan comfortably from arm's length without anyone needing to crouch or lean in.
• Gift table. A second, sensible spot for the same code — pairs naturally with a physical gift table for guests who'd rather give digitally instead of, or alongside, a wrapped gift.
• Vendor and stall counters. For a business or stallholder, the code belongs at eye level at the point of sale, not tucked below the counter — laminate it if the event runs outdoors or near food and drink, since a single stray splash on a paper printout can be enough to make the code unreadable at exactly the moment a queue is forming.
• Add a short instruction line. The same accessibility principle that applies to any QR code applies doubly here: a line like "Scan to send shagun" or "Scan to pay — UPI" removes the guesswork of what the code actually does, which matters more for a payment code than almost any other type, since guests are naturally more cautious about scanning something financial without knowing what it is first.

One placement mistake worth calling out specifically: don't rely on a single code for a large event with multiple entry points or a long guest line. A welcome desk queue moves faster with two or three identical printed copies spread across the check-in area than with everyone funneling toward one sign to scan the same code.

How to create a UPI QR code with this tool

Generating one takes four short steps, and the result is ready to download in seconds:

1. Enter your UPI ID. Type it into the UPI ID field in the format handle@bank — the tool validates the structure as you type and flags anything that doesn't match a real UPI ID pattern before you export it.
2. Set the payee name. Whatever you enter here is what shows up on the payer's confirmation screen, so use your actual name or business name rather than a nickname a guest might not recognize.
3. Decide on the amount. Fill in a fixed number for a known price or contribution, or leave it blank so each payer enters their own — see the fixed-vs-open guidance above for which fits your situation.
4. Add a note (optional). A short line like "Shagun," "Gift," or a stall/order reference — it appears in the payment confirmation and helps both sides identify the transaction afterward, particularly useful if you're collecting from many people and reconciling later.

From there, style it the same way you would any other code from this tool: pick colors from the Design tab that suit the event, add a logo if you want one — remember to bump error correction to at least Q, or H for anything sizeable, since UPI codes already carry more embedded data than a simple URL and a logo eats into that margin further — and export as SVG for anything printed at reception-desk or banner size, or PNG for a smaller card or a digital share. As with every code type here, none of it — UPI ID, amount, note — is ever sent to a server; the entire code is assembled and rendered directly in your browser.

A quick printing note specific to payment codes: because a UPI string carries more parameters than a plain URL, the resulting code sits in a denser module grid than, say, a Wi-Fi code — which makes testing at actual print size even more important than usual. Print a proof, scan it with two different apps, and confirm the amount and payee name both show up correctly before committing to a full batch of place cards or a large reception-desk sign.

Troubleshooting a UPI QR code that won't open the right app

• Nothing happens on scan, or it opens a generic browser instead of a payments app. Usually means the phone doesn't have any UPI-enabled app installed, or the default camera app isn't handing the recognized upi:// link off to one. Try scanning with a UPI app's own built-in scanner (Google Pay, PhonePe, and Paytm all have one) instead of the phone's general camera.
• The app opens but the payee name or amount is missing or wrong. Almost always a generation-side issue — go back and confirm the payee name and amount fields were actually filled in before the code was exported; a blank field simply won't appear on the payer's end. If the fields were filled in and it still shows nothing, the code may have been generated before a field was fully typed — regenerate it and retest.
• The app says the UPI ID is invalid or can't find the payee. Almost always a typo in the UPI ID itself, or a stale one — double-check it directly against your UPI app's profile screen, not from memory, since even a single wrong character sends it looking for an account that doesn't exist.
• It works on one phone but not another. Since the format is a shared standard, this is far more often a scanning issue than an app-compatibility one — test with the phone's default camera app first, then with the UPI app's own scanner, since some default camera apps handle deep links less reliably than the payment app's dedicated scanner does.
• The code looks fine on screen but fails once printed. Check contrast and size first — a UPI code's denser module grid is less forgiving of low contrast or an undersized print than a simpler code would be; see the size and contrast guidance in the main guide above, and always test the actual printed card, not the on-screen preview.
• A logo was added and now it won't scan. The error correction level likely wasn't raised to compensate — bump it to Q or H depending on logo size before re-exporting; see the error-correction section in the main guide for the specifics.
• The app opens the right payee but shows a different bank than expected. A single person can hold more than one UPI ID, each tied to a different linked bank account — this is normal and not a sign anything's wrong. What matters is whether the UPI ID itself matches the one you intended to generate the code from, not which bank happens to be displayed alongside it.
• The scan is slow or takes several attempts to register. Usually a size, contrast, or lighting issue rather than anything wrong with the data encoded — a UPI code's denser grid gives a camera less margin than a simpler code, so check the size and contrast guidance above before assuming the code itself is faulty.

The bottom line

A UPI QR code is a small, well-defined piece of payment infrastructure disguised as a black-and-white square — get the payee address right, decide deliberately between a fixed and an open amount, use the note field for anything you'll want to reconcile later, and never, under any circumstance, generate or approve a collect request instead of a pay request. Get those right and a UPI code at a wedding reception, a gift table, or a vendor's stall does exactly what it's supposed to: turns a slow, cash-dependent handoff into a five-second scan, with the same security a bank's own QR code carries and none of the restriction on how it looks.