NewAPI 通过 ePay 协议对接快米兔聚合支付：签名对齐、回调兼容与入账对账要点

自建 AI API 中转平台的团队，通常会把 NewAPI 或 OneAPI 作为后端管理框架，用来管理官方接口或任意 OpenAI 兼容上游的 Key、路由与日志。真正让用户完成充值、回调、入账和对账的环节，则可以通过常见 ePay 协议接入快米兔聚合支付。快米兔聚合支付兼容常见 ePay 协议，对已经接入 ePay 的充值页，只需更换网关地址和商户密钥即可切换，下单与回调一般不用重写，这能减少历史魔改 ePay 带来的签名与字段不一致问题。

第一类问题是签名参数对齐。ePay 协议下的下单请求通常按键名 ASCII 升序排列，再拼接参数后做 MD5 或商户后台指定的摘要算法。对接快米兔聚合支付时，应以商户后台提供的签名规则为准，不要沿用旧版魔改 ePay 的排序或空值处理习惯。遇到验签失败，可以在 NewAPI 侧打印完整待签名字符串，再与快米兔聚合支付后台的签名示例逐字符比对，确认参数排序、空值是否参与签名、金额格式和商户密钥是否一致。

第二类问题是异步回调字段映射。NewAPI 的回调处理器一般依赖 trade_no、out_trade_no、money、type 等字段。快米兔聚合支付按照常见 ePay 协议返回这些标准字段，如果你的旧充值页曾修改过字段名，切换后需要检查回调解析是否仍按标准字段读取。用户支付成功但余额不更新时，优先查看回调日志中的原始报文，确认字段名和表单格式是否匹配。

第三类问题是回调地址与反向代理路由。快米兔聚合支付商户后台需要填写完整的回调地址，不建议依赖默认路径。若同一台服务器部署了多个 NewAPI 实例，应在 Nginx 中为每个实例分配独立的 location，避免回调被路由到错误实例。遇到 404 或业务未处理，先检查路径前缀、Nginx 重写规则和商户后台填写的 URL 是否完全一致。

第四类问题是金额单位统一。使用快米兔聚合支付前，先明确回调金额以元为单位，并在 NewAPI 的回调处理中按元换算用户余额或配额。不要继承旧版 ePay 使用“分”或其他精度口径，否则可能出现充值 10 元到账 0.1 元或 1000 元的异常。

第五类问题是重复回调的幂等处理。快米兔聚合支付在未收到 success 响应时会重发回调，NewAPI 需要对 out_trade_no 做幂等控制，防止同一笔订单重复入账。建议在数据库层为订单号建立唯一索引，并在业务捕获重复键错误，必要时增加分布式锁或 Redis 幂等标记。

第六类问题是 HTTPS 与网络链路。商户服务器与快米兔聚合支付之间应使用受信任 CA 签发的证书，避免自签名证书或证书链不完整导致 TLS 握手失败。若回调长期不到达，还要检查服务器出口 IP 是否在商户后台白名单内，以及防火墙和安全组是否放行回调请求。

第七类问题是额外鉴权信息。如果在快米兔聚合支付商户后台开启了支付接口 Token 或 IP 白名单，需要在 NewAPI 请求中携带对应 Token，并把服务器出口 IP 加入白名单。出现“鉴权失败”而非“签名错误”时，优先排查 Token 和 IP 配置。

接入快米兔聚合支付后，资金链路采用直清模式，资金进入商户结算账户，T+1 结算，交易费率为 1%，除按成交金额计费外，没有开户费、年费等其他开户费用。对已经使用 NewAPI 或 OneAPI 的团队来说，保留两侧详细日志、用固定金额订单覆盖支付到回调到入账的全链路、对回调处理加入幂等锁，并定期核对订单状态，可以让充值、回调、入账和对账链路更稳定。