"原生"改了什么
钱的部分没变，变的是界面。pay_type=2 下单方式一样，但由你的应用决定用户怎么付：可以内嵌流程、自己渲染二维码，或把支付链接交给你自己控制的 webview。
收银台本身就是产品时，这点很关键：订阅页、App 内钱包、游戏充值，以及任何"跳到第三方域名就掉转化"的流程。
| 能力 | 扫码唤醒（pay_type=1） | 原生直连（pay_type=2） |
|---|---|---|
| 支付界面归属 | rolexpay 托管页 | 你的应用 |
| 单笔限额 | ₹100 – ₹50,000 | ₹100 – ₹5,000 |
| 基础费率 | 3.00% | 8.00% |
| 签名与回调 | 完全一致 | 完全一致 |
| 适合场景 | 移动端 H5、发票、聊天成交 | 自有收银台、App 内、订阅 |
请求与返回
调用 POST /api/submit/submitCollect，pay_type=2。返回里有 platform_order_no、fee、status 和 pay_link。请把 platform_order_no 和你的订单号一起存下来 —— 回调里出现的就是它。
金额是 INR 小数。merchant_order_no 在商户维度必须唯一；重试时复用同一个号，是产生重复订单最快的方式。
安全地处理回调
回调是 JSON。先校验 md5(platform_order_no + merchant_order_no + amount + fee + status + key) 与 sign 是否一致，再动业务逻辑，并在 5 秒内返回纯文本 SUCCESS。
按至少一次投递来设计：同一订单可能收到多次回调。以 platform_order_no 作为幂等键，保证处理逻辑可重复执行。
对接面
HTTP POST，application/x-www-form-urlencoded，UTF-8 编码。没有 SDK、没有 OAuth、没有 token 刷新 —— 一套按顺序拼值的 MD5 签名就是全部鉴权。
可用接口：submitCollect、submitPayout、getBalance、collectStatus、payoutStatus。完整参数、错误码和多语言示例见开发者文档。
FAQ
常见问题
为什么原生直连费率比扫码唤醒高？
原生订单金额更小、风险与路由模型不同，所以基础费率是 8%，扫码唤醒是 3%。走量后的阶梯价按商户单独谈。
以后能从原生切换回托管吗？
可以。两者是同一个接口的不同 pay_type，回调格式不变，不需要重新对接。
支持纯服务端流程吗？
支持 —— 服务端下单，pay_link 你想放哪放哪，状态靠回调加 collectStatus 即可。没有任何环节强制用户访问 rolexpay 页面。
订单超时怎么算？
用户一直不付款，待支付订单会过期。用 collectStatus 或回调拿最终状态，超过有效期仍是 status 1 就按未支付处理。
有幂等键吗？
merchant_order_no 就是幂等键。重复提交同一个值会视为同一笔订单，而不是新建一笔。
提供沙箱环境吗？
提供。Telegram 联系我们拿测试商户号和密钥，上线前可以先跑通全部接口。