APP 与小程序都可能把支付放在应用内部，但它们使用的运行环境、身份信息与调起参数不完全相同。接入时先确定用户从哪里发起，再让业务订单贯穿创建、调起、确认和交付全过程。

用户身份与订单归属明确

业务系统用稳定的用户标识关联订单，客户端展示当前购买账号与商品。涉及应用或小程序专有身份参数时，按相应产品文档获得并核对，不能将另一个应用的身份信息直接复用。

多端账号互通的业务，应定义网站、应用和小程序购买后的权益归属。用户在手机付款、在电脑使用服务时，业务侧应能找到同一份购买记录。

服务端创建，客户端调起

金额由业务服务端计算，私钥也留在服务端。创建支付后，根据实际返回类型将必要参数交给客户端，应用再调用对应支付能力。不要把签名私钥打包进安装包或小程序代码。

本站支付创建文档列出 app、applet 等请求方式与各类返回字段。接入时区分请求方式和返回支付类型，确认客户端处理的是本次真实返回结果。

切回应用后重新核对结果

客户端收到的完成、取消或错误提示，可用于更新界面，但业务履约依赖服务端核实。应用从后台恢复、页面被重新创建或网络恢复时，按原订单重新查询，避免遗漏已经完成的付款。

对于尚在确认中的订单，展示可查询状态，不要立刻提示重新付款。重复点击支付时先恢复原订单，确需新建支付尝试时，也要保留与原业务订单的关联。

测试覆盖生命周期变化

  • 调起支付后主动取消，再次进入原订单。
  • 付款后切换应用，过一段时间再返回。
  • 网络中断后恢复，检查订单结果与权益。
  • 重新登录同一账号，确认能找回已经购买的内容。
  • 服务端重复通知时，确认业务只交付一次。

客户端负责体验衔接，服务端负责状态确认，两者应展示同一笔订单。通知校验细节可阅读支付回调处理，网页嵌入场景则参照H5 支付指南。