跳到主要内容

CW与MC的交互说明

刚上手系统，容易分不清 MC（四方） 后台 和 CW（三方） 后台 的区别。
也容易搞混：订单先出现在什么系统、最终由谁执行、异常时该去哪里排查。

本章节将从 系统定位、职责分工、交互关系、订单流转 四个方面，帮助你快速理解
MC（四方） 和 CW（三方） 之间的关系。

一、MC（四方）与 CW（三方）的系统定位​

1. MC（四方） 是什么？​

MC（四方） 可以理解为：
商户侧后台 / 平台调度后台

MC（四方） 主要负责：

  • 对接商户
  • 接收商户提交的订单
  • 管理商户余额与账务
  • 配置订单走哪条通道、哪一个上游
  • 查看商户订单流向与平台整体运营情况

也就是说：

MC（四方） 更偏向“商户入口”和“订单调度中心”

2. CW（三方） 是什么？​

CW（三方） 可以理解为：
跑分工作者执行后台 / 实际收付执行后台

CW（三方） 主要负责：

  • 管理阿三（收款 / 付款工作者）
  • 管理阿三绑定的 UPI 工具（CT）
  • 执行代收、代付任务
  • 记录真实银行流水（CT Bill）
  • 跟踪账单匹配、Pending、掉单、重复 UTR 等问题

也就是说：

CW（三方） 更偏向“执行层”和“真实收付款落地系统”

二、MC（四方）与 CW（三方）的核心区别​

1. 一句话理解​

  • MC（四方）：负责接单、分单、看商户
  • CW（三方）：负责执行、收钱、付款、看账单

2. 对比理解​

对比项MC（四方） 后台CW（三方） 后台
系统定位商户管理中心执行工作者管理中心
面向对象商户、通道、上游阿三、UPI、账单、执行订单
核心作用接收订单、分配订单、管理商户实际执行订单、核对真实流水
看什么数据商户订单、通道流向、上游流向、平台总览CT账单、代收订单、代付订单、个人CT、额度
谁在用商务、运营、管理、技术客服、运营、风控、执行管理
核心关注点订单有没有进入平台、走到哪里钱有没有真实到账 / 付出去、UTR 是否匹配

三、MC（四方）与 CW（三方）的系统交互关系​

1. 整体关系​

MC（四方） 和 CW（三方） 不是两个独立无关的系统，
而是 同一套业务中的两个不同层级后台。

你可以把它们理解成：

  • MC（四方） = 前台调度中心
  • CW（三方） = 后台执行中心

2. 交互逻辑​

通常情况下，流程是这样的：

  1. 商户先把订单提交到 MC（四方）
  2. MC（四方） 根据通道配置，把订单分发到对应链路
  3. 如果该链路需要阿三执行，则会进入 CW（三方）
  4. CW（三方） 再分配给具体的阿三 / UPI 工具去完成收款或付款
  5. 执行结果再返回给 MC（四方）
  6. MC（四方） 最终把结果回调给商户

3. 一句话记忆​

MC（四方） 负责“订单从哪里来、往哪里去”
CW（三方） 负责“这笔钱是谁收的、谁付的、有没有真实发生”

四、为什么需要 MC 与 CW 两个后台系统？​

因为平台业务不是只有“接单”这么简单。

一笔订单从商户发起，到最终成功，通常会经过两层逻辑：

第一层：平台层逻辑（MC（四方））​

平台需要知道：

  • 订单是哪家商户发来的
  • 商户有没有余额
  • 订单该走哪条通道
  • 订单最终该分到哪个上游
  • 该给商户返回什么结果

这些事情都属于 平台调度与商户管理，所以放在 MC（四方）。

第二层：执行层逻辑（CW（三方））​

如果订单最终需要通过阿三、UPI、银行卡等方式实际完成收付，
平台还需要知道：

  • 具体是哪一个阿三接了单
  • 阿三使用哪个 UPI 工具
  • 银行真实流水有没有出现
  • UTR 是否匹配
  • 有没有 Pending、No Pick Up、掉单、私人交易

这些事情都属于 真实执行与账单核对，所以放在 CW（三方）。

五、代收订单流转流程​

1. 代收的本质​

代收 = 商户拉起收银台二维码，用户付款，阿三收款，平台确认到账

也可以理解为：

钱流入平台执行链路

2. 代收流转步骤​

第一步：商户在 MC（四方） 发起代收订单​

商户通过接口或后台提交一笔代收订单到 MC（四方） 系统。

此时 MC（四方） 会记录：

  • 商户是谁
  • 订单金额是多少
  • 商户订单号是什么
  • 订单状态初始值是什么
  • 订单准备走哪条通道

第二步：MC（四方） 根据通道规则分发订单​

MC（四方） 会根据商户配置好的：

  • 通道
  • 上游
  • 业务规则

来判断这笔订单应该交给哪条链路处理。

如果该链路是 CW（三方） 执行链路，
订单就会继续流转到 CW（三方） 系统。

第三步：CW（三方） 分配给阿三和具体 CT 工具​

订单进入 CW（三方） 后，系统会进一步判断：

  • 哪个阿三具备可用额度
  • 哪个 UPI 工具在线
  • 哪个工具优先级更高
  • 哪个工具当前风险更低

然后把这笔代收订单分给具体阿三执行。

第四步：用户付款，银行产生真实账单​

当用户向阿三的 UPI 付款后：

  • 银行会生成真实交易流水
  • 系统会在 CT Bill 中抓取这笔收款账单
  • 账单会带有 UTR
  • CW（三方） 会尝试用 UTR 去匹配对应代收订单

第五步：CW（三方） 确认到账并更新订单状态​

如果账单和订单成功匹配：

  • 代收订单会更新为成功
  • 阿三额度会被扣除 / 结算
  • 相应账变会记录在 CW（三方） 中

如果没有成功匹配，则可能出现：

  • No Pick Up
  • Pending
  • 掉单
  • 重复 UTR
  • 私人交易

这时通常需要人工审查。

第六步：执行结果回传给 MC（四方）​

当 CW（三方） 完成执行并确认结果后，
结果会同步 / 回传到 MC（四方） 系统。

MC（四方） 更新自己的订单状态后：

  • 订单显示成功 / 失败 / 支付中
  • 平台账务同步更新
  • 最终回调给商户

3. 代收流程时序图​

六、代付订单流转流程​

1. 代付的本质​

代付 = 商户提交一笔付款订单，平台安排阿三付款，最终钱打到指定账户

也可以理解为：

钱从平台执行链路流出去

2. 代付流转步骤​

第一步：商户在 MC（四方） 发起代付订单​

商户将一笔代付请求提交到 MC（四方），
MC（四方） 先记录：

  • 商户信息
  • 收款人信息（银行卡号，IFSC，金额）
  • 商户订单号
  • 订单状态

第二步：MC（四方） 进行分发​

MC（四方） 根据商户配置和通道规则，
决定这笔代付订单应该走哪条执行路径，也可以进行手动派发

如果走的是 CW（三方） 执行链路，
订单就会进入 CW（三方） 代付订单（Pay Order）。并且进入跑分前端的订单展示池中

第三步：CW（三方） 跑分前端展示订单列表​

跑分前端展示订单列表：

  • 按照时间先后顺序展示订单
  • 可以筛选订单金额区间
  • 可以把订单分到惊喜池

阿三自行在跑分前端选择代付订单，阿三开始执行付款。

第四步：阿三付款，银行生成付款账单​

阿三用自己的 UPI 工具完成付款后：

  • 银行会生成真实付款流水
  • 系统会抓取这笔 Send 类型账单
  • 账单里会出现真实 UTR

第五步：CW（三方） 核对付款结果​

如果系统成功匹配到付款账单：

  • 代付订单更新为成功
  • 记录付款时间和相关状态
  • 若失败则进入待审状态

如果账单未正确匹配，则可能出现：

  • 待办 / Pending
  • 可能需要人工审核场景

第六步：结果回传 MC（四方），并通知商户​

CW（三方） 确认结果后，
会将结果同步到 MC（四方）。

然后 MC（四方）：

  • 更新代付订单状态
  • 做平台账务处理
  • 最终把结果通知给商户

3. 代付流程时序图​

七、问题排查：应该查看 MC（四方） 还是 CW（三方）？​

这是最容易混淆的地方。

1. 先看问题属于哪一层​

属于商户层、平台层的问题，先看 MC（四方）​

例如：

  • 商户订单有没有创建成功
  • 商户余额是否正常
  • 订单走了哪条通道
  • 订单最终到了哪个上游
  • 平台有没有成功回调商户

这些问题，优先查 MC（四方）。

属于执行层、账单层的问题，先看 CW（三方）​

例如：

  • 阿三有没有真实收到钱
  • 阿三有没有真实付出去
  • UTR 是否匹配
  • 是否出现 No Pick Up / Pending
  • UPI 是否掉线
  • 是否是重复 UTR、私人交易、误扣

这些问题，优先查 CW（三方）。

2. 一个很实用的判断方法​

查“订单入口”看 MC（四方）
查“真实流水”看 CW（三方）

八、常见业务问题场景​

在日常运营中，最常遇到的问题通常来自两类人员：

  • 商户（MC系统）
  • 跑分工作者 / 阿三（CW系统）

不同角色遇到的问题不同，因此排查思路也不同。

1、代收订单常见问题​

代收订单通常指：

商户发起订单 → 用户付款 → 阿三收款 → 平台确认到账

也就是 钱进入平台执行链路。

场景一：商户反馈 “用户已经付款，但订单没有回调”​

这是代收订单中 最常见的问题。

常见原因​

可能属于以下几种情况：

  1. 掉单/空单

用户已经付款，但订单没有正确进入 CW 执行链路。
CW额度不足，导致出现空单。

  1. UTR 未回填

用户付款成功，但 UTR 没有提交到正确的订单上。

  1. 银行流水未抓取（UPI波动）

CT Bill 没有同步到账单。账单同步延时了

  1. 假支付

用户提供截图，但银行实际上没有真实流水。

排查思路​

1️⃣ 先在 MC（四方） 查询订单

确认：

  • 订单是否存在
  • 当前订单状态
  • 是否已经分发到哪个上游，是否是属于CW的订单

2️⃣ 如果订单已进入 CW（三方），再到 CW系统 查询：

检查：

  • 是否存在对应代收订单
  • 是否存在对应 CT Bill
  • UTR 是否匹配
  • 是否出现 Pending / No Pick Up / Need Ct Idle

3️⃣ 根据账单情况判断：

  • 若存在真实流水 → 可能是 掉单 / 未匹配
  • 若不存在流水 → 可能是 假支付 / 工具掉线

场景二：跑分工作者反馈 “额度被扣了，但钱没有收到”​

这是 CW执行层最常见的问题。

常见原因​

1️⃣ UPI掉线

UPI工具掉线，系统没有正确同步账单。

2️⃣ 私人交易

阿三进行私人转账，系统误识别为平台交易。

3️⃣ Pending账单

系统抓到账单，但用户没有额度可扣，无法确认账单归属。

排查思路​

1️⃣ 在 CW系统 → CT Bill 查询对应 UTR

确认：

  • 是否存在真实银行流水
  • 账单类型是 Receive
  • 当前账单状态

2️⃣ 检查 Pick 状态

  • Pick Up → 已匹配订单
  • No Pick Up → 未匹配订单

3️⃣ 判断账单类型：

  • 若为私人交易 → 让阿三提供证据，人工取消扣除
  • 若为系统订单 → 继续追踪订单匹配情况

2、代付订单常见问题​

代付订单通常指：

商户发起代付订单 → 阿三付款 → 用户收到资金

也就是 钱从平台执行链路流出。

场景三：商户催促 “为什么代付订单还没完成”​

常见原因​

1️⃣ 没有阿三接单

订单已进入 CW，但没有跑分工作者选择执行。

2️⃣ 执行能力不足

金额过小，奖励不足等原因

3️⃣ 订单执行中

阿三已经接单，但仍在付款流程中。

排查思路​

1️⃣ 先在 MC（四方） 查看订单状态

确认：

  • 订单是否成功创建
  • 是否已经进入执行链路

2️⃣ 再到 CW（三方） Pay Order 查询：

查看：

  • 是否已有阿三接单
  • 当前订单状态
  • 是否存在付款账单

场景四：商户反馈 “订单成功，但用户没收到钱”​

常见原因​

1️⃣ 银行延迟到账

部分银行存在到账延迟。

2️⃣ 账户被冻结

收款账户被银行风控冻结。

3️⃣ 收款信息错误

商户提交的收款账户信息错误。

排查思路​

1️⃣ 在 CW Pay Order 查看付款账单

确认：

  • 是否存在真实 Send 账单
  • UTR 是否存在
  • 付款是否成功

2️⃣ 如果存在真实付款流水

说明平台已经完成付款。

此时问题可能在：

  • 收款银行
  • 收款账户
  • 银行风控

场景五：跑分工作者反馈付款异常​

跑分工作者在执行代付时，也会遇到各种情况。

情况一：我已经付款，但订单没成功​

可能原因：

  • UTR 没有正确同步
  • 账单未抓取
  • 订单未匹配
  • 使用错误的UPI支付
  • 填写了错误的收款人信息

需要在 CW Pay Order + CT Bill 中核查。

情况二：我付少了​

阿三付款金额小于订单金额。

处理方式：

  • 订单通常会进入异常状态
  • 需要补足金额或人工处理。

情况三：我付多了​

阿三付款金额超过订单金额。

处理方式：

  • 多付金额需要人工核对
  • 仅给予订单对应金额的补偿。

情况四：付款信息填错​

例如：

把 A订单的付款信息
回填到了 B订单

这种情况会导致：

  • UTR匹配错误
  • 订单状态异常

需要人工核对真实付款流水并重新匹配。

3、总结​

在日常运营中，大多数问题都可以通过 MC + CW 两个系统交叉排查 来解决。

简单记忆：

商户问题 → 先查 MC（四方）

  • 看订单
  • 看流向
  • 看回调

执行问题 → 再查 CW（三方）

  • 看账单
  • 看UTR
  • 看执行情况

📘 提示
若涉及 UTR、CT Bill、Pending、No Pick Up、付款执行情况，
请优先在 CW系统 中排查。

九、快速理解方法​

1. 最简单的记忆方式​

MC（四方） 管商户、管订单入口、管流向
CW（三方） 管阿三、管执行、管真实账单

2. 再简单一点​

MC（四方） 看“平台有没有接到这笔订单”
CW（三方） 看“这笔钱有没有真的收 / 付成功”

3. 最后一句话总结​

MC（四方） 是调度中心，CW（三方） 是执行中心。
MC（四方） 决定订单怎么走，CW（三方） 决定订单有没有真正完成。

十、总结​

MC（四方） 和 CW（三方） 是同一套业务中的两个重要后台，缺一不可。

  • MC（四方） 负责承接商户订单、配置流向、管理商户与平台数据
  • CW（三方） 负责具体执行订单、核对真实银行流水、处理异常账单问题

二者之间的关系不是重复，而是上下游协作：

  • MC（四方） 是订单入口与调度层
  • CW（三方） 是执行落地与核账层

所以在日常工作中，一旦遇到问题，先判断：

这是 “订单有没有进入平台” 的问题，
还是 “这笔钱有没有真实发生” 的问题。

判断清楚这一点，就知道应该优先查 MC（四方） 还是 CW（三方）。

📘 提示1：若涉及商户资料、通道流向、上游配置，请优先查看 MC（四方）。
📘 提示2：若涉及 UTR、CT Bill、Pending、No Pick Up、阿三执行情况，请优先查看 CW（三方）。
📘 提示3：实际查单时，很多问题都需要 MC（四方） + CW（三方） 配合交叉排查，不能只看单一后台。