LOCAL 代付全流程
所属：Paisa 运营人员指南 · 第 5 篇
上一篇：LOCAL 代收全流程 · 下一篇：爬虫与账单匹配
商户发起 代付（平台向终端用户付款）且走 LOCAL 时，由App用户 抢单 后在自家钱包完成转账。商户资金在创单时已划入 代付冻结池（第 3 篇）。
1. 流程总览
2. 创单（商户侧）
- 校验商户 可用余额 + 授信 是否够付本单。
- 路由到 LOCAL（或其它通道）；创建主单 待处理。
- 可用余额减少，代付冻结池增加 相同金额（商户总资金不变）。
- 不立即创建有效子单，等待App用户抢单。
3. 抢单与支付（App用户侧）
- App用户在列表 抢单；系统创建子单 支付中，主单 进行中，并锁定该子单。
- 启动 20 分钟 支付倒计时（与代收 8 分钟不同）。
- 用户向订单收款账号（UPI/银行卡）完成转账。
- 可提交 银行流水号 或 付款截图 → 子单 审核中 → 触发爬虫匹配。
抢单失败：若主单已被他人抢走，本次子单记 取消，提示订单已被抢；该取消不计入「不得再次购买同一主单」限制，用户可继续抢同一主单。
不得重复抢同一主单：若用户曾在该主单上 主动取消 或 最终失败（含审核拒绝、匹配彻底失败等），列表不再展示该主单，且无法再次进入购买/确认抢单；支付超时 不在此列，主单回待处理后仍可再次抢。
同时只能抢一单（例外）：平时同一App用户只能有 一笔 需主动处理的代付单（支付中、审核中待匹配、少付待补足等）。若当前仅有 账单待定（钱包显示「处理中」、系统后台等账单变 success/failed，详见 附录：代付匹配与账单待定），不占用抢单名额，可继续抢 其他 代付主单；支付中或仍在主动处理的审核单仍会挡住新单。
4. 无凭证时的自动查账
- 子单创建满约 4 分钟，且尚无流水号/截图时，自动查 转出账单 一次。
- 20 分钟 到期前再 最后一查；仍未匹配则子单 支付超时，主单回 待处理，可再次抢单。
- 自动查账阶段 不立即判失败，避免账单延迟入库误杀。
5. 匹配结果（摘要）
| 结果 | 子单 | 主单 | 说明 |
|---|---|---|---|
| 直接成功 | 成功 | 成功 | 账单已成功且金额一致 |
| 少付待补足 | 审核中 | 进行中 | 通知用户 24 小时内补足；超时自动拒绝 |
| 账单待定 | 审核中 | 进行中 | 钱包显示「处理中」；靠定期账单同步更新，最长约 120 小时兜底 |
| 多付 | 成功 | 成功 | 实付多于应付仍可按成功处理 |
| 完全对不上 | 失败 | 待处理 | 可再次撮合 |
| 审核中、已过 20 分钟支付超时再 1 分钟 仍对不上 | 失败 | 待处理 | 爬虫成功拉账但未匹配时自动拒绝（含 1009 重试等延后查账） |
详解见 第 6 篇 与 附录：代付匹配与账单待定。
6. 成功后的资金
- 商户：代付冻结池减少，可用余额不回升（实付已落地）。
- App用户：余额增加（含奖励），记流水；返佣/分润另发。
7. LOCAL 代付特有：回池、流转、驳回
LOCAL 代付最怕两件事：大厅里没人抢，或 抢了又连续黄了。前者靠时间等，后者靠「连续子单取消计数」。当 LOCAL 实在接不住时，平台会把 主单（仍是待处理） 转交给 其它下游通道 继续出款——这就是 流转。
7.1 流转是什么（一句话）
商户订单号不变，钱还在代付冻结池里；平台按路由规则，把单子从 LOCAL App 账户池 改派 给别的通道（可能是另一个 LOCAL 变体，也可能是外部三方通道）。
对商户来说：只要没收到「取消」回调，单就还在做。
对App用户来说：一旦转给 外部通道，这单 不会再出现在抢单大厅。
7.2 什么时候能流转 / 不能流转
| 条件 | 能否流转 |
|---|---|
| 主单是 LOCAL 代付 且状态 待处理 | ✅ 可以 |
| 主单已是 进行中（有人抢单、子单支付中/审核中） | ❌ 不行，须等子单结束 |
| 主单已转到 外部下游（通道编码非 LOCAL） | ❌ 已不在 LOCAL 池，走该通道自己的逻辑 |
| 管理端点 驳回 | 不流转，直接整单取消 |
运营记忆点：流转和驳回都只对「待处理 + LOCAL」的主单生效；有App用户正在做时，系统会提示「有进行中的子单」。
7.3 流转之后会发生什么
系统按 路由规则优先级（管理后台「下游机构 → LOCAL 策略 / 路由规则」）依次尝试候选通道：
| 结果 | 主单 | 商户资金 | App侧 |
|---|---|---|---|
| 流转成功 | 仍为 待处理，通道改为新下游 | 冻结池 不变 | 若转到外部通道：活跃子单被取消，用户不能再抢 |
| 无可用下游 | 取消 | 冻结退回可用余额 | — |
| 流转成功且外部通道后续成交 | 成功 | 冻结池减少 | 由外部通道回调驱动，不经过App端 |
流转成功后，主单上的「连续子单取消计数」会 清零，避免刚转走又因历史计数再次触发。
7.4 谁会触发流转（四条路径）
| 触发方式 | 谁干的 | 通俗场景 |
|---|---|---|
| 管理端手动流转 | 运营在「订单明细」点 流转 | 某单 LOCAL 久无人抢 / 连续黄了，人工推一把 |
| 硬兜底自动流转 | 系统定时任务（约每 5 分钟扫一次） | 主单创建已超过配置 小时数 仍是 LOCAL 待处理 |
| 软策略自动流转 | 同上 | LOCAL 待处理池 水位偏高 时，按池子规则批量转走「排队太久」的单 |
| 连续子单取消/超时 | 子单结束回池时自动判断 | 同一主单在 LOCAL 待处理期间，子单 取消或支付超时 累计达阈值 |
子单取消计数说明（仅 LOCAL 待处理主单）：
- 会计入：App用户 主动取消、支付超时（含 20 分钟系统关单）。
- 一般不计入：抢单被别人抢走（那条子单取消但主单当时不是待处理计数场景）、对账 彻底失败（子单失败回池，走再抢而非计数流转）。
- 达阈值后：若后台开关 开启 → 自动流转；若 关闭 → 整单取消 并退回商户冻结。
金额越大，默认要求的连续次数越高（分档表在后台「LOCAL 策略配置」维护，典型默认见 第 8 篇 · 代付流转参数）。
7.5 软策略：LOCAL 待处理池水位（通俗版）
当 LOCAL 大厅里 待处理主单太多 时，系统不能无限堆着，会用「池子水位」决定转多少、转多快：
| 策略 | 什么时候动 | 转哪些单 |
|---|---|---|
| 软超时 | 待处理单数 ∈ [下限, 上限] | 创建时间超过 软超时分钟数 的全部候选 |
| FIFO 溢流 | 待处理单数 超过上限 | 按创建时间 最早 的先转；每周期批量笔数有上限，防止打爆外部下游 |
| 硬兜底 | 与水位无关（独立开关） | 创建超过 硬兜底小时数 的 LOCAL 待处理单 |
典型默认：软超时 5 分钟、池下限 6 单、池上限 15 单、硬兜底 10 小时——均以管理后台「LOCAL 策略配置」为准，印度时间。
7.6 管理端：流转 vs 驳回
| 操作 | 会不会试其它通道 | 结果 |
|---|---|---|
| 流转下游 | 会，按路由优先级逐个试 | 成功 → 换通道继续；全失败 → 取消并退回商户 |
| 驳回 | 不会 | 直接主单 取消、解冻商户、回调商户 |
怎么选：
- 还想把这单做完 → 先 流转（给外部下游或别的 LOCAL 变体一次机会）。
- 确认商户不要了 / 信息有误 → 驳回（最快关单）。
7.7 和「子单回池」的关系
子单 支付超时 或App用户 主动取消 后，主单通常回 待处理，单子重新进大厅——这是日常回池，不等于流转。
只有满足 7.4 中某条触发条件时，才会从 LOCAL 改派 到其它通道；否则主单一直在 LOCAL 等人抢。
连续多次「抢了又黄」时，与其无限回池，系统更倾向于 流转或整单取消，避免商户干等。
7.8 管理端：预约中置顶
当某笔 LOCAL 代付主单处于 待处理（预约中）、尚未被App用户抢单时，运营可在「订单明细」对该单执行 置顶 或 取消置顶：
| 操作 | 效果 |
|---|---|
| 置顶 | 该单在App端 购买列表最前面 展示，卡片带 Hot 标记；可多笔同时置顶，按置顶时间先后排序（先置顶在前） |
| 取消置顶 | 恢复为普通列表排序，不再显示 Hot |
适用条件（与流转/驳回相同）：代付主单、状态 待处理、接单方为 LOCAL。
说明：
- 置顶 不改变 订单状态与资金，仅影响App端列表展示顺序。
- App用户抢单后若子单取消或支付超时、主单 回到大厅（待处理），置顶 仍然保留，无需再次操作。
- 以下情况置顶会失效：运营手动取消置顶；主单 整单取消 / 驳回；主单 流转 离开 LOCAL。
- App端购买列表已移除 Bank/UPI 标签，仅置顶单显示 Hot。
8. 与代收的区别（速记）
| 维度 | LOCAL 代收 | LOCAL 代付 |
|---|---|---|
| 创单时App用户余额 | 派单即减少 | 不变 |
| 创单时商户资金 | 不冻结 | 划入代付冻结池 |
| 支付时限 | 约 8 分钟关单 | 抢单后 20 分钟 |
| 主单超时后 | 多为主单取消 | 多为主单回待处理 |
下一篇 → 第 6 篇：爬虫与账单匹配