金融通道、银行支付与授信分期

1. 文档定位

本文说明 DGJ2.0 中“银行通道接入、支付中心结果落账、授信分期与分期还款”三层业务。它面向产品、前端、后端、测试、财务和运维，用于回答以下问题：

1. 服务站为什么能看到某一种银行或授信通道，注册、签约和二维码分别由谁提供。
2. 用户完成支付后，采购单、付款单、账户流水和还款单怎样变化。
3. 分期申请、分期账单、主动还款、自动还款和到期提醒怎样串联。
4. 外部系统已成功而 DGJ2 未落账时，怎样判断、补偿和验收。

本文依据当前仓库代码整理。外部支付中心、OPS Manager、银行网关的数据库表、生产路由、签名算法和重试策略不在本仓库中，均标为“待外部确认”。

2. 业务边界

2.1 本文包含

• B2B、工行、工行 E 贷、民生、京东数科、拉卡拉、泰隆、小雨点、网商银行等适配入口。
• 银行资料、贷款人资料和通道资格查询。
• 注册、短信、签约、支付二维码、还款二维码、支付链接和状态查询。
• 支付中心支付成功、支付异常、授信还款、分期到期和逾期锁站回调。
• 分期签约、可分期判断、分期模型、token、提交、账单、服务费和合同。
• 分期还款单创建、无页面支付、银联支付、B2B 支付和自动还款落账。
• 本地付款单、付款明细、账户、采购支付快照和还款单的排查方法。

2.2 本文不包含

• 专属授信资金池、专属返利、额度冻结、占用和释放的完整算法，见《32_专属授信_返利与资金池》。
• 通用支付故障的全量排查清单，见《18_财务和支付排查手册》。
• 采购单创建、支付前状态和支付后履约全流程，见《03_采购_采购退货与采购入库》。
• 银行侧清结算、对账、拒付、证书轮换和真实商户配置。
• 支付中心、OPS Manager 内部表结构及其定时任务。

2.3 三层职责

flowchart LR
    U[服务站用户] --> C[DGJ2 金融 Controller]
    C --> S[Financial Service 或分期 Service]
    S --> O[OPS Manager / 支付中心]
    O --> B[银行或授信机构]
    B --> O
    O --> M[paycenter_notify]
    M --> N[PayCenterNotify]
    N --> P[付款单和账户流水]
    N --> R[采购单或还款单状态]

3. 参与角色与前置条件

通用前置条件：

1. sid 必须对应有效服务站，当前用户必须属于该站点。
2. 需要支付的采购单通常处于 PoOrderEnums::BILLSTATUS_WAIT_PAY；支付超时的特定预订单提货单有兼容处理。
3. 银行通道必须完成准入或签约，且 OPS Manager 能查询到对应服务站配置。
4. 分期业务还需要供货方编码 shipperCode、授信调整单号 adjustNo 或分期单号 installmentNo。
5. 页面展示“已签约”“可支付”不等于资金已到账，最终必须核对支付中心事件和 DGJ2 财务落账。

4. 代码入口地图

4.1 银行与金融 Controller

4.2 分期 Controller

application/controllers/financial/BtInstallment.php 是薄 Controller：读取 getThoroughData()，调用 BaitiaoInstallmentSer，再统一通过 splash() 返回成功或错误。

5. 通道能力矩阵

6. 外部接口边界

6.1 OPS Manager 分期接口

6.2 分期还款接口

Provider 统一以外部响应 code == 0 作为成功；非零直接抛出外部 message。这只能说明接口调用成功，不能替代银行资金终态。

7. 请求字段与口径

7.1 分期申请核心字段

7.2 还款请求示例

{
  "sid": "10001",
  "user_id": "20001",
  "shipperCode": "SUPPLIER_DEMO",
  "orders": [
    {
      "installNo": "INSTALLMENT_DEMO_001",
      "returnAmount": 123400
    }
  ]
}

字段解释：

• returnAmount 在还款单本地字段和回调处理中按“分”解释；展示付款单时除以 100 转“元”。联调必须再次核对外部契约。
• sourceNo 不由前端传入，由 KzOrderNo::getHKDNo($sid) 加批次内索引生成。
• uid 记录发起人，自动还款没有本地原单时会取服务站主账号，取不到则为 0。
• shipperCode 用于匹配供应商和组成账户键，传错会导致财务往来对象错误。

7.3 还款账户键

无页面支付和 B2B 还款使用：

accountKey = accountType + "-" + sid + "-" + shipperCode

这是跨系统业务键，不是本地账户表主键。任何一段错误都可能出现“支付中心找不到账户”或资金进入错误账户域。

8. 账户类型与支付状态

8.1 系统账户编码

AccountEnums 用支付中心账户类型拼成本地 number：SYSTEM_NUMBER_PREFIX('10') + payTypeCode。

8.2 本地付款状态

这些状态是本地付款单状态，不等价于支付中心 payStatus。支付回调代码明确要求 payStatus == '02' 才进入成功落账。

8.3 分期配置枚举

9. 银行注册与签约流程

sequenceDiagram
    participant U as 服务站用户
    participant C as Financial Controller
    participant S as Service/Provider
    participant O as OPS Manager
    participant B as 银行
    U->>C: 查询资格/状态(sid)
    C->>S: 映射登录上下文
    S->>O: 查询通道状态
    O->>B: 查询主体或协议
    B-->>O: 未注册/处理中/已开通/拒绝
    O-->>S: code/message/data
    S-->>C: data 或抛异常
    C-->>U: 统一 splash 响应
    U->>C: 短信/注册/签约
    C->>S: 主体资料+验证码
    S->>O: 注册或签约
    O->>B: 实际开户/签约
    B-->>U: 可能跳转银行页面

业务判断：

1. “发送短信成功”只代表验证码请求成功。
2. “返回签约 URL”只代表获得签约入口。
3. 用户从银行页面返回后，应再次查询签约/注册状态，不能只信前端跳转结果。
4. 状态“处理中”不可重复提交敏感资料，除非外部明确允许。
5. 注册资料包含身份证、银行卡、营业执照等敏感信息，日志和文档必须脱敏。

10. 采购支付主流程

flowchart TD
    A[采购单进入待支付] --> B[请求支付中心预支付]
    B --> C{选择账户和银行通道}
    C --> D[获取二维码/链接/短信]
    D --> E[用户完成银行操作]
    E --> F[银行通知支付中心]
    F --> G[支付中心投递 paycenter_pay_result]
    G --> H{payStatus == 02?}
    H -- 否 --> I[NACK并告警]
    H -- 是 --> J{原单类型}
    J -- 预订单 --> K[校验预订单可支付状态]
    J -- 采购单 --> L[校验待支付或兼容超时状态]
    K --> M[创建付款主单与明细]
    L --> M
    M --> N[写账户流水和采购支付信息]
    N --> O[推进原单后续状态]
    O --> P[事务提交后ACK]

10.1 支付成功事件关键字段

10.2 原单校验

• 预订单允许状态来自 PreOrderEnums 的待支付、取消、自动取消兼容集合。
• 普通采购单只接受待支付和特定支付超时状态。
• 原单不存在、状态不允许或重复成功消息会抛异常并返回 NACK。
• mainPayTypeCode == 99 时走零元订单兼容，不应按普通资金明细入账。

10.3 本地落账结果

一次正常支付至少需要核对：

1. 采购/预订单状态是否推进。
2. SCM_PAYMENT 主单是否生成。
3. SCM_PAYMENT_INFO 是否按账户拆出明细。
4. SCM_ACCOUNT 是否存在支付类型对应的系统账户。
5. SCM_ACCOUNT_INFO 是否产生正确方向和金额的账户流水。
6. SCM_PO_ORDER_PAYINFO 是否记录采购支付快照。
7. 支付中心单号、来源单号和本地付款单号是否能互相追踪。

11. 分期签约与申请流程

flowchart TD
    A[查询签约状态] --> B{已签约?}
    B -- 否 --> C[发送 FQ签约 短信]
    C --> D[校验验证码]
    D --> E[获取外部签约URL]
    E --> F[用户完成签约]
    F --> A
    B -- 是 --> G[批量查询账单可分期]
    G --> H[选择 adjustNo]
    H --> I[查询分期模型]
    I --> J[选择期数/首还金额]
    J --> K[生成一次性 token]
    K --> L[按 token 提交]
    L --> M[查询分期批次和明细]

11.1 短信签约安全边界

BaitiaoInstallmentSer::getSignUrl 先使用本地短信服务校验 user_id + code，再请求外部签约地址。需要回归：

• 验证码错误、过期、已使用。
• 同一用户连续发送和频率限制。
• A 用户的验证码不能给 B 用户使用。
• 页面手机号和服务站主体手机号不一致。
• 外部签约 URL 超时后重取，旧 URL 是否失效。

11.2 可分期判断

queryEnableInstallment 同时传 sid、shipperCode 和 adjustNoList。因此“某账单可分期”至少取决于：

• 服务站授信资格。
• 该供货方是否支持分期。
• 账单是否满足金额、期限和状态条件。
• 账单是否已经分期或正在处理。

页面不能仅凭金额大于零显示“可分期”，必须使用外部返回结果。

11.3 token 语义

token 是“分期方案快照”的一次性凭证，可能固化账单、期数、费率、首还金额和有效期。高风险行为：

• token 生成后修改账单选择再直接提交。
• 重复点击导致同一 token 多次提交。
• 缓存旧 token，跨用户或跨站点复用。
• 前端自行计算服务费并覆盖外部结果。

12. 分期待还金额口径

queryInstallmentWaitPayList 对外部返回的每个分组补充六个聚合字段：

代码的“未来七天”截止值由当天零点时间戳加 7 * 24 * 60 * 60 计算。需要注意：

• 包含截止日零点及之前的记录，若到期时间含时分秒，边界可能与产品理解不同。
• 代码对 totalAmount 使用分转元，而 queryBtInstallmentMoney 汇总 totalAmountYuan；两个接口的源字段不同。
• 页面合计应使用接口聚合值，不要混加“分”和“元”。

flowchart LR
    A[外部待还分组] --> B[遍历 installmentOrderList]
    B --> C[全部待还金额/笔数]
    B --> D[未来7天金额/笔数]
    B --> E[expiredStatus=02 金额/笔数]
    C --> F[分转元]
    D --> F
    E --> F
    F --> G[返回页面]

13. 分期还款单创建

13.1 调用链

BtInstallment::installmentReturnSubmit
  -> BaitiaoInstallmentSer::installmentReturnSubmit
  -> BaitiaoInstallmentValidate::scene('installmentReturnSubmit')
  -> KzOrderNo::getHKDNo(sid)
  -> RepaymentOrderModel::cancelUnpayByShipperCodeAndSid
  -> RepaymentOrderModel::addBatch
  -> InstallmentRepayProvider::installmentReturnBatchSubmit

13.2 逐步写入

13.3 分布式事务窗口

sequenceDiagram
    participant S as BaitiaoInstallmentSer
    participant DB as DGJ2 DB
    participant O as OPS Manager
    S->>DB: BEGIN
    S->>DB: 取消旧未支付还款单
    S->>DB: 批量插入新还款单
    S->>O: 批量创建外部还款单
    alt 外部失败
        O-->>S: error
        S->>DB: ROLLBACK
    else 外部成功
        O-->>S: success
        S->>DB: COMMIT
    end

高风险点：外部调用在本地数据库事务内。若外部已成功，但本地连接在提交时失败，外部存在还款单而本地没有；直接重试可能生成新的 sourceNo 和重复外部单。恢复前必须同时查询两端，不能只重跑接口。

14. 三种主动还款方式

发起成功只表示支付中心受理。页面应显示“处理中”并轮询业务状态或等待回调，不应立即把本地还款单改为已还款。

15. 授信还款回调

PayCenterNotify::paycenterBaitiaoReturnPayResult 消费 paycenter_baitiao_return_pay_result。

flowchart TD
    A[收到授信还款成功事件] --> B[按 sourceNo 查询本地还款单]
    B --> C{本地存在?}
    C -- 否 --> D{returnMethod == 03?}
    D -- 否 --> E[NACK: 单号不存在]
    D -- 是 --> F[按 sid/shipperCode/adjustNo 补建自动还款单]
    C -- 是 --> G[检查 state]
    F --> G
    G --> H{state == 1?}
    H -- 是 --> I[当前实现抛异常并NACK]
    H -- 否 --> J[查询供应商和支付账户]
    J --> K[生成其他支出付款单]
    K --> L[本金/利息/滞纳金付款明细]
    L --> M[写账户流水并更新还款单]
    M --> N[事务成功 ACK]

15.1 自动还款补单

当本地不存在 sourceNo 且 returnMethod == '03' 时，消费者允许按事件中的：

• sid
• shipperCode
• adjustNo

补建本地还款单。发起人优先取站点主账号，取不到为 0。其他还款方式找不到本地单时直接失败。

15.2 财务拆分

回调 details 按 code 区分并映射到付款类别：

外部金额除以 100 写入付款主明细的“元”字段；还款单原始金额保留“分”口径。排查总额时必须统一单位后再比较。

15.3 重复消息风险

当前代码发现 repaymentOrderInfo.state == 1 时抛异常，外层返回 NACK。若 MQ 以 NACK 重投且没有死信上限，已经成功的重复消息可能持续重试。待环境确认消费者重试和死信策略；代码优化方向是将“同一业务结果已成功”识别为幂等 ACK，同时核对金额和支付单号是否一致。

16. 支付异常与未知结果

paycenter_pay_exception 会按来源单号查询采购单，并调用 PoOrderSer::cancelWaitPayOrder 取消待支付订单。处理原则：

1. 支付异常消息不能只看错误文案，要核对银行是否真实扣款。
2. 若支付中心返回失败但银行已扣款，先冻结人工重试，交由支付中心对账。
3. 若采购单已被取消，随后又收到支付成功事件，当前状态校验可能 NACK，属于迟到成功风险。
4. 资金结果未知时，优先主动查询支付中心/银行状态，再决定是否补消息。

flowchart TD
    A[页面支付失败或超时] --> B{银行是否扣款?}
    B -- 否 --> C[查支付中心支付单状态]
    B -- 是/不确定 --> D[禁止重复支付]
    C --> E{支付中心终态?}
    E -- 成功 --> F[查 DGJ2 是否落账]
    E -- 失败 --> G[确认采购单取消或可重新支付]
    E -- 处理中 --> H[等待回调/对账]
    D --> C
    F --> I{本地完整?}
    I -- 否 --> J[按幂等键补消息或人工补账审批]

17. 到期提醒与逾期锁站

17.1 分期到期提醒

paycenter_installment_expire：

1. 按 sid 查询服务站联系人。
2. 统计 installmentOrderList 数量和 stayTotalAmountYuan。
3. 发送账户主题站内信。
4. 发送分期到期短信。
5. 站内信或短信失败均返回 NACK。

提醒事件不会直接扣款，也不会更新还款状态。

17.2 逾期锁站状态

stateDiagram-v2
    [*] --> 正常可用
    正常可用 --> 延期锁定: lockStatus=03
    延期锁定 --> 正常可用: DGJ2执行解锁
    正常可用 --> 已锁站: lockStatus=02且时间不早于10:00
    延期锁定 --> 已锁站: 后续收到02且时间满足
    已锁站 --> 正常可用: lockStatus=01

批量事件逐站处理；单个站点异常只记录并继续，外层仍可能 ACK。因此必须从日志核对每个 sid 的实际结果，不能只看整条 MQ 是否消费成功。

18. 核心表与分片

SCM_PAYMENT_SUB_NUM = 32，付款相关表查询必须使用项目 Model 的 setSid() 或按 sid 正确路由，不能只查一个物理表后认定“没有付款单”。账户表的具体分片规则应以 Model 为准。

erDiagram
    SCM_PO_ORDER ||--o{ SCM_PO_ORDER_PAYINFO : has
    SCM_PO_ORDER ||--o{ SCM_PAYMENT_INFO : source
    SCM_PAYMENT ||--o{ SCM_PAYMENT_INFO : contains
    SCM_ACCOUNT ||--o{ SCM_ACCOUNT_INFO : records
    SCM_PAYMENT_INFO }o--|| SCM_ACCOUNT : uses
    SCM_REPAYMENT_ORDER ||--o{ SCM_PAYMENT_INFO : settles
    BS_CONTACT ||--o{ SCM_PAYMENT : counterparty

19. 业务键追踪

20. 事务与一致性矩阵

21. 幂等设计检查

当前排查必须至少核对以下幂等键：

• 支付：sourceOrderNo + payOrderNo + payStatus。
• 还款：sourceNo，并附加 adjustNo、金额和 payTypeCode 校验。
• 分期提交：token 或外部分期申请号。
• 还款单创建：本地 bill_no 与外部 sourceNo 一致。
• 到期提醒：sid + 到期日 + installmentOrderNo，当前代码未见本地提醒去重表。
• 锁站：sid + lockStatus + 事件时间，菜单锁/解锁操作应具备重复执行安全性。

只用“状态已成功”判断幂等还不够，还要检查金额、账户类型和来源单是否一致；否则可能掩盖同单号不同金额的脏消息。

22. MQ 事件地图

Destination：paycenter_notify。

sequenceDiagram
    participant PC as 支付中心
    participant MQ as paycenter_notify
    participant C as PayCenterNotify
    participant DB as DGJ2 DB
    PC->>MQ: routing key + message
    MQ->>C: 投递
    C->>DB: 查业务单和状态
    alt 可处理且事务成功
        C->>DB: 付款/账户/业务状态
        C-->>MQ: ACK
    else 暂时失败或数据不完整
        C->>DB: ROLLBACK
        C-->>MQ: NACK
    end

23. 故障树：二维码获取失败

flowchart TD
    A[二维码/支付链接获取失败] --> B{Controller 是否收到请求}
    B -- 否 --> C[查路由、登录态、菜单权限]
    B -- 是 --> D{参数校验是否通过}
    D -- 否 --> E[核对 sid、单号、手机号、shipperCode]
    D -- 是 --> F{Provider 是否调用外部}
    F -- 否 --> G[查本地异常和前置状态]
    F -- 是 --> H{外部 code 是否为0}
    H -- 否 --> I[按通道错误码查准入/签约/风控]
    H -- 是 --> J{data 是否含URL/二维码}
    J -- 否 --> K[外部响应契约或字段兼容问题]
    J -- 是 --> L[前端展示/CORS/二维码过期问题]

24. 故障树：已扣款但订单未变化

排查顺序必须是资金优先：

1. 用银行流水或支付中心单号确认是否真实成功。
2. 查支付中心是否生成 paycenter_pay_result。
3. 查 RabbitMQ 消费日志是否进入 paycenterPayResult。
4. 核对 sourceOrderNo 是否能查到正确站点和分片原单。
5. 核对 payStatus 是否为 02。
6. 核对原单是否仍在允许支付的状态。
7. 查事务异常，确认付款主单、明细、账户流水是否全部回滚。
8. 查消息是否 NACK 重试、进入死信或被人工丢弃。
9. 未确认外部幂等前，不重新发起支付。

25. 故障树：分期还款后仍显示未还

26. 只读 SQL 模板

以下 SQL 仅为排查模板。先确认实际物理分表、字段名和环境；禁止直接在生产执行更新。

26.1 按采购单号查主单

SELECT id, sid, billNo, billStatus, totalAmount, srcOrderType, create_time, modify_time
FROM t_scm_po_order
WHERE billNo = 'PO_DEMO';

26.2 按站点计算付款分表

SELECT MOD(10001, 32) AS payment_shard;

再按项目实际命名规则查询对应物理表：

SELECT id, sid, billNo, billType, transType, totalAmount, isDisable, create_time
FROM t_scm_payment_XX
WHERE sid = 10001
  AND billNo = 'PAYMENT_DEMO';

26.3 查付款明细来源

SELECT id, iid, sid, stlId, stlNo, amount, accId, wayId, paymentType, create_time
FROM t_scm_payment_info_XX
WHERE sid = 10001
  AND stlNo IN ('PO_DEMO', 'HKD_DEMO')
ORDER BY create_time, id;

26.4 查还款单

SELECT id, sid, uid, bill_no, adjust_no, shipper_code,
       amount, interest, late_fee, state, create_time, modify_time
FROM t_scm_repayment_order
WHERE sid = 10001
  AND (bill_no = 'HKD_DEMO' OR adjust_no = 'ADJUST_DEMO')
ORDER BY create_time DESC;

26.5 查系统账户

SELECT id, sid, number, name, type, create_time
FROM t_scm_account_XX
WHERE sid = 10001
  AND number IN ('1006', '1007', '1008', '1012', '1018', '1020');

26.6 对账守恒检查

SELECT stlNo,
       COUNT(*) AS detail_count,
       ROUND(SUM(amount), 2) AS detail_amount
FROM t_scm_payment_info_XX
WHERE sid = 10001
  AND stlNo = 'HKD_DEMO'
GROUP BY stlNo;

将结果与：还款单 (amount + interest + late_fee) / 100、付款主单 totalAmount、支付中心成功明细统一到元后比对。

27. 日志与代码定位命令

rg -n "paycenter_pay_result|paycenter_baitiao_return_pay_result|paycenter_installment_expire" \
  application/controllers/tasks application/KzData/Enums/MqEventEnums.php

rg -n "sourceOrderNo|payOrderNo|sourceNo|adjustNo|installmentNo" \
  application/controllers/tasks/PayCenterNotify.php \
  application/Services/ExclusiveBaitiao

rg -n "getQRCode|payQrcode|repayQrcode|submitPayOrder|queryRefundStatus" \
  application/controllers/financial application/Providers/OpsManager/Financial

rg -n "SCM_PAYMENT|SCM_REPAYMENT_ORDER|SCM_PO_ORDER_PAYINFO|SCM_ACCOUNT" \
  application/config/tables.php application/models

日志建议同时检索：

• PayCenterNotify
• payCenterPayResult
• paycenterBaitiaoReturnPayResult
• 支付消息通知开始/失败/结束
• 授信还款消息通知
• 来源采购单号、还款单号、支付中心单号和 sid

28. 允许的补偿与禁止动作

28.1 补偿前置检查

1. 确认外部支付/还款终态和唯一支付单号。
2. 确认本地原单、付款、明细、账户流水和还款单的实际状态。
3. 确认原消息是否仍在队列、重试或死信中。
4. 确认消费者对重复成功是否幂等。
5. 制定补偿后的资金守恒验收 SQL。

28.2 可选恢复路径

28.3 禁止动作

• 未确认银行扣款前让用户再次支付。
• 直接修改采购单为已支付而不生成财务数据。
• 只补付款主单，不补付款明细和账户流水。
• 删除已成功还款单后重新发起。
• 用新 sourceNo 替代外部已有的旧还款单。
• 在文档、工单或群聊粘贴完整银行卡、身份证、手机号、签名密钥和证书。

29. 监控建议

30. 安全与合规

• 请求和日志中的银行卡仅保留后四位，身份证仅保留必要掩码。
• 短信验证码不得持久化明文，不得进入普通业务日志。
• 签约 URL、支付 URL 和二维码通常包含短期凭证，不应长期保存或公开。
• Provider 配置中的密钥、证书、商户号不写入知识库。
• 人工补账必须有审批、操作人、原始支付凭证、SQL 前后快照和双人复核。
• 生产查询默认只读，先按 sid 定位分片，再限制单号和时间范围。

31. 回归清单：通道接入

• [ ] 未开通、审核中、已开通、拒绝四类状态展示正确。
• [ ] 短信发送成功、频控、错误手机号、验证码错误、验证码过期。
• [ ] 重复注册和重复签约不产生冲突主体。
• [ ] 银行跳转成功、取消、超时、返回页刷新。
• [ ] 二维码生成、过期、重复获取和跨账号隔离。
• [ ] 单一银行维护不影响其他银行 Provider。
• [ ] 外部 code != 0 时前端显示可理解错误，不泄露敏感响应。
• [ ] 服务站被锁定后金融菜单和接口权限一致。

32. 回归清单：采购支付

• [ ] 普通采购单待支付成功。
• [ ] 预订单支付成功。
• [ ] 零元订单不生成错误资金流水。
• [ ] 企业、个人、返利、待退款、授信、银联、网商和混合账户拆分。
• [ ] 支付失败和支付异常取消待支付订单。
• [ ] 用户中途取消或二维码过期。
• [ ] 银行成功、回调延迟期间页面状态。
• [ ] 相同成功消息重复投递。
• [ ] 同来源单不同支付单号冲突。
• [ ] 支付成功和支付异常乱序到达。
• [ ] 支付超时后迟到成功。
• [ ] 付款主单、明细、账户流水和采购支付信息金额守恒。
• [ ] 32 分片路由正确。
• [ ] 消费事务中任一步失败后完整回滚。

33. 回归清单：分期申请

• [ ] 未签约不可直接分期。
• [ ] 签约短信与当前用户绑定。
• [ ] 单账单和多账单可分期判断。
• [ ] 不同 shipperCode 不混选。
• [ ] 不可分期原因正确展示。
• [ ] 旧版和 V2 模型列表兼容。
• [ ] 首还金额边界、最小金额、最大金额和精度。
• [ ] token 过期、重复使用、跨用户使用。
• [ ] 重复点击提交只产生一笔外部分期申请。
• [ ] 分期批次、明细、服务费和合同可追踪。
• [ ] 未来七天与到期日边界。
• [ ] 分/元聚合无百倍误差。

34. 回归清单：分期还款与逾期

• [ ] 单笔和多笔还款单创建。
• [ ] 同站点同供货方旧未支付单取消。
• [ ] 不同供货方待还款单互不影响。
• [ ] 外部创建失败时本地回滚。
• [ ] 外部成功、本地提交失败的人工恢复演练。
• [ ] 无页面、银联、B2B 三种还款。
• [ ] 主动还款和自动还款回调。
• [ ] 自动还款本地无单时按事件补建。
• [ ] 本金、利息、滞纳金分别落账。
• [ ] 重复还款成功消息的 ACK/NACK 行为。
• [ ] 到期站内信成功、短信失败的重复通知风险。
• [ ] 01/02/03 三种逾期锁定状态。
• [ ] 09:59 与 10:00 锁站边界。
• [ ] 批量锁站中单个站点失败仍有可观察记录。
• [ ] 解锁后菜单、接口和登录态一致。

35. 改动风险分级

36. 已确认事实与待确认项

36.1 已从当前代码确认

• 金融通道 Controller 和方法清单。
• 分期 Provider 的外部路径和 code == 0 成功判断。
• 分期签约短信、本地验证码校验和签约 URL 顺序。
• 可分期、模型、token、提交、待还列表、服务费和合同调用链。
• 还款单在本地事务内新增并调用外部批量接口。
• 还款账户键由 accountType-sid-shipperCode 组成。
• 支付中心 destination 和本文涉及的 routing key。
• 支付成功要求 payStatus == '02'。
• 自动还款可在本地无原单时补建还款单。
• 还款金额按分转元写付款数据。
• 重复已还款消息当前会抛异常并 NACK。
• 分期到期发送站内信和短信。
• 锁站状态 02 在 10:00 前被跳过，01/03 解锁。

36.2 待环境或外部系统确认

• 各银行生产路由、商户配置、签名算法、证书轮换和超时。
• 外部注册、签约、支付、退款和分期状态全集。
• 分期 token 有效期、幂等约束和重复提交返回。
• firstReturnAmount 等金额字段的正式单位合同。
• 支付中心 publisher confirm、重试次数、死信和消息保留时间。
• 本地付款、账户和还款表的生产唯一索引。
• 支付中心对迟到成功、重复成功和支付异常乱序的责任边界。
• 逾期批量事件是否保证同一站点有序。
• 通知中心短信去重和频控。

37. 证据来源

• application/controllers/financial/B2bPay.php
• application/controllers/financial/BridgeBank.php
• application/controllers/financial/BtInstallment.php
• application/controllers/financial/Cmbc.php
• application/controllers/financial/Icbc.php
• application/controllers/financial/IcbcE.php
• application/controllers/financial/Jdsk.php
• application/controllers/financial/Lakala.php
• application/controllers/financial/Mxsk.php
• application/controllers/financial/MyBank.php
• application/controllers/financial/OtherBank.php
• application/controllers/financial/TaiLong.php
• application/controllers/financial/Xiaoyudian.php
• application/Services/Financial/*
• application/Providers/OpsManager/Financial/*
• application/Services/ExclusiveBaitiao/BaitiaoInstallmentSer.php
• application/Providers/OpsManager/Baitiao/BaitiaoInstallmentProvider.php
• application/Providers/OpsManager/Baitiao/InstallmentRepayProvider.php
• application/controllers/tasks/PayCenterNotify.php
• application/controllers/tasks/QPayCenterNotify.php
• application/KzData/Enums/AccountEnums.php
• application/KzData/Enums/PaymentEnums.php
• application/KzData/Enums/InstallmentEnums.php
• application/KzData/Enums/MqEventEnums.php
• application/config/tables.php

38. 一页式交接结论

1. 银行 Controller 只负责“能否用、怎样签、怎样拿入口”，不能据此认定资金成功。
2. 采购支付以 paycenter_pay_result 且 payStatus == '02' 为资金成功入口。
3. 支付成功后必须同时核对原单、付款主单、付款明细、账户流水和采购支付快照。
4. 分期申请围绕 adjustNo -> model -> token -> submit；token 是一次性方案快照。
5. 分期还款围绕 installmentNo -> sourceNo -> repayment_order -> paycenter callback。
6. 外部金额多为分，本地财务展示多为元，任何修改先做单位表。
7. 还款单创建存在“外部成功、本地提交失败”的分布式事务窗口。
8. 重复已还款消息当前可能持续 NACK，是生产重试风险点。
9. 到期提醒失败会重投，逾期锁站批量中单站失败可能被整批 ACK 掩盖。
10. 所有人工恢复都必须以原支付单号/还款单号为幂等键，并完成资金守恒验收。

请求-日志-数据变更追踪卡

多入口请求链路

日志证据矩阵

| 链路段 | 日志来源 | 可检索锚点 | 成功信号 | 失败信号 | 与下一段关联方式 | | --- | --- | --- | --- | --- | --- | --- | | 签约申请 | Financial Controller/Provider | request_id、sid、application/token ID | 返回受理/签约 URL | 配置关闭、token 过期、外部拒绝 | application ID 查签约状态 | | 分期下单 | Provider | 来源单、installment order ID、金额/期数 | 外部订单 accepted | 超时、金额/期数不支持、重复 | 外部订单号关联本地来源单 | | 支付回调 | PayCenterNotify | payOrderNo、来源单、event/message ID | 支付/授信记录一次落库 | 重复占额、迟到/乱序 | payOrderNo 查本地资金表 | | 退款还款 | Provider/Consumer | original pay、refund/repayment ID | 外部成功且额度/余额一次恢复 | 外部成功本地失败、重复返还 | 原支付单串联正反向流水 |

环节数据变更台账

子模块追踪：bank-pay 银行与聚合支付

子模块追踪：installment-config 授信分期模式配置

子模块追踪：installment-sign 分期签约

子模块追踪：installment-apply 分期申请与服务费

子模块追踪：installment-pay 分期支付回调

子模块追踪：installment-lock 延迟、逾期与锁定

子模块追踪：installment-refund 分期退款

子模块追踪：installment-repay 分期还款与额度恢复