Dynamic QR Code Payments for Websites: How They Work and Why They Win Online

Dynamic QR code payments are now the default way Indian websites accept UPI. Every time you check out on a Zomato, Swiggy, BookMyShow, or D2C brand's site and see a QR with the amount already filled in, you're using a dynamic QR. The technology behind it is straightforward once you understand the three-layer model: the QR encodes a per-order payment request, the gateway tracks the intent's lifecycle, and webhooks notify your site when payment lands. This article unpacks each layer with the precision a builder needs.

The three layers of a dynamic QR payment

When you 'add dynamic QR payments to your website', you're actually setting up three coordinated layers:

• The QR payload — a UPI URI encoded as a QR image, containing your merchant identifier, the exact amount, and a unique order reference.
• The intent lifecycle — your gateway tracks the QR's state from creation through payment (or expiry), giving you a single source of truth.
• The webhook notification — the gateway pushes payment success to your backend so your application can fulfil automatically.

Each layer can be replaced independently — you could use one gateway for the QR generation and another for webhook delivery, in principle — but in practice you pick a gateway that does all three coherently.

Layer 1: The payload

A dynamic UPI QR is a QR image encoding a URI in the format `upi://pay?pa=...&pn=...&am=...&tr=...&cu=INR`. The key fields:

• pa — merchant VPA (e.g. yourbrand@bank).
• pn — your business name shown to the customer.
• am — amount, prefilled and non-editable in the customer's UPI app.
• tr — transaction reference (your order ID or the gateway's intent ID).
• tn — short note shown to the customer (e.g. 'Order 12345').

The customer's UPI app — PhonePe, GPay, Paytm, BHIM, any bank app — reads these fields and shows them in a confirmation screen. The customer only has to enter their UPI PIN; everything else is pre-filled.

Layer 2: The intent lifecycle

An 'intent' is the gateway's record of one QR being issued for one order. Its states:

1. created — intent created by your backend, QR rendered on customer's screen.
2. paid — customer's payment detected at your merchant bank/PSP, gateway matched it to this intent.
3. expired — intent's expiry window passed (default 15 min) without payment.
4. cancelled — your backend explicitly cancelled the intent before payment.

Knowing the current state of every intent lets you give customers a sensible UX (waiting screens, expiry warnings, retry options) and lets your accounting code match every credit to a specific order with zero ambiguity.

Layer 3: The webhook

When the gateway detects a payment that matches an intent, it fires a signed HTTP POST to your webhook URL with the intent ID, order ID, amount, UTR, and a timestamp. Your backend verifies the signature, marks the order paid in your DB, and triggers downstream actions (email, fulfilment, access provisioning).

"The webhook is the only authoritative source of payment truth. The customer's UPI app showing 'success' doesn't count; your frontend's optimistic 'we got the payment' doesn't count. Only the verified webhook is the truth."

Why this beats static QR online

Static QR is a hand-me-down from the physical-retail world. Online, it fails for predictable reasons: customers type wrong amounts, two customers paying the same value are indistinguishable, your bank statement shows credits with no order reference. Dynamic QR removes every one of these failure modes structurally — not because you've trained the customer better, but because the amount field is locked, the reference is unique, and the gateway can tell intents apart by ID even when amounts collide.

Operational benefits in practice

Merchants who migrate from static QR + manual confirmation to dynamic QR + webhooks typically report, within the first month:

• 60–80% reduction in payment-related support tickets.
• Reconciliation time drops from hours/day to minutes/day.
• Wrong-amount refunds approach zero.
• Order-to-fulfilment latency drops from 'whenever the team gets to it' to 'within seconds of payment'.
• Repeat purchase rates improve because customers had a friction-free first checkout.

Implementation in three calls

The technical work to add dynamic QR to a custom website with VyaparGateway:

1. POST /v1/intents from your backend with amount + order_id, get back QR + intent_id.
2. Render the QR on your frontend, poll GET /v1/intents/:id/status every few seconds.
3. Handle POST to /webhooks/vyapargateway on your backend, verify the HMAC signature, mark the order paid.

That's the whole integration — 100 lines or less of backend code for a custom site, plus the small frontend polling logic. For Shopify or WooCommerce, the same logic is wrapped in a plugin you install in minutes. VyaparGateway helps you issue dynamic UPI QR codes, verify payments, and notify your stack via webhooks—without charging a per-transaction platform fee on top of your plan.