A QR code that shows a fixed amount and one generated fresh for every order look identical at the counter, but they solve different problems and carry different compliance weight. This guide is about UPI QR used for collecting payments, not the retailer cash-withdrawal QR, which is a separate, already-regulated case covered below.
Static QR and dynamic QR: what actually differs
| Static QR | Dynamic QR | |
|---|---|---|
| Amount | Fixed or blank; the payer types the amount | Generated with the exact order amount already encoded |
| Reference | None built in; matching is manual | Carries a transaction reference the backend can match automatically |
| Lifetime | Printed once, reused indefinitely | Generated per order or session, typically set to expire |
| Reconciliation | By amount and rough time, error-prone at volume | By the embedded reference, one-to-one with the order |
| Typical use | A counter accepting varying, low-volume payments | Checkout flows, or any system that must tie one payment to one order automatically |
The core engineering difference is who does the matching. A static QR pushes matching work to a person, comparing a bank statement against a paper order book. A dynamic QR carries the reference itself, so the backend can match a payment notification to an order without asking anyone to look at anything.
Why a screenshot is never proof of payment
A payer can show a "payment successful" screen and still have the transaction fail, reverse, or never reach the payee's account. The only trustworthy signals are:
- A status check against the bank's or PSP's own API for that specific transaction reference.
- A callback or push notification your backend receives directly from the bank or PSP, not one relayed by the customer.
Treat every payment as unconfirmed until one of those two sources says otherwise. This is the same principle covered in more depth in payment API idempotency and reconciliation: never credit an order, release goods, or mark cash collected on the strength of what the payer's phone shows you.
A "customer showed me the screenshot" workflow is a common fraud pattern. Doctored screenshots and reversed transactions both look identical to a genuine, completed payment on screen. Confirm through your bank's or PSP's status API every time.
UPI limits to design around
Two limits matter for a QR-based collection flow:
- Peer-to-peer (P2P) UPI payments stay capped at ₹1 lakh a day.
- Peer-to-merchant (P2M) payments to verified merchants in certain listed categories, reported to include capital markets, insurance, travel, collections and government marketplace payments, can go up to ₹5 lakh per transaction and ₹10 lakh a day, from 15 September 2025, under NPCI's circular of 28 August 2025. Government broadcaster News On AIR reported the change; the exact list of eligible categories is reported by industry coverage and should be confirmed with your acquiring bank or PSP before you rely on it for a specific category.
- An ordinary, non-verified merchant VPA stays inside the normal UPI limits set by the paying bank and PSP.
If your business model needs the higher P2M ceiling, check with your bank whether your merchant category and verification status actually qualify. It is not automatic for every UPI-accepting VPA.
Deep links: keep it conceptual
A UPI QR encodes a payment intent that a UPI app reads and pre-fills: who gets paid, how much, and a reference for that specific transaction. The exact technical parameters belong to NPCI's and the banks' own specifications and can change. Rather than reproduce parameter names here that may be out of date, treat a UPI QR as an intent your customer's UPI app understands, and pull the current specification from your bank's or PSP's own integration documentation before you generate QR codes in production.
When you need someone else's authorisation
Your own VPA, your own bank
If the QR carries your business's own UPI ID at your own bank, and the money lands directly in your account, you are running plain software on top of your bank's UPI service. No separate payment licence is needed for this alone.
Pooling money for other businesses
If your platform collects into its own or a shared account and pays merchants out later, that is payment aggregation, PA-P for in-person collection, PA-O for online collection, and needs RBI authorisation as a non-bank Payment Aggregator under the RBI (Regulation of Payment Aggregators) Directions, 2025.
Working as someone else's technology partner
The alternative to holding your own PA authorisation is building and operating the software as the technology partner of a bank or an already-authorised Payment Aggregator, who holds the licence and the merchant relationship.
The 2025 Directions (press release, Master Direction) do not mention UPI or QR by name, so this is our own reading of how their PA-P/PA-O definitions apply to QR collection. Confirm the specific structure with your own legal adviser before you build a pooled-collection product.
The UPI cash withdrawal QR: a special, already-defined case
One dynamic-QR use case already has its own settled framework: UPI-based cash withdrawal at Micro ATM and BC touchpoints, enabled by NPCI circular NPCI/UPI/OC-225/2025-26 (7 October 2025). Secondary coverage of that circular (Complinity) reports caps of ₹5,000 per transaction, ₹10,000 per day and ₹50,000 per month, with two-factor authentication on every withdrawal. Treat these figures as reported until you have read the circular.
In the Payonclick platform, this flow is implemented with a per-transaction range of ₹100 to ₹5,000 in ₹100 steps, and daily and monthly ceilings of ₹10,000 and ₹50,000 per customer, limits coded against NPCI's framework for this route. This is a withdrawal, not a merchant collection: the flow pays cash out to the customer rather than collecting money for a merchant, and it sits under different rules from the P2M limits described above.
Where Payonclick fits today
The only dynamic QR in the Payonclick platform today is inside UPI cash withdrawal: the platform server-renders a QR for that specific withdrawal request, and it expires in about 60 seconds. It exists so a customer can authorise a cash withdrawal from their own bank account through UPI, not to collect a merchant payment.
A merchant collection QR, one that takes payment for goods or services and settles into a business's own account, does not exist in the platform today. Building one would be custom development, designed around your own bank account or an authorised Payment Aggregator's rails, rather than something available as a standing dynamic QR API.