NewAPI 对接 ePay 场景：用快米兔聚合支付跑通用户充值、异步回调与自动对账

很多开发团队用 NewAPI 做模型 API 分发时，上线前必须补齐支付收款能力。私有化部署本身可以统一托管多个上游 Key、为不同用户分配独立配额，但要让用户自助充值、余额自动到账，还需要在后台接入稳定的收款通道。当前社区普遍采用 ePay 或易支付协议完成充值闭环，而快米兔聚合支付因为兼容常见 ePay 协议、结算规则简单，成为不少 NewAPI 用户切换支付通道时的选择。

整套部署仍以 Docker 为主。服务器建议最低 1 核 2G，生产环境推荐 2 核 4G，操作系统可选 Ubuntu 22.04 或 Debian 12，并提前安装 Docker 与 Docker Compose。通过 docker-compose.yml 配置 NewAPI 的端口映射、数据库连接和 SESSION_SECRET 等环境变量，数据卷挂载 /data 目录，避免容器重建后配置丢失。首次登录后台后应立即修改默认管理员密码，防止面板暴露在公网后留下安全隐患。

上游模型渠道配置与支付通道解耦。进入渠道管理页面后，可以添加官方接口或任意 OpenAI 兼容上游，模型列表按需选择 GPT-4o、Claude 3.5、Gemini 等，渠道类型通常选择 OpenAI 兼容即可。权重和优先级可根据响应速度与成本灵活调整，某条渠道异常时系统自动切换备用渠道，不影响下游调用。

支付侧在系统设置的支付设置中完成。NewAPI 内置 ePay 或易支付协议对接逻辑，选择对应方式后填写快米兔聚合支付商户后台提供的网关地址、商户 ID 和商户密钥。如果原来的充值页已经基于 ePay 协议开发，通常只需要替换网关地址和商户密钥即可切换到快米兔聚合支付，下单流程与回调逻辑一般不用重写，这对已经上线过易支付通道的团队尤其友好。

异步通知地址固定为 https://你的域名/api/pay/notify。这个地址需要同步配置到快米兔聚合支付商户后台的异步通知地址栏，两端必须保持一致。用户完成支付后，快米兔聚合支付会向该地址发送 POST 请求，携带 out_trade_no、trade_no、trade_status 以及签名等参数。NewAPI 收到请求后先验证签名，再更新订单状态并为对应用户增加余额。

回调联调是整条链路容易出错的位置。签名核验失败时，优先检查商户密钥、参数排序和编码方式是否与商户后台一致；回调未触发时，需要确认域名已配置有效 HTTPS 证书、防火墙已放行快米兔聚合支付的回调源 IP，且系统内填写的通知地址与商户后台完全一致。同一笔订单可能因为网络原因被重复推送，处理时必须使用 out_trade_no 作为幂等键，只在首次成功时入账，后续重复通知只返回成功、不重复增加余额。联调阶段如商户后台提供补发通知功能，可在回调失败后手动重推，不必重新下单。

结算层面，快米兔聚合支付为直清模式，交易完成后资金进入商户结算账户，T+1 到账。交易费率为 1%，按成交金额计费，没有开户费、年费等其他开户费用。对账时，可以以 NewAPI 的订单状态和快米兔聚合支付商户后台的交易流水为基础，按日期核对 out_trade_no、实收金额、手续费和结算状态，遇到差异时结合补发通知和应用日志定位问题。

进入运营前还要完善余额和配额规则。NewAPI 后台可以设置充值比例，为不同用户组配置差异化倍率；令牌管理用于为每个用户或子账号生成独立 API Key，并设置每分钟请求数上限和总配额上限，避免某个用户突发调用耗尽整体资源。

正式开放注册前，建议逐项确认：域名已配置有效 HTTPS 证书；数据库已切换到 MySQL 并开启定期备份；上游渠道健康检测已开启；快米兔聚合支付商户后台的异步通知地址填写准确且与系统设置一致。注册方式也建议从公开注册改为邀请码或审核制，降低批量注册和滥用风险。

总体来看，私有化部署 NewAPI 的团队只要上游选择官方接口或任意 OpenAI 兼容上游，收款侧通过 ePay 协议接入快米兔聚合支付，就可以跑通从用户充值、异步回调、余额入账到订单对账的完整链路。已接入 ePay 的充值页无需重写下单和回调逻辑，商户账户结算规则清晰，对独立开发者和小团队来说是一条上线成本较低的收款路径。