网站支付

去年冬天，网站支付我在一个小型独立书店的网站支付收银台前站了整整三分钟。老板是网站支付个五十多岁的男人，正对着电脑屏幕皱眉。网站支付顾客扫了三次码，网站支付页面始终卡在“正在跳转”。网站支付后面排了四个人，网站支付有人开始看手机，网站支付有人叹气。网站支付老板最后摆摆手说：“算了，网站支付你直接转我微信吧。网站支付”这笔交易绕过了网站支付系统，网站支付回到最原始的网站支付方式。问题不在网络，网站支付也不在顾客手机——是网站支付那个支付接口的异步回调没配好，订单状态永远停在“待支付”。

网站支付这件事，表面看是技术活，骨子里是信任和效率的平衡。用户点下“确认付款”按钮那一刻，背后至少跑了四层逻辑：前端把金额、订单号、商户ID打包，通过HTTPS发给支付网关；网关验证签名、检查风控规则，再跳转到银行或第三方渠道；银行扣款成功后，异步通知商户服务器；商户更新订单状态，最后前端轮询或长连接拿到结果，显示“支付成功”。任何一层断掉，用户看到的就是转圈圈。

我见过不少小团队栽在“异步通知”上。他们以为同步返回成功就万事大吉，结果用户关了浏览器，通知没收到，订单永远挂着。更麻烦的是重复支付——用户以为没成功，再点一次，钱扣了两遍。处理退款比处理支付麻烦十倍。有个做知识付费的朋友，上线第一周就遇到这问题，连夜写了个对账脚本，手动比对支付宝流水和本地订单。他说那三天没睡好觉，梦里都是“交易号”和“商户订单号”在打架。

支付渠道的选择也很有意思。大公司通常接多家：微信、支付宝、银联，甚至海外Stripe。小网站往往只接一家，省事。但省事有代价。去年某支付渠道调整费率，从0.6%涨到1%，一个卖手工艺品的独立站主算了一笔账：月流水八万，多出来的0.4%就是三百多块。他咬咬牙接了第二家渠道，花了两天改代码。改完之后发现，不同渠道的签名算法不一样，回调格式不一样，退款接口也不一样。他苦笑说：“这哪是支付，这是方言翻译。”

安全是另一根弦。有人觉得网站支付就是调个API，没什么大不了。但CSRF、金额篡改、重放攻击，随便一个都能让商户赔钱。我见过最离谱的案例：某网站把订单金额放在前端隐藏字段里，用户用浏览器开发者工具改成0.01元，居然支付成功了。后来查出来，后端只验证了签名，没校验金额是否与数据库一致。这种漏洞在早期电商里不少见，现在虽然少了，但换个马甲又出现在各种“快捷支付”插件里。

移动端又不一样。手机浏览器跳转支付App，再跳回来，中间可能被系统杀掉进程。用户回来发现页面刷新了，订单没了。所以现在很多网站改用“支付中”状态页，配合服务端轮询，而不是依赖前端回调。这多出来的几秒等待，用户感知就是“卡”。但没办法，可靠性优先。

说到底，网站支付不是一锤子买卖。它是一条链，每个环节都得扣紧。商户想的是“钱到账就行”，用户想的是“别扣我两次”，开发者想的是“别半夜报警”。这三者之间的张力，才是支付系统真正的样子。那个书店老板最后没改代码，他贴了张纸条：“如支付失败，请扫旁边二维码。”纸条下面，微信和支付宝的收款码并排躺着。有时候，绕开技术也是一种解决方案。

本文地址：http://www.79wt.cn/news/405b9599499.html