目标读者：副组长 / 财务 / 技术 / 后台管理员 核心问题：非凡包网后台如何配置三方支付通道？新增通道的流程？通道优先级、failover、日常维护要怎么做？ 资料来源： - B 团队（Explore）对 KB 中现有三方支付内容的盘点 - 07-财务支付/03-印尼电子支付生态（行业通用信息） - 副组长日常实操 + 现有平台手册交叉验证 最后更新：2026-04-13 定位：非凡包网平台特定。支付方式的行业知识（费率/限额/合规/选型）见上述行业文档。

11 · 三方支付方式配置指南¶

一、模块定位¶

本文档聚焦非凡包网后台的三方支付通道配置侧，解决三个实操问题：

在哪配 —— 后台菜单路径、关键字段
配什么 —— 已集成的三方列表、参数、密钥
怎么管 —— 优先级调度、failover、灰度、下线

与上下游文档的边界： - 行业通用（费率/合规/选型）→ 07-财务支付/03-印尼电子支付生态 - 代收执行（待入款/确认收款）→ 02-三方待入款 - 代付执行（提现出款）→ 05-提现出款 - 通道顺序切换（日常副组长任务）→ 08-充值方式排序 / 09-提现方式排序 - 自动出款四层开关 → 01-自动出款功能详解

二、后台菜单路径¶

后台 → 支付配置
  ├─ 充值通道管理      （代收 / Pay-in 配置）
  ├─ 提现通道管理      （代付 / Payout 配置）
  ├─ 三方商户管理       （密钥 / API Key / merchant_id 集中管理）
  ├─ 充值方式排序       → 详见 08
  └─ 提现方式排序       → 详见 09

每个通道的配置由 三个维度组成： - 通道标识（三方名 + 商户号 + 通道 ID） - 业务参数（支持的支付方式 / 单笔限额 / 日限额 / 费率） - 运行时开关（启用/停用 / 灰度百分比 / 优先级）

三、已集成的三方通道分类¶

📝 注意：非凡包网后台具体接入了哪些聚合商，每个站点不同。下表是副组长常见看到的通道类型，具体以本站后台实际列表为准。

3.1 代收通道（Pay-in）—— 用户充值入金¶

通道类型	对应行业方	典型支付方式	配置要点
CP 通道	聚合收款（Xendit / Midtrans 类）	QRIS / GoPay / OVO / DANA / ShopeePay	需 `merchant_id` + `secret_key`；余额影响通道优先级
ATM / VA 通道	Bank VA（BCA / Mandiri / BRI / BNI / CIMB / Permata）	银行 VA 转账	每家银行一个子通道；需银行端开户 + 对账文件
USDT 通道	区块链钱包	TRC-20 / ERC-20	需钱包地址 + RPC 节点；有单独的 "USDT 待入款" 池，见 01

📝 重要概念：副组长日常说的 "CP"/"ATM" 是动态角色，不是固定厂商： - CP = 当前主力收款通道（通常是成功率最高的聚合商） - ATM = 当前主力代付/补充通道 - 具体由 "每日接班时查余额 + 成功率" 决定调整。见副组长工作指南 3.6。

3.2 代付通道（Payout）—— 用户提现出金¶

通道类型	对应行业方	适用场景	配置要点
e-wallet 代付	OY Indonesia / Faspay	小额到 DANA/OVO/GoPay/LinkAja	聚合商 `merchant_id` + 代付白名单
银行卡代付	银行直连 / OY / Faspay	大额到 BCA/Mandiri/BRI/BNI 等	每家银行可独立配置；RTGS 时间外会延迟
USDT 代付	链上钱包	加密货币提现	需钱包地址 + 签名密钥

四、新增三方通道上线流程¶

4.1 五阶段流程（POC → 全量）¶

 ┌──────────┐   ┌──────────┐   ┌──────────┐   ┌──────────┐   ┌──────────┐
 │  POC     │ → │ 测试对接  │ → │ 灰度上线  │ → │ 扩大灰度  │ → │  全量     │
 │ 1-2 周   │   │  1 周     │   │  5% ~ 10% │   │ 30% ~ 60% │   │  100%    │
 └──────────┘   └──────────┘   └──────────┘   └──────────┘   └──────────┘
   资料收集     技术对接         小流量验证     成功率对标     完全替换
   费率谈判     测试账户         风控观察       成本比对       备份旧通道

4.2 每阶段的责任矩阵¶

阶段	主责	配合	产出
POC	财务 / 商务	副组长（反馈需求）	对接协议 + 费率表 + 单笔/日限额
测试对接	技术	副组长（测试账户验证）	后台配置项 + API 对接文档
灰度上线	副组长（监控）	技术（随时支持）	成功率日报 + 异常告警
扩大灰度	副组长 + 主管	财务（成本核算）	成本对比报告
全量	副组长	技术（下线旧通道）	新通道成为主力，旧通道降级或下线

4.3 灰度阶段关键指标¶

指标	阈值	处理
代收成功率	≥ 97%（印尼标准）	低于 90% → 暂停放量，排查根因
代付成功率	≥ 95%	低于 90% → 同上
回调延迟	≤ 30s（99 分位数）	超过 2min → 上报技术
对账差异	≤ 0.1%（单日）	超过 → 财务 + 技术联合排查
用户投诉	0 条（灰度 5% 下）	出现即暂停

五、通道优先级与 failover 配置¶

5.1 优先级决策因子¶

后台 "充值方式排序 / 提现方式排序"（08 / 09）决定前台展示顺序和系统轮询顺序。

核心决策因子（按权重降序）：

当前余额 —— 聚合商的代付余额；不足则自动降权或跳过
历史成功率 —— 滚动 24h 窗口；低于阈值自动降权
费率 —— 同档次优先选低费率
用户偏好 —— 某些站点按用户历史偏好展示（灰度）
手动置顶 —— 紧急情况下副组长 / 主管手动调整

5.2 Failover 自动顺延机制¶

适用范围：代付通道（代收通常让用户重选，代付可自动切换）。

 用户提现请求
     │
     ▼
 当前优先级 #1 通道
     │
     ├─ 成功   → 结束
     │
     └─ 失败   → 自动尝试 #2 通道
                    │
                    ├─ 成功 → 结束（记录 failover 日志）
                    │
                    └─ 失败 → 尝试 #3 通道
                                 │
                                 └─ 连续 N 次失败 → 转人工审核
                                    （参见 01-自动出款功能详解 的 N 值配置）

详见 01-自动出款功能详解 · 四层开关。

5.3 副组长可直接调整的项¶

场景	操作	文档
某通道余额低，紧急降权	支付配置 → 对应通道 → 停用 or 降低优先级	08 / 09
某通道突发失败率飙升	支付配置 → 停用；群里通知财务补余额	同上
日常接班检查 CP/ATM 余额	见副组长指南 3.6	—

副组长不能擅自修改的项： - 密钥 / API Key（技术权限） - 费率字段（财务权限） - 通道新增 / 下线（主管 + 技术审批）

六、日常维护清单¶

6.1 每日¶

[ ] 接班时查 CP/ATM 余额（代收池 + 代付池）
[ ] 查昨日各通道成功率，异常 > 3% 的通报主管
[ ] 对账差异 > 0.1% 的订单列表交财务

6.2 每周¶

[ ] 通道费率对账（财务主导，副组长提供量数据）
[ ] 失败订单根因分类（技术问题 / 用户问题 / 通道风控）
[ ] 灰度中通道的阶段评估

6.3 每月¶

[ ] 通道整体绩效评估（成功率 + 费率 + 结算速度）
[ ] 下线长期低效通道（财务 + 技术 + 主管三方决议）
[ ] 新通道 POC 评估（若有）

七、常见配置坑¶

坑	后果	预防
密钥串行覆盖	灰度切流后新密钥没同步到所有子站点	密钥变更走批量下发脚本，不要手工逐站改
优先级调整未同步前后台	后台调了但前台展示仍是旧顺序（缓存）	改完后手工刷新前端缓存 + 抽查 2-3 个站点前台
代付余额不足未降权	用户提现直接失败	设余额告警线（如 < 单笔限额 × 10 即告警）
灰度比例设错成 100%	一把梭导致故障放大	灰度操作走双人复核（副组长 + 主管）
通道费率漂移	聚合商单边调价，成本突增	每周财务对账发现后第一时间告主管
MCC 码 / 关键词触发风控	通道突然拒付	监控拒付原因，与聚合商沟通 MCC 映射
RTGS 时间外代付延迟	用户投诉提现未到账	告知用户印尼 RTGS 工作时间（WIB 工作日 06:30-19:00）

八、故障应急流程¶

 发现通道异常
       │
       ▼
 ┌───────────────────────────────┐
 │ ① 确认故障层级                  │
 │  · 单笔失败 → 重试 / 换通道     │
 │  · 批量失败 → 该通道紧急停用    │
 │  · 多通道失败 → 升级重大事件    │
 └───────┬───────────────────────┘
         │
         ▼
 ┌───────────────────────────────┐
 │ ② 立即操作                     │
 │  · 后台停用问题通道            │
 │  · 在值班群公告                 │
 │  · 通知财务核对资金             │
 │  · 通知技术查根因               │
 └───────┬───────────────────────┘
         │
         ▼
 ┌───────────────────────────────┐
 │ ③ 事后复盘                    │
 │  · 影响范围（订单数 / 金额）   │
 │  · 根因                       │
 │  · 改进项                     │
 │  · 回填到本文"常见配置坑"表   │
 └───────────────────────────────┘

九、与自动化路线图的关联¶

副组长日常的通道维护中，以下环节高度重复、适合自动化，已进入自动化候选：

任务	当前手动	自动化后	优先级
每日 CP/ATM 余额检查	人工登录后台查	定时 API 拉取 + 阈值告警	P0
通道成功率日报	人工导出 Excel	自动统计推送到群	P1
对账差异订单筛选	人工 SQL 导出	自动对账工具 + 差异清单	P1
通道费率异动监控	人工月度核对	费率变更自动告警	P2

详见 12-自动化路线图/02-自动化机会盘点。

十、待确认问题清单 ❓¶

本站点实际接入的聚合商列表？ 需要后台截图 + 财务 / 技术对齐。
各通道的 merchant_id / secret_key 管理流程？ 是否有密钥轮换规则？
灰度比例的后台配置位置？ 副组长是否有权限调整，还是必须走技术？
代付白名单的来源？ 某些聚合商需要预先报白名单用户，这部分流程需要明确。
USDT 通道的链选择 —— TRC-20 还是 ERC-20？费率和速度对比？是否有 BEP-20 备选？

导航：← 14-财务与支付 README · 行业通用：印尼电子支付生态 · 02-三方待入款 · 05-提现出款 · 08-充值方式排序 · 09-提现方式排序