Questions, answered clearly

Merchant payment software. You ask for a payment — as a link, from the dashboard or through the API — your customer pays it and sends the payment screenshot, and PayMQR checks that evidence against the order and keeps the record. PayMQR also generates direct UPI QR codes, which pay you straight from any UPI app.

Merchants who already collect payments into their own UPI account and need a reliable way to ask for them and keep track of which ones have been paid. Shops, restaurants, service businesses, freelancers and anyone invoicing customers directly.

No. Your customer pays your own UPI account directly. PayMQR is never in the money path — it does not hold, route, settle or guarantee funds, and it is not a bank, an acquiring institution or a regulated payment gateway.

No. There is no settlement, no payout and no clearing. Money arrives in your account exactly as it would if the customer had paid you without PayMQR; PayMQR adds the payment record and verification.

It is counted each time PayMQR checks a submitted payment against one of your orders — typically when a customer uploads a payment screenshot on the checkout page.

It is not a page view, not an API call and not a payment. A payment nobody submits evidence for consumes nothing.

A QR code is a direct UPI code. It carries your payment account, so a customer scanning it pays you straight from their own UPI app — there is no PayMQR page in between, and PayMQR never sees the payment.

A payment link, and a payment created through the API, goes through the PayMQR checkout: the exact amount, a screenshot from the customer and the payment status PayMQR updates after checking the proof. Use a QR code where you just want to be paid, and a link where you need the record.

No. Your allowance counts PAYMENTS PAYMQR SUCCESSFULLY VERIFIED, and nothing else. Creating payments, payment links and QR codes is unmetered, as is generating, downloading or printing a QR code, opening a checkout link, uploading a screenshot, viewing analytics and receiving webhooks.

A check that fails, is sent for review, or is run again on the same payment costs you nothing. One payment can only ever use one of your verifications, however many times it is checked — and a direct QR code is never verified at all.

It moves the payment to "Under review" and leaves it for you. You see the screenshot, the checks that ran and the order it belongs to, then approve or reject it yourself.

PayMQR does not guess. A payment reads Verified only when the checks confirm it or you decide it.

When PayMQR creates a payment it may adjust the payable amount by a small number of paise — so ₹1,240.00 becomes, say, ₹1,240.37. That suffix makes the amount identifiable against one specific order, which is what lets a payment be matched confidently.

The checkout always shows the exact amount to send, and the QR carries that same amount. Your customer never has to work it out.

You can still be paid — the money moves between banks and PayMQR is not in the way — but PayMQR stops you starting NEW payments until your allowance renews, because it could not confirm them for you. Payments you had already started are unaffected and are still verified normally.

Your remaining allowance and the exact renewal time are shown in the console under Usage. A free allowance renews at 00:00 UTC each day; a paid one renews with your monthly period.

You create a link once and share the URL — or the QR of that URL. When a customer opens it, PayMQR creates a payment for that customer and takes them to the checkout.

One-time links stop working after the first payment. Reusable links keep going, creating a separate payment for each customer. Customer-entered links ask the customer for the amount, within limits you set.

Static carries no amount. It goes on your counter, and every customer who scans it starts their own payment and types what they owe.

Dynamic carries one exact amount and points at one payment. It goes on one bill, and scanning it twice does not create a second payment.

A limited time, and only while the payment is still open. You can open a new checkout link for the same payment at any time — the payment itself is unaffected.

They are validated on the server, then stored privately outside the web root. There is no public URL for a proof image. Only the merchant the payment belongs to can view it, through an authenticated request.

A customer can send another screenshot if the first was unclear; nothing already sent is replaced.

Yes, on every plan. Create payments, open hosted checkouts and read payment status over plain HTTPS with a bearer key. Webhooks tell your server when a payment changes.

Log in for the full integration details.

Developer overview

Yes. A test API key creates test payments that involve no money. A test checkout shows no UPI ID, no QR code and no pay button, so nothing can be paid through one. Test and live data are listed separately throughout.

Yes, from Billing in your PayMQR account. Choosing a paid plan opens a purchase you pay for by UPI from your own app; the plan activates once PayMQR confirms that payment. Moving between paid plans works the same way. Your payments, links, QR codes and API keys are unaffected by a plan change.

Contact PayMQR

Self-service password reset is not available yet. Get in touch and we will help you regain access.

Contact PayMQR

Each account has one owner today. Multi-user teams are not available yet.