Let customers pay by scanning instead of typing account details. Works with a UPI ID or a PayPal account, with an optional fixed amount.
The real risk to a printed payment code is not interception, it is substitution: somebody covers yours with their own. Print the destination in words beside it, check the code by hand on a schedule, and prefer a page bearing your name over a jump straight into a payment app.
Enter content to generate QR code
Two shapes, chosen by the method dropdown. UPI produces a standard upi://pay request carrying your VPA, payee name and any amount, currency and note you set. A UPI app reads it, shows the payee and asks the customer to authorize. PayPal produces a normal checkout URL, so any camera opens PayPal’s payment page in the browser. Either way the code carries only payee details: it can receive, never withdraw.
UPI ID ana@examplebank, payee Ana Rivera, 250 INR, note Invoice 123, and the code holds:
upi://pay?pa=ana%40examplebank&pn=Ana+Rivera&am=250&cu=INR&tn=Invoice+123pa is the payee address, pn the payee name the customer sees before authorizing, am the amount, cu the currency and tn the note. A PayPal code is different in kind: an ordinary https checkout URL, which is why any camera opens it and a UPI code needs a UPI app.
Leave the amount blank and the customer types what they owe, which suits a register where every basket differs. Fill it in and the amount is locked in the request, which suits an invoice, a fixed-price item or a donation tier. A fixed-amount code printed at a register is the classic mistake, since it either has to be reprinted daily or gets overridden by hand, and both cost more time than they save.
The payee name you type is what the paying app displays before the customer authorizes. A store doing business as one name whose UPI account is registered in another will show the registered one, and that mismatch is exactly what makes a careful customer stop. Scan your own code with a real app and read the confirmation screen before it goes on the counter.
The real risk to a payment code is not interception, it is substitution: somebody stickers their own code over yours, and the money goes to them all afternoon. Laminate it, mount it where staff can see it, and check daily that the code on the counter is still yours by scanning it and reading the payee name. Any code that a customer questions should be replaced immediately rather than defended.
A UPI code is read by UPI apps, which is a mainly Indian ecosystem, so a phone camera outside it will simply show an unrecognized link. A PayPal code is a plain web address, so any camera on any phone opens it. Choose the method your customers actually have, and if you serve both, print two clearly labeled codes rather than one that half your customers cannot use.
The code carries only the details needed to send money to you (never credentials), and every payment is confirmed inside the payer’s own banking or PayPal app. The genuine risk is physical: someone covering your code with theirs. Check the printed code regularly by scanning it and reading the payee name.
Yes. Fill in the amount and it is encoded in the request, so the payer only confirms. Leave it blank for an open amount, which is what a register usually wants.
A UPI code needs a UPI app; a phone camera outside that ecosystem will not know what to do with it. A PayPal code is an ordinary web link, so any camera opens the PayPal checkout page.
No. The code is generated in your browser and the UPI ID or PayPal address never leaves your device. We hold no payment information of yours at any point.
No — the amount is part of the pattern. Print an open-amount code for anything that varies, and keep fixed-amount codes for one-off invoices and documents rather than counter signage.
Not at any stage. The transaction runs entirely between the payer’s app and your payment provider. We only draw the code.
Not for UPI: upi:// is a payment scheme rather than a web address, so a redirect has nothing to serve. A PayPal code is an ordinary https link and technically could be, but it should not be — a payment code that passes through a redirect is one more hop between the customer and a payee name they can check, and that is precisely the shape of the substitution scam these codes attract.