网站与移动端支付接入指南

支付接入方案应从顾客在哪里下单开始。电脑浏览器、手机网页、APP 和小程序的界面相似，但支付唤起方式、需要准备的标识以及返回路径并不相同。先确定终端环境，再安排接口和联调，可以减少上线前反复修改。

先区分终端环境

这些准备有不同的职责归属：客户端负责展示与唤起支付，服务器负责生成业务订单、签名、验证支付结果和记录最终状态。商户私钥应保存在服务器端，不应随网页或应用安装包分发。

怎样理解接口类型？

本站统一下单文档列出了 web、jump、jsapi、app、scan 和 applet 等类型。选择时要同时考虑业务终端与返回参数的处理方式。

• web 面向通用网页支付，结合 device 描述终端环境。
• jump 返回支付跳转地址，适合通过跳转完成收银的页面。
• jsapi、app 与 applet 对应应用内的调用场景，需要由相应客户端处理返回的支付参数。
• scan 用于读取顾客付款码，需要提供付款码参数 auth_code。

请求中的接口类型与返回的 pay_type 是两个概念。前者描述发起方式，后者告诉接入方实际应怎样继续：跳转、展示二维码或调用客户端支付。代码应处理文档规定的返回类型，不要把所有响应都当作二维码地址。

把订单与支付结果连接起来

服务器应先生成业务订单及唯一的 out_trade_no，确定商品、金额和用户，再发起支付请求。收到平台返回的 trade_no 后，将两个订单号保存到同一条业务记录中，便于查单与售后定位。

notify_url 是接收服务器通知的地址；return_url 是顾客完成操作后的页面返回地址。用户可能关闭页面、断网或重复打开收银台，所以业务系统不能只依赖回跳页面决定是否发货。

金额由服务器根据业务规则计算，不能直接信任客户端传入的最终金额。通知到达时，还需要核对签名、商户、订单号、金额与交易状态。

上线前至少验证这些情况

1. 正常付款后，支付记录与业务订单能对应，交付动作只执行一次。
2. 用户取消或返回时，业务订单不会被错误标记为已付款。
3. 收到重复通知时，系统能识别已处理订单并正确应答。
4. 暂未收到通知时，服务器能通过订单查询确认结果。
5. 不同浏览器与目标设备上，跳转、返回及二维码展示都能完成。
6. 涉及退款的业务能够记录退款单号，并核对处理后的订单状态。

留下一份可以维护的接入记录

记录接口版本、通知地址、负责人员和各终端测试结果。后续更换域名、修改服务器或更新客户端时，重新验证相关环节。遇到问题时提供订单号与时间范围，比只提交一张“支付失败”的截图更容易定位原因。

字段及返回类型见统一下单文档；签名细节见签名规则。结果处理可接着阅读支付回调处理指南。