Five ways to start a payment. Three of them end on the PayMQR checkout.
A payment can begin in the dashboard, from a link, from a QR code or from your own
system. A payment created in the dashboard, from a link or through the API sends
your customer to the same PayMQR checkout and moves through the same lifecycle. A
QR code on your counter pays you directly and PayMQR never sees it.
Create→
Share→
Customer pays→
Proof→
Check→
Status
Where a payment starts
Pick whichever suits the moment
A
You create a payment in the dashboard
Enter an amount, your own reference and a description. Open a checkout link and send it to the customer.
Create payment→
Open checkout link→
Send it→
PayMQR checkout
The link is shown once, so send it to the customer it is for.
B
A customer opens a payment link
You create the link once. Opening it shows the amount; confirming creates that customer's own payment.
Share link→
Customer opens it→
Payment created→
PayMQR checkout
A one-time link stops working after the first payment. A reusable link keeps going. A customer-entered link asks for the amount first.
C
A customer scans your static QR
The code on your counter carries your payment account and no amount. The customer scans it and types what they owe in their own UPI app. This pays you directly, so PayMQR does not see it.
Scan counter QR→
Their UPI app opens→
Customer types the amount→
Paid to you directly
One code, many customers. No PayMQR checkout and no verification on this path.
D
A customer scans a fixed-amount QR
You print it on one bill with your amount inside it. The customer scans it and their UPI app opens with that amount already filled in. This pays you directly too.
Create code with an amount→
Customer scans→
Amount pre-filled→
Paid to you directly
Best where the amount is already known — a table bill, an invoice, a delivery.
E
Your system creates a payment through the API
Post the amount and your order id, then open a checkout and redirect your customer to the URL it returns.
POST /payments→
POST /checkout→
Redirect customer→
PayMQR checkout
Same page, same rules. Test keys create payments that can never collect money.
The checkout
What your customer actually sees
One page. Your business name, the exact amount to send, and a UPI QR they can scan
with any UPI app. On the phone they are paying from, a button opens their app directly.
The amount includes a unique-paise suffix, so it can be matched to this one order.
A customer paying from a laptop, a second phone or a printed bill can still scan.
Once they have paid, “I’ve Paid — Verify Payment”
opens the screenshot upload.
If a payment is already being checked, the page says so and tells them not to pay twice.
Then the evidence
The customer uploads the payment screenshot from their bank or UPI app on the same
page. PayMQR checks it against the payment it was made for.
PayMQR checks payment evidence against the payment it was made for, and anything it
cannot settle waits for a decision from you. A Verified record is PayMQR's record of
those checks — it is not a bank confirmation, and only your bank can tell you
that funds cleared.
Lifecycle
The six statuses a payment can hold
Verified, rejected and expired are final — nothing moves out of them.
Awaiting payment
Created and waiting. Nothing has been received.
Checking payment
A submitted payment is being checked against this order.
Under review
PayMQR could not confirm it automatically. Waiting for your decision.
Verified
The checks were satisfied, or you accepted it. This is the only status that closes a payment as paid.
Rejected
You rejected it, or the checks did not pass. Final.
Expired
The payment window closed before it was confirmed. Final.