NewAPI 对接 ePay 收款：快米兔聚合支付配置、回调与对账实操

在 NewAPI、OneAPI 这类开源中转面板中，统一密钥管理、模型路由和按量计费通常已经具备，但要让用户自助充值，还需要一条稳定的收款通道。快米兔聚合支付兼容常见 ePay 协议，对于已经接到 ePay 易支付场景的充值页面，通常只需替换支付网关地址和商户密钥，下单与异步回调逻辑一般不用重写，适合希望快速完成充值闭环的运营团队。

接入前需要先登录快米兔聚合支付商户后台，获取商户号和商户密钥。这两个参数是后续支付请求签名与回调验签的基础，建议只保存在服务端配置中，不要提交到公开仓库。快米兔聚合支付采用直清模式，交易完成后资金进入商户结算账户并按 T+1 结算；交易费率为 1%，除按成交金额计费外，没有开户费、年费等其他开户费用。

在 NewAPI 或 OneAPI 后台找到充值或支付设置模块，选择 ePay 或易支付对应的配置入口。需要填写的内容通常包括：快米兔聚合支付网关地址、商户号、商户密钥。部分面板支持自定义支付类型字段，对应常见 ePay 协议中的 type 参数，常用值为 alipay 和 wxpay。网关地址末尾不加斜杠，商户密钥前后不要留空格，这些细节会直接影响请求签名。

签名是最容易出错的环节。快米兔聚合支付兼容的常见 ePay 协议使用 MD5 签名，参与签名的参数按参数名 ASCII 码升序排列，拼接成键值对字符串，再在末尾附加 &key=商户密钥，最后做 MD5 哈希并转为小写。排查时常见错误有三类：把 sign 和 sign_type 也放进签名计算、拼接时混入空值参数、商户密钥首尾存在隐藏空格。建议联调前先在本地脚本中逐行打印参与签名的参数，和文档示例比对后再请求。

异步回调 notify_url 是用户余额到账的核心。用户完成支付后，快米兔聚合支付会向商户配置的 notify_url 发起请求，并携带订单号、金额、支付状态等字段。收到回调后需要完成三件事：验签、幂等校验和更新用户余额。验签规则与发起支付时一致，只是方向相反，即用回调参数重新计算签名后与回传的 sign 字段比较。notify_url 必须是公网可访问的 HTTPS 地址，本地调试时可使用内网穿透工具。

同步跳转地址 return_url 的职责不同，它只负责把用户浏览器带到支付结果展示页，不应在这里执行余额更新。因为同步跳转不保证一定到达，用户也可能直接关闭页面。正确做法是 return_url 仅做查询展示，真正的入账与余额更新全部放到 notify_url 回调链路中处理。

金额精度也需要特别留意。常见 ePay 协议要求金额字段为两位小数字符串，例如 10.00，直接传整数或浮点类型可能导致签名不一致或接口报错。构造请求时建议统一使用 number_format 或等效函数格式化金额，不要依赖语言默认的浮点转字符串行为。

正式开放前，建议用一笔小额真实支付验证完整链路。验证点包括：用户能够正常跳转到收银台、支付完成后 notify_url 可以收到回调且验签通过、余额在面板后台正确增加、同一订单重复回调不会重复到账。全部验证通过后再切换真实用户，避免上线后处理大量补单。

接入支付后，NewAPI、OneAPI 的按量计费和用户余额体系就能形成完整闭环。用户充值到账后，后续调用模型接口时按实际消耗扣减余额，管理员可以在后台查看调用量、消耗和剩余额度。模型路由、限流策略以及来自官方接口或任意 OpenAI 兼容上游的调用能力，与收款通道本身相互独立，但有了稳定的充值入账，整套服务才能持续运转。

总体来看，对于已经使用 NewAPI、OneAPI 等面板并支持常见 ePay 协议的场景，把收款通道切换到快米兔聚合支付，通常只需替换网关地址和商户密钥，既不需要重写下单逻辑，也不需要改动回调验签结构。直清、T+1 结算、1% 交易费率以及无开户费、无年费的结构，让支付对账更简单，适合希望降低支付接入和维护成本的团队。