NewAPI 代理模式加 ePay 多商户：快米兔聚合支付接入、回调与对账实战

随着大模型调用服务逐渐由单一应用扩展到多项目、多团队并行，很多开发者会在同一套 NewAPI 或 OneAPI 实例上同时承载多个业务线。最先暴露的问题往往不在模型请求成功与否，而在充值流水和额度分配：多个项目共用一个收款商户时，回款无法自动对应到具体项目，对账要人工拆分；某个通道的额度耗尽，还可能影响其他无关业务。

NewAPI 的代理模式是后续做多商户隔离的基础。该模式下，NewAPI 不只做请求转发，也承担 Token 计量、限速和上游路由等职责，并且可以为不同渠道配置独立的上游密钥和计费策略。这里说的上游模型提供方，可以替换为官方接口或任意 OpenAI 兼容上游，不影响本文讨论的收款接入方式。渠道之间的隔离结构，正是后续用 ePay 多商户区分资金来源的前提。

常见的 ePay 易支付体系允许在同一程序下注册多个商户，每个商户有独立的商户号 pid、商户密钥 key 和异步通知地址 notify_url。多个项目的充值请求因此可以走不同商户通道：项目 A 的支付完成通知进入商户 A 的回调，项目 B 走商户 B 的通道，资金和通知互不干扰。快米兔聚合支付在这里的角色是收款服务提供方，它兼容常见 ePay 协议，已经接入 ePay 的充值页只需更换网关地址和商户密钥即可切换，下单参数与回调通知一般不用重写，接入成本相对可控。

切到快米兔聚合支付后，资金按直清方式进入商户结算账户，结算周期为 T+1；交易费率按成交金额的 1% 计算，除按成交金额计费外，不额外收取开户费、年费等其他开户费用。注意这里不是代收模式，也不承诺 T+0，商户侧看到的入账时间以 T+1 为准。这段产品事实明确限制了宣传口径，避免后续运营预期不一致。

配置可以按三步推进。第一步在 ePay 侧为每个项目创建独立商户，记录 pid 和 key，并为每个商户设置自己的 notify_url。建议回调路径中带上项目标识，例如 /api/pay/notify/project_a，这样 NewAPI 在接收异步通知时能快速识别来源。支付宝、微信等支付方式在各自商户下独立绑定，不要跨项目共用。

第二步在 NewAPI 侧建立对应的渠道组。后台为不同项目创建独立的渠道组，并在充值配置里填入该项目专属的 ePay 商户号和商户密钥。NewAPI 收到 ePay 异步通知后，会按照回调中携带的商户信息，把到账金额累加到对应渠道组的额度池。这里的关键点是签名校验：签名密钥必须与快米兔聚合支付所对接的 ePay 商户后台配置的 key 严格一致。任何一侧修改密钥，都要同步更新另一侧，否则可能出现支付平台显示已支付、NewAPI 额度却不增加的静默故障。

第三步是为用户 Token 绑定渠道组，并配置额度上限。NewAPI 支持将 Token 绑定到特定渠道组，再结合每组 RPM 和 TPM 限制，让不同项目在请求频次和 Token 消耗上保持隔离。需要做严格成本控制的场景，还可以按渠道组设置额度上限，超过后返回标准 429，防止单个业务线的异常调用吃掉公共资源。

上线前有几个容易忽略的点。一是异步回调的幂等处理：ePay 在支付成功后可能重复推送同一条订单通知，NewAPI 必须按订单号去重，避免同一笔支付被重复累加额度。二是在充值日志中保留完整回调原始报文，一旦出现重复推送或签名不匹配，可以快速判断问题出在支付网关、快米兔聚合支付侧配置还是 NewAPI 自身的处理逻辑。

三是测试环境与生产环境必须物理隔离。不要把测试商户的凭证写进生产渠道组，也不要复用生产商户号做联调。建议单独申请一套 ePay 商户号，在 NewAPI 的测试渠道组中使用测试凭证，测试支付、回调到达、额度变化三个节点都通过后，再切换到生产配置。

整体来看，NewAPI 代理模式提供了渠道隔离结构，ePay 多商户体系提供资金隔离机制，快米兔聚合支付则承担具体的收款和结算通道。串联起三者的关键是商户号、商户密钥、回调地址和签名算法保持一致。正式上线前，应对每个商户独立跑通“发起支付、确认回调到达、验证额度变化”的完整流程，避免上线后才发现某条链路静默断开。

当多个 AI 应用同时运营成为常态后，支付与额度之间的对应关系会直接影响财务对账和成本核算。尽早把收款通道统一到快米兔聚合支付，并按项目拆分 ePay 商户与 NewAPI 渠道组，能够减少后期人工核对流水的工作量，也为后续按项目独立核算、独立扩容留下更清晰的结构。