码支付，技术极客的最优解 —— 从接入到调优全指南

码支付不是一个“傻瓜式”的图形化工具——虽然它也提供了很好用的客户端和插件。码支付真正的灵魂，是一套 极简、开放、文档齐全的HTTP API。如果你是一位喜欢掌控一切的技术极客，码支付会让你感到舒适。

一、接口设计哲学：少即是多

码支付的API只有三个核心端点：

• 创建订单： /create
  传入参数：pid（商户ID）、type（支付方式：1微信/2支付宝）、out_trade_no（你的订单号）、money（金额）、notify_url（回调地址）、return_url（同步跳转）。返回二维码链接或二维码图片内容。

• 查询订单： /query
  传入订单号，返回支付状态、金额、时间等。幂等查询，支持补单。

• 回调通知： 码支付主动POST到你的notify_url
  携带订单号、金额、交易流水号等。你的服务器需要返回success字符串表示确认收到。

没有任何冗余的参数，没有复杂的签名机制（可选MD5签名），没有OAuth跳转地狱。你甚至可以用curl在命令行里完成一次完整的支付测试。

二、多客户端协同：本地监听 + 云端转发

码支付支持两种模式：

1. 本地监听模式： 你的服务器或PC上运行码支付客户端，客户端直接回调你的内网服务（如http://127.0.0.1:8080/callback）。适合个人电脑运行的软件、本地调试环境。

2. 云端转发模式（推荐）： 客户端将收款通知上报到码支付云端，云端再转发到你配置的公网回调地址。适合网站、云服务器应用。好处是你不需要保持客户端和服务器在同一台机器上，手机端App也可以作为监听端，服务器在云端即可。

两种模式可以同时启用，互为备份。

三、防丢单的硬核实践

码支付的技术架构中，丢单防护是重中之重。我们设计了多级可靠性：

• 客户端本地持久化： 每次捕获到收款通知，先写入SQLite本地数据库，再尝试上报。即使上报时断网，重启客户端后会自动重传。

• 云端消息队列： 使用RabbitMQ持久化消息，确保服务器重启不丢失。

• 异步重试机制： 回调失败时，第1次延迟5秒重试，第2次延迟30秒，第3次2分钟，第4次10分钟……最多重试72小时。

• 主动查询API： 你的业务系统可以每小时调用一次查询接口，比对最近订单，处理任何可能的漏网之鱼。

• 备用回调域名： 你可以配置多个回调地址，码支付会依次尝试。

四、高并发与性能调优

对于日单量超过1000的高负载场景，码支付提供以下建议和配置：

• 多账号轮询： 单个个人微信/支付宝每日收款上限约为5-10万元，且频繁收款可能触发风控。你可以在码支付客户端中同时登录多个个人账号，API创建订单时指定使用哪个账号的二维码，实现负载分摊。

• 回调地址优化： 将回调接口设计成异步处理 —— 收到通知后立即返回success，然后把业务逻辑丢进队列后台执行。避免因为业务处理耗时过长导致码支付认为回调失败而重试。

• 静态二维码缓存： 对于固定金额的商品（比如定价9.9元的软件授权），你可以提前生成二维码图片并缓存，用户请求时直接返回缓存，减少API调用开销。

五、开源生态与自研扩展

码支付官方提供了PHP、Python、Java、C#、Node.js、易语言、Go等主流语言的SDK和示例代码。社区用户还贡献了WordPress插件、Typecho插件、WHMCS接口、彩虹易支付接口适配等。

如果你有更特殊的需求，比如需要将码支付集成到硬件收银机、嵌入式设备、命令行脚本中，码支付开放的低层级API（WebSocket实时推送、TCP socket直连）也可以满足你。

技术选型没有最好，只有最合适。码支付也许不是功能最多的，但一定是最透明、最容易掌控的。 查看完整API文档（含签名算法、错误码列表、测试环境），请访问我们的开发者中心。用代码说话，用回调验证。

- END -