UPI collection · pay_type = 2
Native UPI collection API
Native collection lets your own checkout own the payment step. Create the order through the API, receive the payment parameters and pay link, and decide how your interface presents it — no third-party branding, no forced redirect, one signed callback when the money lands.
- Entry rate
- 8.00% per transaction
- Order range
- ₹100 – ₹5,000
- Settlement
- T+0 · INR
- Signature
- MD5, 32 lowercase
What “native” changes
Nothing about the money. Everything about the surface. With pay_type=2 the order is created the same way, but your application decides how the customer pays: you can embed the flow, render the QR yourself, or hand the pay link to a webview you control.
That matters when checkout is the product: subscription screens, in-app wallets, game top-ups and any flow where a redirect to a third-party domain measurably lowers conversion.
| Capability | Scan & Pay (pay_type=1) | Native (pay_type=2) |
|---|---|---|
| Payment UI owner | rolexpay hosted page | Your application |
| Order range | ₹100 – ₹50,000 | ₹100 – ₹5,000 |
| Entry rate | 3.00% | 8.00% |
| Signature + callback | Identical | Identical |
| Best for | Mobile web, invoices, chat commerce | Own checkout, in-app, subscriptions |
Request and response
Call POST /api/submit/submitCollect with pay_type=2. The response carries platform_order_no, fee, status and pay_link. Store platform_order_no alongside your own order — it is the key that appears in the callback.
Amounts are decimals in INR. merchant_order_no must be unique per merchant; reusing it is the fastest way to create a duplicate-order incident during retries.
Handling the callback safely
The callback arrives as JSON. Verify md5(platform_order_no + merchant_order_no + amount + fee + status + key) against the sign field before doing anything else, then reply with the plain text SUCCESS within five seconds.
Treat delivery as at-least-once: the same order can be delivered more than once. Key your processing on platform_order_no and make the handler idempotent.
Integration surface
HTTP POST with application/x-www-form-urlencoded and UTF-8. No SDK, no OAuth, no token refresh — one MD5 signature over ordered values is the whole auth model.
Available endpoints: submitCollect, submitPayout, getBalance, collectStatus, payoutStatus. The full reference with error codes and language samples lives in the developer documentation.
FAQ
Common questions
Why is the native rate higher than Scan & Pay?
Native orders are smaller and carry a different risk and routing profile, so the entry rate is 8% versus 3% for hosted Scan & Pay. Volume tiers are negotiated per merchant.
Can I switch between native and hosted later?
Yes. Both are the same endpoint with a different pay_type, and the callback format does not change. No re-integration is needed.
Do you support server-to-server only flows?
Yes — create the order server-side, present the pay_link wherever you want, and rely on the callback plus collectStatus for state. Nothing requires a customer-facing rolexpay page.
What is the timeout on an order?
Pending orders expire if the customer never completes payment. Poll collectStatus or rely on the callback; treat status 1 beyond the expiry window as unpaid.
Is there an idempotency key?
merchant_order_no is the idempotency key. Send the same value again and the platform treats it as the same order rather than creating a new one.
Do you provide a sandbox?
Yes. We issue a test merchant ID and key over Telegram so you can call the endpoints against the test environment before going live.
Telegram
Get native API credentials
Send your business category and expected monthly volume on Telegram. You get a merchant ID, secret key and test endpoint to build against.