UPI collection · pay_type = 1
UPI Scan & Pay with in-app wake-up
Scan & Pay is rolexpay’s hosted UPI collection flow. Your server creates an order with pay_type=1 and receives a pay_link; the customer opens it, the UPI app on their phone wakes straight into the confirmation screen, and a signed callback tells your server the result. No customer app install, no card data, no redirect loops.
- Entry rate
- 3.00% per transaction
- Order range
- ₹100 – ₹50,000
- Settlement
- T+0 · INR
- Callback
- ≤ 5s, MD5 signed
How a Scan & Pay order works
The flow has six steps and only two of them involve you: create the order, then handle the callback.
Everything between those two points — rendering the QR, opening the customer’s UPI app, collecting the UPI PIN, routing to a working channel — happens on our side.
| Step | Who | What happens |
|---|---|---|
| 1 | Your server | POST /api/submit/submitCollect with pay_type=1, amount, merchant_order_no and callback_url |
| 2 | rolexpay | Verifies the MD5 signature, allocates a channel, returns platform_order_no and pay_link |
| 3 | Customer | Opens pay_link: QR is scanned or the page wakes the installed UPI app |
| 4 | Customer | Confirms the amount in the UPI app with the UPI PIN |
| 5 | rolexpay | Sends a JSON callback with status 2 (paid) or 3 (failed), fee, utr and sign |
| 6 | Your server | Recomputes the signature and replies SUCCESS within five seconds |
When Scan & Pay beats a native integration
Scan & Pay is the right default when you do not want to own the payment UI: mobile web checkouts, Telegram or WhatsApp commerce, invoices, and any surface where a redirect to a hosted page costs you less than building your own payment screen.
It also survives the case native flows struggle with — a customer on desktop who wants to pay with a phone. The hosted page renders a QR they scan with the same UPI app.
If you need full control of the checkout UI, use native collection with pay_type=2 instead. The signing scheme and the callback format are identical, so you can switch later without rewriting anything.
Signature and callback contract
Collect request: md5(user_id + merchant_order_no + amount + pay_type + callback_url + key).
Callback: md5(platform_order_no + merchant_order_no + amount + fee + status + key), computed over the raw received values. Reject anything that does not match before touching your ledger, and reply with the plain text SUCCESS so we stop retrying.
Reconciliation when a callback is lost
Callbacks are the source of truth, but networks drop requests. POST /api/orderquery/collectStatus with your merchant_order_no returns the order status, actual amount, UTR and callback_status (0 not delivered, 1 delivered, 2 failed), so your reconciliation job can close the loop without support tickets.
FAQ
Common questions
Which UPI apps can the customer pay with?
Any UPI app installed on the phone, including PhonePe, Google Pay, Paytm, BHIM and Amazon Pay. The hosted page does not force a specific app — the customer picks.
Do you charge on failed or abandoned payments?
No. The fee applies only to successful collection. Abandoned or declined attempts cost nothing.
What is the maximum order amount?
₹50,000 per transaction for Scan & Pay. Higher-value orders should use native collection, which is capped at ₹5,000 per order for a different risk profile — talk to us if your average order value sits outside both ranges.
How fast do funds settle?
T+0 in INR, with a ₹100 minimum settlement. Settlement timing is agreed per merchant at onboarding.
Can I use the same account for Scan & Pay and native collection?
Yes. Both use pay_type on the same endpoint, share one merchant ID and key, and report through the same callback format.
What happens if the customer closes the app mid-payment?
The order stays in status 1 (pending) until it expires. Query collectStatus to get the final state, and treat it as unpaid if it never reaches status 2.
Telegram
Get a test merchant ID for Scan & Pay
Message us on Telegram with your business category and expected monthly volume. We send the merchant ID, secret key and test endpoint — usually the same working day.