支付通道路由与 Paystack 接入 — 迭代需求

核心目标：在现有 PMT / Plutus 支付中台基础上，明确 Monnify、Paystack 两类支付通道的能力边界、路由规则、配置治理、异常切换和验收口径，使后续研发可以按统一通道模型落地，而不是为某个通道新增孤立流程。

1. 背景

当前系统中 Monnify 和 Paystack 都已经存在接入痕迹，但能力分布不完全一致：

Monnify 已接入出款 / 转账、Monnify Mandate 代扣、Monnify 回调、绑卡相关链路。
Paystack 已接入卡 / token 代扣、Paystack Webpay 主动还款、交易查询、账户校验等链路。
支付中台已有 PaymentChannel、ThirdPaymentFactory、DoRepaymentFactory、channel.avaliable.pay 等通道抽象和配置能力。

本需求不把 Paystack 当成全新支付框架接入，而是要求把 Paystack 和 Monnify 纳入同一套路由、监控、查询补偿和运营配置体系。

2. 目标

明确 Monnify、Paystack 在主动还款、自动代扣、银行转账、Mandate、放款 / 出款等场景下的推荐使用方式。
明确本期 Paystack 必须支持的四类能力：出款、H5 主动还款、银行账号代扣、虚拟账号收款。
支持按业务线、还款方式、通道可用性和优先级选择默认支付通道。
支持通道异常时按规则切换备用通道，避免因为单一通道故障影响还款和出款。
保证同一订单在多通道环境下不会重复扣款、重复入账或状态倒退。
为后续运营后台配置、监控告警、查询补偿和人工排查提供统一字段和流程。

3. 范围

3.1 本期包含

能力	范围
通道能力梳理	固化 Monnify、Paystack 在当前系统中的可用能力和使用边界
还款方式路由	支持 H5 主动还款、银行卡 / token 代扣、银行账户扣款、虚拟账户 / 银行转账等方式按规则选通道
出款通道路由	支持放款 / 转账出款按业务线优先级选择 Monnify 或 Paystack
Paystack 本期接入	支持 Paystack 出款、H5 主动还款、银行账号代扣、虚拟账号四项功能
配置治理	统一使用 `channel.avaliable.pay` 管理通道开关和优先级
异常切换	支持通道关闭、余额不足、接口异常、长期 pending 等场景下的受控切换
幂等和防重复	对支付发起、回调、查询补偿、重发通知做幂等约束

3.2 本期不包含

重写支付中台整体架构。
新增完整财务对账平台；对账和入账监控详见 15-还款入账查询监控。
改造 FCS 销账顺序、费用减免、还款计划试算规则。
允许同一订单在状态不明时立即跨通道重复扣款。
运营人员任意修改第三方密钥、回调地址、签名算法等敏感配置。

4. 当前系统事实

模块 / 能力	当前状态	说明
`PaymentChannel`	已包含 `Paystack`、`PaystackWebpay`、`Monnify`、`MonnifyMandate`	通道枚举已具备基础扩展点
`ThirdPaymentFactory`	已可路由到 Paystack、PaystackWebpay、Monnify、MonnifyMandate	代扣、出款、查询类能力通过工厂分发
Paystack 卡 / token 代扣	已有实现	用于自动扣款、批量代扣和查询
Paystack Webpay	已有实现	初始化交易后返回 `authorization_url`，客户跳转完成主动还款
Paystack 账户校验	已有实现	用于银行账户名称解析
Monnify 转账 / 出款	已有实现	以 `paymentFlowId` 作为 reference / reconRefNo
Monnify Mandate	已有实现	使用 mandate code 发起扣款，并查询 `PAID / FAILED` 状态
Monnify 回调	已有实现
通道同步任务	已有实现	将 Apollo 通道配置同步到可用通道表，并告警业务线全关等情况

5. Paystack 本期功能范围与接口文档

本期 Paystack 明确支持以下四项能力。研发实现时以 Paystack 官方文档为接口口径，本文仅定义我方业务落地规则和边界。

功能	Paystack 能力 / API	官方文档地址	我方业务用途	本期落地要求
出款	Transfers / Transfer Recipients	Transfers、Transfer API、Transfer Recipient API	放款、退款、运营转账或其他业务出款备用通道	支持创建 / 复用 recipient、发起 transfer、保存 transfer code / reference、查询结果、处理失败和余额不足
H5 主动还款	Transactions	Accept Payments、Transaction API、Verify Payments	客户在 H5 / 还款链接中跳转 Paystack 页面完成主动还款	支持初始化交易、返回 `authorization_url`、支付完成后 verify、回调与主动查询双确认
银行账号代扣	Direct Debit	Direct Debit、Direct Debit API	客户授权后从银行账户发起代扣，作为银行卡 token 之外的自动还款方式	支持 mandate 授权、授权状态查询、发起银行账号扣款、保存 mandate / authorization 标识、处理 pending / failed / success
虚拟账号	Dedicated Virtual Account	Dedicated Virtual Accounts、Dedicated Virtual Account API	为客户创建专属虚拟账号，客户转账后自动匹配还款	支持创建 / 查询客户虚拟账号、展示银行名 / 账户名 / 账号、接收转账交易通知、按客户和订单匹配入账

5.1 Paystack 出款

业务目标：将 Paystack 纳入出款候选通道，与 Monnify 一起按业务线配置进行主备路由。

关键要求：

出款发起前必须完成收款人账户校验或 recipient 创建。
每笔出款必须保存我方 paymentFlowId、Paystack transfer code、reference、recipient code、实际商户主体。
出款结果以 Paystack transfer 状态和我方查询补偿结果为准，不只依赖同步返回。
余额不足、recipient 无效、银行不可达、transfer pending 超时等场景必须进入异常切换或人工处理队列。
已经被 Paystack 受理且状态不明的出款，不允许立即换通道重复出款。

5.2 Paystack H5 主动还款

业务目标：客户通过 H5、还款链接、客服发送链接进入还款页时，可使用 Paystack 初始化交易并跳转支付。

关键要求：

后端初始化交易时必须传入我方 paymentFlowId 作为 reference。
返回给前端的核心字段为 authorization_url、订单号、金额和处理中状态。
前端回跳只用于展示和触发查询，不直接作为入账依据。
还款终态必须通过 Paystack verify、回调、PMT 状态处理和 FCS 入账确认闭环。
初始化成功但客户未支付的订单，需要按超时规则关闭或标记 abandoned，避免长期占用在途订单。

5.3 Paystack 银行账号代扣

业务目标：支持客户授权银行账户后进行自动还款，作为卡 token 代扣和 Monnify Mandate 的补充通道。

关键要求：

银行账号代扣必须先有客户授权，不允许仅凭账号直接扣款。
系统需保存 mandate / authorization 相关标识、授权状态、授权账户、银行编码和客户标识。
发起扣款前需校验授权仍有效、账户未冻结、客户和借据匹配。
代扣请求返回 pending / processing 时，进入查询补偿，不允许跨通道立即重扣。
授权失败、授权过期、客户撤销授权时，应从可用代扣方式中过滤该账户。

5.4 Paystack 虚拟账号

业务目标：支持为客户创建或分配 Paystack Dedicated Virtual Account，客户转账到账后自动识别还款。

关键要求：

每个虚拟账号必须绑定客户、业务线、Paystack customer / dedicated account 标识。
还款页展示虚拟账号时，需展示银行名、账户名、账号、应还金额和有效说明。
收到 Paystack 转账交易通知后，必须按客户、账号、金额、时间和订单规则匹配还款订单。
无法匹配订单、金额不一致、客户身份不一致的交易不得自动销账，进入未匹配收款队列。
虚拟账号交易仍需接入 15-还款入账查询监控的主动查询、异常队列和人工处置。

6. 通道能力边界

6.1 Paystack

能力	使用场景	要求
Paystack Webpay	H5 / 短链 / 客服发送链接后的主动还款	返回可跳转 URL；支付完成后通过回调和 verify 查询确认结果
Paystack 卡 / token 代扣	到期自动扣款、批量代扣、客户已绑卡还款	必须使用 Paystack 自身 token / authorization；不能假设其他通道 token 可复用
Paystack 出款	放款或转账出款备用通道	需保存 transfer code / reference，支持主动查询
Paystack 账户校验	银行账户绑定、账户名称核验	可作为账户校验通道之一，不等同于还款通道
Paystack Direct Debit	银行账号授权代扣	必须完成客户授权，按 mandate / authorization 状态发起扣款和查询
Paystack Dedicated Virtual Account	虚拟账号转账还款	用于客户专属账号收款，到账后按订单匹配入账

6.2 Monnify

能力	使用场景	要求
Monnify 转账 / 出款	放款、转账出款	以 `paymentFlowId` 作为幂等 reference；保存第三方 reference
Monnify 回调收款	虚拟账户 / 银行转账 / 部分收款通知	按 `paymentReference` 匹配订单；无法匹配时进入异常队列
Monnify Mandate	银行账户授权扣款 / Direct Debit	需先完成 mandate 绑定；扣款后通过状态查询确认 `PAID / FAILED`
Monnify 绑卡 / 认证链路	绑卡或账户授权辅助流程	与还款扣款链路分离管理，避免把绑卡成功当成还款成功

7. 场景分工

业务场景	首选通道	备用通道	路由说明
H5 主动还款	PaystackWebpay	Monnify 银行转账 / 虚拟账户	Paystack 提供跳转支付页；客户无法完成 Webpay 时可展示银行转账方式
短链还款	PaystackWebpay	Monnify 银行转账 / 虚拟账户	短链只负责进入还款页；还款页按业务线展示可用方式
已绑卡自动代扣	Paystack 或原绑卡通道	MonnifyMandate，仅限客户已完成对应授权	token / mandate 与通道绑定，不能跨通道强行复用
银行账号代扣	Paystack Direct Debit	MonnifyMandate	仅在客户具备对应授权时可用；授权标识不得跨通道复用
虚拟账户 / 银行转账还款	Paystack Dedicated Virtual Account 或 Monnify	按业务线配置	以专属账号到账通知、主动查询和订单匹配为核心
放款 / 转账出款	按业务线配置	按业务线配置	Monnify 与 Paystack 都进入出款通道路由，按可用性和优先级选择
账户名称校验	Paystack / NIBSS / 其他已接入校验通道	按配置	账户校验通道不直接决定支付通道

8. 路由设计

8.1 路由层级

支付通道选择按以下顺序执行：

业务入口
  -> 确认业务类型：还款 / 出款 / 绑卡 / 账户校验
  -> 确认支付方式：Webpay / Card / Token / BankTransfer / BankAccount / Mandate
  -> 读取业务线通道配置
  -> 过滤不可用通道
  -> 按支付方式能力和优先级选择默认通道
  -> 创建订单和流水，固化本次实际通道
  -> 调用第三方通道
  -> 回调 / 查询 / 补偿均按本次固化通道处理

8.2 配置模型

继续使用 Apollo channel.avaliable.pay 作为业务线级通道开关和优先级配置。

示例：

{
  "PalmCredit": {
    "PaystackWebpay": "Y|1",
    "PaystackVirtualAccount": "Y|2",
    "Paystack": "Y|3",
    "PaystackDirectDebit": "Y|4",
    "Monnify": "Y|5",
    "MonnifyMandate": "N|6"
  },
  "Xcash": {
    "Monnify": "Y|1",
    "PaystackWebpay": "Y|2",
    "Paystack": "Y|3"
  }
}

字段说明：

字段	说明
业务线 key	产品 / App / channel 编码，必须与 PMT 订单中的业务线一致
支付通道 key	`PaymentChannel` 枚举值或明确映射值
`Y/N`	是否启用该通道
`level`	优先级，数字越小优先级越高

注：如果研发决定不新增 PaystackVirtualAccount、PaystackDirectDebit 枚举，也可以先使用 paymentChannel=Paystack + payMethod=VirtualAccount/DirectDebit 的组合表达。但配置、订单固化、监控和查询页面必须能区分 Paystack 的四类能力，不能只显示一个笼统的 Paystack。

8.3 还款方式过滤规则

还款方式	可候选通道	过滤规则
`PaystackWebpay`	PaystackWebpay	仅用于跳转支付页；必须有 merchant mapping 和 callback URL
`Card` / `Token`	Paystack、客户 token 所属通道	必须存在有效 token / authorization；卡失效、冻结、风控限制时过滤
`BankTransfer` / `VirtualAccount`	Paystack Dedicated Virtual Account、Monnify 或其他虚拟账户通道	必须能返回可展示账户信息或已有客户专属账户
`BankAccount` / `DirectDebit` / Mandate	Paystack Direct Debit、MonnifyMandate	必须存在有效授权；授权失效、撤销或未完成时过滤
出款	Monnify、Paystack	必须配置出款商户、源账户或 recipient code，并通过余额 / 可用性检查

8.4 通道固化

订单一旦发起第三方请求，必须在 PMT 订单和流水上固化以下信息：

字段	说明
`paymentChannel`	本次实际调用的通道，如 `PaystackWebpay`、`Monnify`
`paymentMerchant`	实际商户主体，如 Paystack / Monnify 的 merchant key
`payMethod`	支付能力类型，如 `Webpay`、`Transfer`、`DirectDebit`、`VirtualAccount`、`Token`
`paymentFlowId`	我方支付流水，作为幂等 reference
`thirdRefNo`	第三方交易参考号
`reconRefNo`	对账参考号，默认使用 `paymentFlowId` 或第三方要求字段
`debitStrategy` / `repayType`	支付方式，如 Webpay、Token、BankTransfer
`routeReason`	选择该通道的原因，建议新增或扩展记录
`routeVersion`	路由规则版本，便于回溯

后续回调、查询、补偿、重发通知必须按订单固化通道执行，不允许重新按当前配置选择通道。

9. 异常切换规则

9.1 允许切换的场景

场景	是否允许切换	说明
尚未调用第三方	允许	例如通道配置已关闭、商户映射缺失、参数校验失败
第三方明确未受理	允许	例如返回参数错误、商户不可用、余额不足且无在途交易
通道被系统关闭	允许新订单切换	已发起订单仍按原通道查询
出款余额不足	允许切换	需记录关闭原因和切换原因
客户主动选择其他方式	允许	前提是不存在同订单在途支付，或已明确关闭上一笔

9.2 不允许立即切换的场景

场景	处理
第三方已返回 pending / processing	不立即切换；进入查询补偿，避免重复扣款
Webpay 已生成支付链接且未过期	不自动再生成其他通道订单；客户重新选择时需关闭或隔离旧订单
卡代扣请求状态不明	不跨通道重扣；先查询原通道结果
回调与查询状态不一致	不自动切换；进入异常队列
已成功入账	不允许任何通道切换或重复扣款

9.3 自动关闭和恢复

动作	触发条件	要求
自动关闭通道	连续余额不足、接口异常率超阈值、处理中积压超阈值	更新 `channel.avaliable.pay` 和可用通道表，记录关闭原因
自动切备用	默认通道关闭后仍有其他 `Y` 通道	只影响新订单
手动恢复	运营 / 技术确认通道恢复	需有权限控制和操作日志
全通道关闭告警	某业务线无任何可用通道	P0 / P1 告警，不允许静默失败

10. 支付方式体验要求

10.1 H5 / 还款页展示

还款页不直接展示“内部通道实现”，而应按客户可理解的支付方式展示：

前端展示方式	后端 repayType	推荐通道
Card Payment	`PaystackWebpay` 或 `Card`	PaystackWebpay / Paystack
Bank Transfer	`BankTransfer` / `VirtualAccount`	Paystack Dedicated Virtual Account / Monnify
Bank Account Debit	`BankAccount` / `DirectDebit`	Paystack Direct Debit / MonnifyMandate
Saved Card	`Token`	Paystack 或 token 所属通道

10.2 支付发起结果

通道 / 方式	返回给前端
PaystackWebpay	`authorization_url`、订单号、处理中状态
Paystack 虚拟账号 / Monnify 银行转账	银行名称、账户名、账号、金额、订单号、有效期
Token / Card 代扣	处理中 / 成功 / 失败状态；不暴露第三方敏感 token
Paystack Direct Debit / MonnifyMandate	处理中状态；由后端查询或回调确认最终结果

11. 幂等与防重复

场景	要求
支付初始化	同一业务订单在未终态前不得无限生成新支付流水
第三方 reference	优先使用 `paymentFlowId` 作为幂等 reference
Webpay 回跳	前端回跳只触发查询展示，不直接入账
第三方回调	以 reference + 通道 + 事件类型做幂等，不重复入账
主动查询补偿	查询成功后走同一终态处理链路，不绕过幂等
重发 FCS 通知	FCS 按还款订单 / 流水幂等销账
跨通道重试	原通道状态不明时禁止自动发起新通道扣款

12. 监控与告警

本需求需要复用 15-还款入账查询监控的监控口径，并额外补充通道路由维度：

指标	说明
`payment_route_selected_count`	按业务线、支付方式、通道统计选中次数
`payment_route_fallback_count`	按原因统计备用通道切换次数
`payment_route_no_channel_count`	无可用通道次数
`payment_channel_auto_close_count`	系统自动关闭通道次数
`payment_channel_manual_change_count`	人工调整通道配置次数
`payment_channel_pending_timeout_count`	通道处理中超时订单数
`payment_channel_success_rate`	按通道和支付方式统计成功率
`paystack_transfer_pending_count`	Paystack 出款处理中订单数
`paystack_direct_debit_pending_count`	Paystack 银行账号代扣处理中订单数
`paystack_virtual_account_unmatched_count`	Paystack 虚拟账号到账未匹配订单数

告警要求：

某业务线无可用还款通道：P0。
某业务线无可用出款通道：P0。
主通道 5 分钟内失败率或 pending 率异常升高：P1。
自动切换备用通道次数连续升高：P1。
Paystack / Monnify 回调成功率异常：按 15-还款入账查询监控告警。

13. 运营后台需求

后续后台配置可按以下功能拆分：

页面 / 功能	字段和动作
通道路由配置	业务线、支付方式、通道、启用状态、优先级、商户主体、更新时间、操作人
通道健康状态	通道成功率、处理中数、失败率、最近异常、是否自动关闭
订单通道追踪	订单号、客户、业务线、还款方式、实际通道、商户、routeReason、第三方 reference
异常切换记录	原通道、新通道、切换原因、是否自动、触发规则、操作人
Paystack 功能配置	出款、H5 主动还款、银行账号代扣、虚拟账号分别配置启用状态、商户和优先级
手动开关通道	启用 / 停用、调整优先级、填写原因、审批或二次确认

权限要求：

普通客服只能查询订单通道和状态。
运营可查看通道健康和异常队列。
支付运营 / 技术可调整通道开关和优先级。
生产通道关闭、恢复、优先级调整必须记录操作日志。

14. 研发实现建议

14.1 后端改造点

模块	改造建议
PMT 路由层	抽象 `PaymentRouteService`，集中处理业务线、支付方式、通道可用性和优先级
PMT 订单 / 流水	固化 `paymentChannel`、`paymentMerchant`、`routeReason`、`routeVersion`
`DoRepaymentFactory`	保持按 repayType 分发；具体通道由 repayType 内部路由或配置决定
`ThirdPaymentFactory`	保持按 `PaymentChannel` 分发；新增通道必须在此注册
Apollo 配置同步	继续同步 `channel.avaliable.pay`，补充支付方式维度时需兼容旧格式
查询补偿	按订单固化通道查询，不重新路由
回调处理	所有回调只更新匹配订单；无法匹配进入异常队列
Paystack 出款	补齐 recipient、transfer、transfer query、余额不足处理和出款幂等
Paystack H5 主动还款	复用现有 Webpay 初始化和 verify 能力，补齐支付方式维度和配置治理
Paystack 银行账号代扣	新增 / 补齐 direct debit mandate 授权、扣款、查询和授权状态维护
Paystack 虚拟账号	新增 / 补齐 dedicated virtual account 创建、查询、到账通知、订单匹配和未匹配队列

14.2 配置兼容

本期建议先兼容旧格式：

{
  "PalmCredit": {
    "PaystackWebpay": "Y|1",
    "Monnify": "Y|2"
  }
}

如需按支付方式精细化，后续可扩展为：

{
  "PalmCredit": {
    "repayWebpay": {
      "PaystackWebpay": "Y|1"
    },
    "virtualAccount": {
      "PaystackVirtualAccount": "Y|1",
      "Monnify": "Y|2"
    },
    "autoDebit": {
      "PaystackDirectDebit": "Y|1",
      "Paystack": "Y|2",
      "MonnifyMandate": "Y|3"
    },
    "payout": {
      "Paystack": "Y|1",
      "Monnify": "Y|2"
    }
  }
}

扩展前必须明确旧配置迁移、默认值和回滚方案。

15. 流程

15.1 主动还款 Webpay

客户进入还款页
  -> PMT 查询业务线可用还款方式
  -> 客户选择 Card Payment
  -> PMT 按配置选择 PaystackWebpay
  -> 创建订单和流水，固化 PaystackWebpay
  -> 调用 Paystack 初始化交易
  -> 返回 authorization_url
  -> 客户跳转支付
  -> Paystack 回调 / PMT 主动 verify
  -> PMT 更新终态并通知 FCS 入账

15.2 虚拟账号 / 银行转账还款

客户进入还款页
  -> 客户选择 Bank Transfer
  -> PMT 按配置选择 Paystack Dedicated Virtual Account 或 Monnify
  -> 创建或查询客户虚拟账号 / 转账账户信息
  -> 返回账号、账户名、银行名、金额和有效期
  -> 客户转账
  -> Paystack / Monnify 回调或 PMT 主动查询到账
  -> PMT 匹配订单并通知 FCS 入账

15.3 银行账号代扣

客户完成银行账号授权
  -> PMT 保存 Paystack mandate / authorization 信息
  -> FCS / 批处理发起代扣
  -> PMT 校验授权状态、客户、借据和金额
  -> 按配置选择 Paystack Direct Debit 或 MonnifyMandate
  -> 创建订单和流水，固化实际通道
  -> 调用第三方银行账号代扣
  -> pending 状态进入查询补偿
  -> 成功后通知 FCS 入账
  -> 失败后按策略释放订单或进入下一批处理

15.4 自动卡 / token 代扣

FCS / 批处理发起代扣
  -> PMT 查询客户有效 card token / authorization
  -> 按 token 所属通道和路由规则选择 Paystack 或其他卡扣通道
  -> 创建订单和流水，固化实际通道
  -> 调用第三方代扣
  -> pending 状态进入查询补偿
  -> 成功后通知 FCS 入账
  -> 失败后按策略释放订单或进入下一批处理

15.5 出款

业务系统发起出款
  -> PMT 按业务线读取出款通道配置
  -> 过滤关闭、余额不足、参数缺失通道
  -> 选择 Monnify 或 Paystack
  -> 创建出款流水，固化通道和商户
  -> 调用第三方出款
  -> 通过回调 / 查询确认结果
  -> 通知业务系统出款结果

16. 验收标准

每个业务线可配置 PaystackWebpay、Paystack、Monnify、MonnifyMandate 的启用状态和优先级。
Paystack 本期四项能力均有明确接入：出款、H5 主动还款、银行账号代扣、虚拟账号。
Paystack 四项能力均在配置、订单固化、监控、异常查询中可区分，不允许只显示笼统的 Paystack。
Paystack 出款可完成 recipient 创建 / 复用、transfer 发起、结果查询、失败处理和幂等控制。
主动还款选择 Card Payment 时，系统可按配置发起 PaystackWebpay 并返回 authorization_url。
Paystack H5 主动还款可完成交易初始化、跳转 URL 返回、verify 查询和回调 / 查询确认。
Paystack 银行账号代扣可完成授权状态保存、授权校验、扣款发起、结果查询和授权失效过滤。
Paystack 虚拟账号可完成账号创建 / 查询、还款页展示、到账通知处理、订单匹配和未匹配入队。
Bank Transfer / VirtualAccount 方式可按配置走 Paystack Dedicated Virtual Account 或 Monnify，并返回客户可完成转账的信息。
自动代扣只能使用客户已有的对应通道 token / mandate，不发生跨通道强行复用。
任一订单发起后，PMT 订单和流水能查到本次实际 paymentChannel、paymentMerchant 和第三方 reference。
已发起到第三方且状态不明的订单不会自动跨通道重复扣款。
主通道关闭或明确不可用时，新订单能切换到备用通道，并记录切换原因。
回调、主动查询、补偿、重发通知均不会导致重复入账。
某业务线无可用支付通道时，系统能告警，并阻断继续生成不可支付订单。
通道配置调整、自动关闭、人工恢复均有操作日志。

17. 待确认

问题	影响
各业务线当前 Paystack / Monnify merchant key 和账户主体命名	决定 `paymentMerchant` 配置和迁移范围
Paystack 出款、H5 主动还款、银行账号代扣、虚拟账号四项能力的生产开通状态	决定上线顺序和灰度范围
Paystack Direct Debit 是否已为目标商户开通	决定银行账号代扣能否本期上线
Paystack Dedicated Virtual Account 支持的银行 provider 和业务限制	决定虚拟账号展示和回调匹配规则
Bank Transfer 当前底层是否完全由 Monnify 提供，还是需要新增 Paystack DVA	决定虚拟账户迁移和双通道并行策略
是否需要按支付方式扩展 `channel.avaliable.pay` 配置结构	决定配置改造复杂度
自动代扣失败后是否允许跨通道后续批次重试	决定风控和重复扣款边界
出款通道余额检查是否已有统一接口	决定自动关闭通道能否实时触发
运营后台是否本期同步建设	决定配置是否先继续走 Apollo，还是提供页面化配置

袋鼠金融蓝图

探索

支付通道路由与 Paystack 接入 — 迭代需求

1. 背景

2. 目标

3. 范围

3.1 本期包含

3.2 本期不包含

4. 当前系统事实

5. Paystack 本期功能范围与接口文档

5.1 Paystack 出款

5.2 Paystack H5 主动还款

5.3 Paystack 银行账号代扣

5.4 Paystack 虚拟账号

6. 通道能力边界

6.1 Paystack

6.2 Monnify

7. 场景分工

8. 路由设计

8.1 路由层级

8.2 配置模型

8.3 还款方式过滤规则

8.4 通道固化

9. 异常切换规则

9.1 允许切换的场景

9.2 不允许立即切换的场景

9.3 自动关闭和恢复

10. 支付方式体验要求

10.1 H5 / 还款页展示

10.2 支付发起结果

11. 幂等与防重复

12. 监控与告警

13. 运营后台需求

14. 研发实现建议

14.1 后端改造点

14.2 配置兼容

15. 流程

15.1 主动还款 Webpay

15.2 虚拟账号 / 银行转账还款

15.3 银行账号代扣

15.4 自动卡 / token 代扣

15.5 出款

16. 验收标准

17. 待确认

关系图谱

目录

反向链接