一笔扫码唤醒订单是怎么走的
整个流程六步，其中只有两步需要你做：下单，处理回调。
中间的所有环节 —— 渲染二维码、唤起用户的 UPI 应用、收取 UPI PIN、分配可用通道 —— 都在我们这边完成。
| 步骤 | 谁 | 做什么 |
|---|---|---|
| 1 | 你的服务端 | POST /api/submit/submitCollect，pay_type=1，传金额、商户订单号、callback_url |
| 2 | rolexpay | 校验 MD5 签名，分配通道，返回 platform_order_no 与 pay_link |
| 3 | 用户 | 打开 pay_link：扫码，或在手机上直接唤起已装 UPI 应用 |
| 4 | 用户 | 在 UPI 应用内输入 PIN 确认金额 |
| 5 | rolexpay | JSON 回调，status 2 成功 / 3 失败，含 fee、utr 与 sign |
| 6 | 你的服务端 | 重算签名，5 秒内返回纯文本 SUCCESS |
什么时候该用扫码唤醒，而不是原生直连
不想自己做支付界面时，扫码唤醒就是默认选择：移动端 H5 收银台、Telegram / WhatsApp 成交、发票收款，以及任何"跳一次托管页比自己写支付页更划算"的场景。
它还解决了原生流程最难受的一种情况 —— 用户在电脑上下单，但要用手机付款。托管页会渲染二维码，用户用同一个 UPI 应用扫一下就完成。
如果你要对收银台 UI 有完整控制权，用 pay_type=2 的原生直连。签名规则和回调格式完全一致，之后想换也不用重写对接。
签名与回调契约
下单签名：md5(user_id + merchant_order_no + amount + pay_type + callback_url + key)。
回调签名：md5(platform_order_no + merchant_order_no + amount + fee + status + key)，必须用收到的原始值拼接。校验通过再动账，通过后返回纯文本 SUCCESS，我们才会停止重试。
回调丢了怎么对账
回调是最终依据，但网络会丢请求。用商户订单号调用 POST /api/orderquery/collectStatus，会返回订单状态、实际金额、UTR 以及 callback_status（0 未回调、1 成功、2 失败），你的对账任务可以直接闭环，不用找客服。
FAQ
常见问题
用户可以用哪些 UPI 应用付款？
手机上装了哪个就用哪个，包括 PhonePe、Google Pay、Paytm、BHIM、Amazon Pay。托管页不强制指定应用，由用户自己选。
失败或用户放弃的订单收费吗？
不收费。费用只对成功的收款产生，失败和放弃的订单不产生任何费用。
单笔最大金额是多少？
扫码唤醒单笔上限 ₹50,000。更高客单价走原生直连（单笔上限 ₹5,000，风险模型不同）—— 两边都不匹配就直接联系我们。
多久到账？
T+0 当日结算，币种 INR，最低结算金额 ₹100。具体时点在开户时按商户类型确认。
同一个商户号能同时用扫码唤醒和原生直连吗？
可以。两者是同一个接口的不同 pay_type，共用一套商户 ID 与密钥，回调格式一致。
用户在支付中途关掉 App 会怎样？
订单保持 status 1（待支付）直到过期。用 collectStatus 查最终状态，没到 status 2 就按未支付处理。