Intent 还是 Collect：收银台该选哪条 UPI 链路

托管收银台：先上线，再优化

托管收银台把买家带到支付 URL，再用回调带回来。前端不用重写：一个链接、一次接入，页面背后同时处理 Intent 链接和 Collect 降级。在 Titan Pay 的沙箱里，托管链路基准成功率是 60%。对 Web 和 H5 来说，这是一个合理的起点，尤其适合还没摸清买家常用哪些 App、又要先上线的情况。

代价是控制权。买家离开你的页面，也要承接收银台自身的流失。先用托管收银台拿数据，再把高意向流量切到步骤更少的链路。

Intent 唤醒：移动端少按几次

upi:// 链接会打开手机上已经安装的 UPI App。买家不用输入 VPA，回调里带 UTR。在移动 Web 和 App 内，这通常是从点击到支付最短的路径。Titan Pay 的原生与 Intent 基准成功率是 70%，在同一个沙箱里比托管高 10 个百分点。

Intent 链接需要移动端环境。桌面端要降级成动态二维码，不要放一个点不动的按钮。部分 App 允许买家改金额，唤醒前先把订单确认清楚。

原生 Collect：服务端发起，适合重复收款

Collect 是你的服务器向 UPI 链路发起的请求。VPA 校验和金额锁定在 2 秒内返回，状态可以轮询到终态。它适合订阅扣款、批量收款，以及买家不在收银台前的场景。它不适合首笔支付：买家得先有 VPA，并且信任这笔请求。

已经知道付款人是谁时用 Collect；Collect 请求过期时，用 Intent 兜底。

一条简单的选择规则

不变的部分

无论先从哪条链路开始，都保持一套回调格式、同一组四种终态、同一份 D0 结算单。重试要有上限：3 次足够恢复瞬时失败，也能留下干净的审计记录。回调迟到就轮询，订单还在 pending 时不要标失败。

链路是产品选择；围绕它的契约——回调、UTR、结算——不应该因为多接一条链路就改变。