Skip to main content
Menu

How it works

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.