HK 出入金业务手册

深色模式

退款与冲正 ​

本页说明

讲什么：入金系统中三种退款/冲正机制的产品逻辑——什么时候用哪种、系统做了什么、失败了怎么办 适合谁：需要理解退款全貌的产品经理 前置阅读：入金方式总览、入金规则速查预计阅读：8 分钟 负责人：入金产品经理

核心要点：入金系统有三种反向操作——任务冲正（已入账资金扣回）、流水退款（仅标记不动账）、BST 银行退款（天星独有），使用场景和系统行为完全不同。

快速跳转 — 你可能想做的事：

三种退款机制对比 ​

入金系统有三种"已完成交易的反向操作"，虽然用户侧看起来都是"钱退回来了"，但系统行为完全不同：

任务冲正（Task Reversal）流水退款（Flow Refund）BST 银行退款（REFUNDED）
一句话已入账的钱从证券账户扣回标记银行流水为"已退款"，不动证券账户天星银行主动退回已入账资金
触发方运营主动发起运营主动发起银行自动触发
资金影响有 — SBA 从证券账户扣款无 — 仅标记流水状态有 — 系统自动执行 SBA 扣款
前置状态Apply.status = 2（已完成）Flow.status = 0（待处理）入金已完成
结果状态Apply.status = 5, Task.status = REVERSEFlow.result = 3（RESULT_REFUND）入金记录标记 REFUNDED
权限要求CASH_IN_TASK_REVERSECASH_IN_FLOW_HANDLE系统自动，无需权限
是否可撤销不可撤销不可撤销不可撤销
API 入口/deposit/reverse/flow/refund、/flow/refund-batch天星 API 回调
适用场景银行 chargeback、错误入账、风控拦截流水无法匹配且需退回银行、错误流水清理天星 BST 独有——银行事后合规退款
涉及银行所有所有仅天星

核心区别

任务冲正动真金白银（从证券账户扣款）；流水退款只是标记流水状态，证券账户余额不变。搞混这两种操作会导致资金差异——如果本该做任务冲正却只做了流水退款，用户证券账户里的钱不会被扣回。

任务冲正（Task Reversal） ​

任务冲正是最"重"的退款操作——它会把已经入账到用户证券账户的资金扣回。

状态流转 ​

系统执行步骤 ​

当运营点击「冲正」后，系统依次执行：

  1. 状态校验：确认 Apply.status = 2（已完成）且非处理中
  2. SBA 反向编排：调用 turnAround('CashDepositReverse', ...) 从证券账户扣回资金
  3. 状态更新：Apply.status → 5（已冲正），Task.status → REVERSE
  4. 银行卡解绑：如果是通过绑卡入金的（notice_type = BIND_CARD），自动解绑该银行卡
  5. 通知用户：发送冲正通知（App 推送 + 消息中心）

前置条件 ​

条件说明
申请状态 = 已完成（2）只有已完成的入金才能冲正。处理中（1）的不允许
权限 CASH_IN_TASK_REVERSE操作人必须有冲正权限
证券账户余额充足冲正需要从账户扣款，余额不足会导致 SBA Procedure 失败

SBA 反向编排 ​

任务冲正的核心是 SBA（Server Bank Account）的反向 Procedure。系统先检查原入金的 SBA Procedure 状态是否为 PROCEDURE_STATUS_END_OK（即原入金确实成功了），然后调用 turnAround 执行反向操作。

反向操作的本质：把原入金 Procedure 的每一步倒过来执行——原来是"公司账户 → 证券账户"的资金划转，反向就是"证券账户 → 公司账户"。

代码位置
  • 任务冲正入口：deposit/src/app/Business/Deposit.php:877-935 — reverse() 方法
  • SBA 反向调用：deposit/src/app/Business/SOA/SBA/Deposit.php:309 — turnAround('CashDepositReverse', ...)
  • 冲正中间件：deposit/src/app/Business/Tasks/Deposit.php:276-287 — reverseMiddleware()
  • Apply 状态常量：deposit/src/app/Business/Apply.php — STATUS_REVERSE = 5
  • Task 状态常量：deposit/src/app/Classes/Task/Status.php — REVERSE = 5
  • API 入口：DepositController::reverseAction() — /deposit/reverse
  • 批量冲正：DepositController::batchAction() — /deposit/batch with action=reverse

流水退款（Flow Refund） ​

流水退款比任务冲正"轻"得多——它只标记银行流水的处置结果为「退款」，不影响证券账户余额。

什么时候用流水退款 ​

  • 银行流水到了系统，但无法匹配到任何入金申请，且确认需要退回银行
  • 银行流水匹配错误（匹配到了错误的用户），需要先退款再重新处理
  • 流水本身有问题（重复流水、测试流水等），需要清理

状态流转 ​

三种操作入口 ​

操作API 入口场景
单笔退款/flow/refund对单条流水标记退款
批量退款/flow/refund-batch批量标记多条流水为退款
解锁退款/flow/unlock with is_refund=1先解锁被锁定的流水，同时标记退款

流水退款 vs 任务冲正 ​

维度流水退款任务冲正
操作对象银行流水（Flow）入金任务（Task/Apply）
前提流水处于待处理状态入金已完成（资金已到证券账户）
资金变动无有（从证券账户扣回）
影响范围仅标记流水更新 Apply + Task + SBA + 可能解绑银行卡
使用频率较高（日常流水清理）较低（异常情况才用）
风险等级低高
代码位置
  • 流水退款入口：deposit/src/app/Business/BankFlow.php:674-724 — refund() 方法
  • 解锁退款：deposit/src/app/Business/BankFlow.php:1639-1695 — unlock() with is_refund
  • 退款结果常量：deposit/src/app/Business/BankFlow.php — RESULT_REFUND = 3
  • API 入口：FlowController::refund()、FlowController::refundBatch()

BST 银行退款（REFUNDED） ​

这是天星 BST 独有的异常状态——招行和民生的 BST 没有退款机制。

触发条件 ​

  • 银行侧事后发现交易异常（合规问题），主动发起退款
  • 银行风控系统事后拦截

系统行为 ​

REFUNDED vs FAILED ​

REFUNDEDFAILED
资金状态入金已成功，银行事后退回银行拒绝入金，资金从未到账
系统影响需执行冲正（SBA 反向扣款）无需冲正，直接标记失败
复杂度高——已入账资金可能已被用户交易低——只需更新状态
运营介入必须——确认退款原因、通知用户通常不需要

退款决策树 ​

收到退款/冲正需求时，按以下路径判断该走哪条操作：

关键判断：

  1. 资金是否已到证券账户 — 已到账用任务冲正，未到账用流水退款
  2. 谁发起的 — 运营主动走手工冲正，银行自动走系统处理
  3. 余额是否充足 — 不足时需要先协调（用户可能已用资金交易）

CRM 退款管理流程 ​

当退款需求通过客服渠道进入时，走 CRM 退款管理模块的三阶段流程。CRM 是退款的"入口"——它管理审批流程，确定走哪种退款路径后，最终执行的还是上面介绍的三种机制之一。

阶段负责团队关键动作SLA
登记客服记录用户投诉、填写退款原因、关联入金记录当日
审核业务运营核实退款依据、确认走冲正还是流水退款、评估余额影响1 工作日
处理财务执行系统操作（冲正/流水退款）、确认银行侧资金回退1~3 工作日

CRM 不直接操作资金

CRM 退款管理模块只管理审批流程，不直接操作证券账户余额或银行资金。所有实际的资金操作都通过 SBA Procedure 执行。

退款失败与恢复 ​

SBA Procedure 执行失败 ​

症状：冲正操作发起后，Apply 状态未变为 5，SBA 日志显示 Procedure 失败。

可能原因：

原因表现处理方式
证券账户余额不足SBA 返回余额不足错误联系用户补足余额，或协调风控冻结账户后处理
SBA 服务异常Procedure 超时或返回系统错误确认 SBA 服务状态，服务恢复后重试冲正
原入金 Procedure 状态异常PROCEDURE_STATUS_END_OK 校验不通过人工核实原入金的 SBA 执行记录，必要时走手工补偿

余额不足的特殊处理 ​

这是冲正失败最常见的原因——用户入金后可能已经：

  • 用资金买了股票（余额被持仓占用）
  • 发起了出金（余额在出金途中）
  • 做了其他投资操作

处理路径：

  1. 确认用户当前可用余额和持仓情况
  2. 如果差额不大：等待用户卖出持仓或出金到账后重新冲正
  3. 如果差额较大或紧急（如银行 chargeback）：冻结账户 → 联合风控处理 → 分批冲正
  4. 不要尝试部分冲正——系统不支持冲正部分金额，只能全额冲正

流水退款误操作 ​

症状：运营误将正常流水标记为退款，但该流水实际应该用于匹配入金。

处理方式：

  • 流水退款标记后不可直接撤销
  • 需要在 OA 后台手动创建一条新的异常入金（DepositType = ABNORMAL），替代被误退款的流水
  • 记录操作日志，标注"流水退款误操作补偿"

真实案例 ​

案例一：标准冲正 — 银行 Chargeback ​

背景：用户 A 通过 FPS 入金 HKD 100,000，入金成功。3 天后，银行通知该笔 FPS 交易因"未授权交易"发起 chargeback。

处理过程：

  1. 运营收到银行 chargeback 通知
  2. 在 OA 找到对应入金申请（Apply.status = 2）
  3. 确认用户证券账户可用余额 ≥ HKD 100,000
  4. 确认无在途出金任务
  5. 执行任务冲正 → Apply.status → 5
  6. SBA 执行 CashDepositReverse，从证券账户扣回 HKD 100,000
  7. 用户收到冲正通知

结果：冲正成功，银行卡自动解绑（因为是绑卡入金）。

案例二：余额不足冲正 — 用户已交易 ​

背景：用户 B 入金 HKD 500,000 后，买入了 HKD 450,000 的股票。随后运营发现该笔入金为错误入账（匹配到了错误用户）。

处理过程：

  1. 尝试冲正 → SBA 返回余额不足（可用余额仅 HKD 50,000，持仓占用 HKD 450,000）
  2. 冻结用户账户，防止进一步交易
  3. 联系用户说明情况，要求卖出持仓
  4. 用户卖出股票后，可用余额恢复到 ≥ HKD 500,000
  5. 重新执行冲正 → 成功
  6. 将 HKD 500,000 重新入账到正确用户

教训：大额入金冲正应尽快执行（发现问题后第一时间冻结账户），避免用户使用资金后难以追回。

案例三：流水退款 — 无法匹配的孤立流水 ​

背景：一条 HKD 25,000 的汇丰 MT910 流水在系统中存在超过 5 天，匹配引擎多次扫描均无法配对（无对应的入金申请）。

处理过程：

  1. 运营在 OA 流水列表发现该孤立流水
  2. 核实：无用户提交过 HKD 25,000 的入金申请
  3. 联系银行确认：该笔转账为客户误转（转错收款账号）
  4. 在 OA 对该流水执行「退款」标记 → Flow.result = 3（RESULT_REFUND）
  5. 银行侧安排资金退回

说明：此操作只标记流水状态，不涉及证券账户资金变动。资金退回由银行侧完成。

冲正时效参考 ​

操作预期耗时说明
任务冲正（余额充足）秒级SBA Procedure 通常几秒内完成
任务冲正（余额不足）数小时~数天取决于用户配合释放资金的时间
流水退款即时仅标记状态，立即生效
BST REFUNDED分钟级系统自动处理，但运营需后续跟进
银行侧资金退回1~5 个工作日取决于银行处理速度和转账类型

常见误解 ​

误解事实
"冲正和退款是一回事"不是。任务冲正会从证券账户扣款（动真金白银），流水退款只标记流水状态（不动证券账户）。混用会导致资金差异
"冲正失败了可以重试"可以重试，但要先排查失败原因（通常是余额不足）。盲目重试不会改变结果
"可以冲正部分金额"不可以。系统只支持全额冲正——要么全冲，要么不冲。没有"冲正 HKD 50,000 中的 30,000"这种操作
"流水退款后资金会自动退回银行"不会。流水退款只是系统内部标记，资金退回需要银行侧另行处理
"所有银行都有 REFUNDED 机制"不是。REFUNDED 是天星 BST 独有的状态，招行和民生的 BST 没有退款机制
"冲正后用户还能看到原入金记录"可以。冲正不删除记录，只是把状态改为"已冲正"（5）。用户在 App 中可以看到这条记录及其冲正状态

读完之后 ​

我想...去看
看运营怎么操作冲正冲正/退款指引
排查冲正失败的问题入金排障 § 冲正失败
查冲正相关的状态码和 API入金规则速查 § 冲正参考数据
修改冲正流程入金变更指南 § 修改冲正流程
了解入金的完整生命周期入金方式总览
了解匹配后的冲正路径匹配与自动入账 § 匹配后路径
这个页面有帮助吗？

内部业务文档 · 仅限 moomoo 团队使用

© 2026 moomoo HK · 出入金产品团队