用户点下“去支付”按钮的跳转那一瞬间，浏览器地址栏的并支锁头图标闪了一下，页面从商户域名跳到另一个完全陌生的跳转域名——通常是某家银行的网关地址。这个跳转过程不超过两秒，并支但背后涉及至少三次握手、跳转一次重定向、并支一次会话令牌的跳转传递，以及一个很多人从没注意过的并支细节：你的订单号被加密后塞进了跳转链接的查询参数里。

我见过一个真实的跳转翻车案例。某电商平台的并支技术团队把跳转地址写死成`http://`而非`https://`，结果在部分安卓WebView里，跳转银行网关直接拒绝加载，并支用户看到的跳转是一片空白。客服收到的并支投诉是“点了支付没反应”，但实际原因出在协议头少了一个字母。跳转这种问题测试环境很难复现，因为测试机的WebView版本和用户手机上的往往不一样。

跳转本身不是最脆弱的环节。真正容易出问题的是跳转前后的状态管理。商户系统需要先生成一笔待支付订单，再把订单号、金额、商户ID、签名打包发给银行。银行验证签名通过后，返回一个带令牌的支付页面地址。用户在这个页面输入卡号密码，银行处理扣款，然后通过异步通知告诉商户“钱到了”。同步跳转回商户页面只是给用户看的，真正决定订单状态的是那条异步通知。很多开发者搞混了这两者，把同步跳转的结果当作支付成功的依据，结果用户关掉浏览器，异步通知还没到，订单就丢了。

我自己的习惯是，在跳转前把订单号写进`sessionStorage`，跳转回来先查本地记录，再调商户后端接口确认状态。银行异步通知有延迟，有时候几秒，有时候几分钟。等不了的话，可以做个轮询，但别太频繁，银行网关对请求频率有限制。

还有个小细节：跳转链接里的金额参数。有些银行要求单位是分，有些要求是元，带两位小数。我遇到过一家城商行，金额传`100`表示1元，传`100.00`反而报错。文档里没写清楚，试了三次才搞对。这种坑只能靠实际对接积累，看文档没用。

移动端更麻烦。iOS的Safari对跨域跳转的Cookie策略越来越严，银行网关如果依赖第三方Cookie维持会话，跳过去可能直接提示“会话过期”。解决办法通常是让银行支持无Cookie的令牌验证，或者商户端做一次中间页跳转，先把用户引导到银行域名下再发起支付。中间页体验差一点，但成功率高。

跳转网银支付这件事，技术上的核心就一句话：别信任前端返回的任何支付结果，只认后端异步通知。剩下的都是细节——协议、编码、金额格式、会话保持。细节没处理好，用户看到的就是“支付失败”四个字，而你查日志要查半天。

(责任编辑：探索)