附录：代付匹配与账单待定
所属：Paisa 运营人员指南 · 附录（代付专题）
上一篇：常见问题与参数表 · 返回：运营指南导读
与 第 6 篇：爬虫与账单匹配、第 5 篇：LOCAL 代付 配套阅读。
适用范围：印度地区代付订单（平台代用户向第三方付款）
时区：印度时间（IST，UTC+5:30）
阅读对象：业务、运营、客服、产品同学
一、为什么需要这套规则
代付订单成功与否，最终要看「钱包侧账单」是否能找到一笔与订单匹配的真实交易。
- 早期规则：必须找到一笔已成功的账单，金额、收款方、时间窗口都一致，才确认订单成功；只要钱包侧没成功，系统就直接把订单彻底拒绝。
- 现实问题：很多印度钱包（如 Mobikwik、Freecharge）会出现**「正在处理」**状态。这种交易：
- 实际可能在几小时甚至 3-8 天后才变成成功；
- 也可能最后被钱包判定失败。
- 影响：在原规则下，承兑用户已经付了钱，但订单却被系统提前拒绝；事后即使账单变成功，订单也已经"无法挽回"，需要客服手工排查、重发。
新方案的目标：让系统不要急着拒绝，先把订单挂在「待定」状态等一段时间，等账单结果落定后再做处置。
二、订单进入系统后的几种结局
一笔代付订单进入系统、爬虫拉到钱包账单后，可能落到以下几种结局之一：
| 结局 | 含义 | 主单状态 | 子单状态 |
|---|---|---|---|
| 直接成功 | 找到一笔金额、收款方、时间都完全吻合且账单已成功的交易 | 成功 | 成功 |
| 少付待补足 | 找到一笔成功交易，但金额不够；等用户补转剩余金额或客服处理 | 进行中 | 审核中 |
| 账单待定 | 找到一笔金额/收款方匹配的交易，但账单本身还是"正在处理"，结果未知 | 进行中 | 审核中 |
| 彻底拒绝 | 完全没找到匹配的交易，确认这笔订单失败 | 待处理 | 失败 |
后两种都对应"审核中"，但触发原因不同，审核备注里会写清楚，客服能一眼区分。
三、新增的"账单待定"具体怎么走
1. 命中条件（满足任一即可挂起）
只要爬虫拉到的账单里存在一笔同时满足以下条件的交易，且该交易状态是「正在处理」：
- 方式 A（按银行流水号匹配）：交易的银行流水号 (UTR) 与用户提交的一致，时间在订单创建后的合理窗口内，收款方账号末四位匹配。金额此时不要求一致（多付、少付、刚好都可以）。
- 方式 B（按收款方+金额匹配）：交易的收款方账号末四位与订单一致，金额刚好一致，时间在窗口内。用于用户没提交银行流水号、或者填错时的兜底命中。
两种方式都没命中，则按原有"少付容错 / 彻底拒绝"路径处理。
2. 挂起后系统会做什么
订单子单保持「审核中」，备注写入清晰原因，例如：
账单待定：实付 200.00 / 应付 200.00，UTR=103308474340，钱包状态=正在处理
同时把这笔订单纳入"等账单结果"的清单。期间不再额外触发爬虫，避免对上游钱包造成额外压力。
3. 系统怎么判定结果
平台本来就有一个全局账单同步任务，每 4 小时一次把所有承兑用户的钱包账单拉一遍。每次同步：
- 若发现某笔之前是"正在处理"的账单变成了成功 → 自动把对应订单确认为成功；
- 若发现变成了失败 → 自动按彻底拒绝处理；
- 若仍是"正在处理" → 继续等下一轮（最多 4 小时后再判一次）。
最坏情况下用户能看到的延迟：4 小时（同步周期）。绝大多数情况下要快得多，因为 Mobikwik 这类钱包一般会在十几分钟到几小时内出最终结果。
4. 兜底机制（避免无限等待）
为了避免极端情况下账单一直停在"正在处理"，系统每小时会扫一遍待定中的订单：
- 默认 72 小时：超过 72 小时仍未出结果 → 视为失败，自动彻底拒绝，备注会标明"超过 X 小时未定，系统兜底拒绝"。
- 这个阈值可以按钱包灵活调整：Mobikwik 一般 24h 内见分晓，72h 完全够用；Freecharge 的提示文案明确说"3 到 8 天内更新"，运维可把上限调到 192 小时（8 天）覆盖最坏场景。
5. 期间管理员/客服能做什么
完全复用现有审核页面，无需新接口：
- 通过：客服核实已成功 → 一键通过 → 订单成功；
- 彻底拒绝：客服确认失败 → 一键拒绝 → 订单失败；
- 申诉：交给承兑用户 24 小时内处理。
任何人工操作落定后，"待定"标记自动清除，订单不再被后台扫描重复处理。
四、四种结局对比（含原有「少付」场景）
| 维度 | 直接成功 | 少付待补足 | 账单待定（新） | 彻底拒绝 |
|---|---|---|---|---|
| 触发原因 | 账单已成功，金额刚好 | 账单已成功，但金额不够 | 账单尚未出结果（正在处理） | 找不到任何匹配交易 |
| 子单状态 | 成功 | 审核中 | 审核中 | 失败 |
| 等待目的 | — | 等用户补足金额 | 等钱包出结果 | — |
| 系统自动收敛 | — | 24 小时后未补足 → 自动拒绝 | 72 小时后仍未出结果 → 自动拒绝 | — |
| 通知承兑用户 | 否 | 是（Telegram 提示补足，含截止时间） | 否（无需用户操作） | 否 |
| 人工干预入口 | — | 审核页通过/拒绝 | 审核页通过/拒绝 | — |
| 期间是否再爬虫 | — | 不再爬 | 不再单独爬，复用 4 小时一次的全局账单同步 | — |
关键区别：
- "少付待补足"需要用户行动（补转钱），所以会发 Telegram 通知，24 小时短截止；
- "账单待定"用户已经付完了，等的是钱包系统，所以不打扰用户，72 小时长截止。
五、完整流程图
六、运营常见问题
Q1：为什么订单显示"审核中"已经很久了？
A：可能是两种情况——
- 钱包账单仍在"正在处理"（最长 72 小时，可后台调整）；
- 之前命中了"少付"，等用户补足（24 小时截止）。
打开审核页查看"审核备注"即可确认。
Q2：账单待定的订单可以手动放行吗？
A：可以。客服在审核页核实账单确实成功后，点"通过"即可立刻流转，无需等系统自动判定。
Q3：72 小时太短/太长？
A：可由后台调整「账单待定最长保留时间」（默认 72 小时）。
- 全部钱包平均：72 小时已足够；
- 仅 Freecharge 时：建议调到 192 小时（8 天）覆盖钱包侧明示的最坏延迟。
Q4：系统会不会一直反复爬同一笔订单的账单？
A：不会。订单进入"待定"后不再单独发起爬虫，只复用 4 小时一次的全局账单同步，对上游钱包零额外压力。
Q5：钱包账单一直是"正在处理"，但用户的钱已经实际到账了，怎么办？
A：客服直接通过即可（不依赖爬虫判定）。系统会同步把"待定"标记清除。
Q6：这条规则会影响代收订单（用户给平台付款）吗？
A：不会。本规则仅作用于代付（平台向用户付款），代收方向的匹配逻辑保持原状。
七、可调参数一览
| 参数（运营说法） | 默认值 | 含义 |
|---|---|---|
| 账单待定最长保留时间 | 72 小时 | 到点后系统兜底彻底拒绝 |
| 待定兜底扫描频率 | 每小时约 23 分扫一次 | 检查是否已超过最长保留时间 |
少付场景的 24 小时截止时间属于另一条独立规则，不受「账单待定最长保留时间」影响。
八、与原方案相比的收益
- 减少误拒：原本会被立刻拒绝的"账单待定"订单，绝大部分能在几小时内被自动判定为成功，承兑用户不再被冤枉。
- 减少客服工单：原本需要客服手动排查、补录的场景，系统自动收敛终态。
- 上游压力可控：复用现有 4 小时一次的全局同步任务，没有新增任何针对单笔订单的高频爬虫。
- 审计完整：从"进入待定"到"出结果"全过程在数据库中可追溯，子单备注也写明原因。
返回目录 → 运营指南导读