Skip to main content

通用错误码


批量出款错误码

有关详细出金错误处理,请参见 出金

资金流水查询 错误码


二维码支付错误码


Web 支付错误码


最佳实践

回调与查询兜底策略

使用“回调优先、查询兜底”的确认模型,可靠管理订单状态: 推荐做法:
  1. 回调作为主要通知机制,接入方式可参考 通知与回调
  2. 处理任何回调前先实现签名验证,具体规则可参考 认证与安全
  3. 使用幂等性安全处理重复回调
  4. 处理前持久化存储通知
  5. 为回调处理实现状态机控制
查询兜底策略: 如果回调缺失或延迟,请使用渐进式退避进行状态查询:
  • 5 秒
  • 10 秒
  • 30 秒
  • 1 分钟
  • 3 分钟
  • 5 分钟
该策略可避免对 API 造成过大压力,同时确保及时确认订单。

退款确认

退款是异步操作。退款 API 成功响应仅表示请求已受理,并不确认退款已实际处理完成。 必需实践:
  • 通过退款查询 API 或退款回调确认最终退款结果,退款回调详情可参考 支付
  • 使用“回调优先、查询兜底”模式验证退款完成状态
  • 不要仅根据 API 响应就认为退款已完成

安全最佳实践

认证与签名验证
  • 处理前始终验证回调签名,具体规则可参考 认证与安全
  • 如果签名验证失败,不要在回调响应中返回 SUCCESS
  • 检查请求时间戳以防止重放攻击
密钥管理
  • 不要在客户端应用中暴露服务端签名密钥或凭证
  • 使用环境变量或安全密钥库妥善存储商户密钥
  • 定期轮换签名密钥,并为测试环境和生产环境维护独立密钥
请求校验
  • 处理前验证所有请求参数
  • 检查 Content-Type 请求头并确保其符合 API 要求
  • 所有 API 通信均使用 HTTPS 与 TLS 1.2 及以上版本

相关文档