LOCAL 通道选卡策略

所属：Paisa 运营人员指南 · 第 1 篇（创单前派卡）
上一篇：运营指南导读 · 下一篇：订单主单与子单

适用范围：商户发起代收时，系统从平台 App 账户池里给这笔订单挑一张「接单卡」。
本文用通俗的话讲清楚「哪些卡可以接、谁优先接、为什么这么设计」，方便运营、风控、客服快速理解。

1. 一句话概览

先用一连串「门槛」过滤掉不该接的卡（含认证免检期），再在剩下的卡里按「最近表现好的优先」做加权随机抽签，取排序第一的可派卡并尝试占位加锁、冻结余额，成功即派单。

选卡过程不再实时调用爬虫校验登录态；每张卡由后台按各自节奏自扫描，扫描通过后写入 Redis「免检期」，免检期内视为认证有效、可参与派单。

2. 选卡流程总览

补充说明：

• 同金额已被占用、余额冻结失败等情况会换下一张卡，不会调爬虫。
• 若当前没有任何处于「认证免检期」内的卡，LOCAL 通道直接失败，订单交给下一个支付通道。

3. 基础合格条件（最低门槛）

只有同时满足下面这些条件的卡，才会进入后续的 6 条派单规则：

这一层是「硬性资格」，连这一关都过不了的卡，不会出现在后续名单里。
系统最低接单公式可在管理后台「LOCAL 策略 → 代收派单最低接单公式」调整；对用户端不可见。
例：用户最高接单设为 9,500 时，不再套用系统门槛（即使公式算出 20,000），只要订单金额在其最低～最高区间内即可进入派单。

4. 6 条派单规则（逐张过滤）

候选名单进来以后，每张卡会被这 6 条规则依次检查，任何一条不满足就直接淘汰。所有「今天」「近 10 分钟」等时间，均按印度时间计算。

规则 ①：当天成功收款不能超过上限

• 什么意思：每张卡每天最多接若干笔「已经收到钱」的订单。默认上限 30 笔，可在管理后台「钱包列表」按卡人工调整（0～100 笔；设为 0 表示当天不再派单）。
• 怎么数：把这张卡当天的银行到账流水，和平台上已成功的代收订单合在一起，按交易号去重后计数。
• 满了怎么办：今天不再派单；印度时间次日 0 点自动清零（计数清零，上限配置本身不变）。

规则 ②：进行中订单不能超过容量上限

• 什么意思：还没出结果的订单太多，就不能再压新单。
• 怎么算：先看今天还能成功几笔（该卡配置的单日成功上限 减去已成功笔数），再按「预估成功率 50%」折算还能接多少在途单。以下示例均按默认上限 30 笔计算：
  • 今天 0 笔成功 → 最多同时接 60 笔进行中
  • 今天 10 笔成功 → 最多同时接 40 笔进行中
  • 今天 28 笔成功 → 最多同时接 4 笔进行中
• 若某卡上限被人工调整为其他值，则公式中的「30」替换为该卡当前配置值。
• 「进行中」包括：支付中、审核中、失败倒计时、失败待补单。
• 目的：从「今天总共还能压多少单」的角度控总量。

规则 ③：同时进行的活单最多 4 笔（试探期更严）

• 什么意思：这张卡同时正在支付或正在审核的订单，平时最多 4 笔。
• 为什么需要：规则 ② 在卡刚开张时上限很宽（最多 26），如果一瞬间灌进很多单，可能多笔一起失败，来不及触发规则 ④ 的冷却。规则 ③ 把「此刻正在跑的单」压到 4 笔，降低误匹配和失败堆积风险。
• 和规则 ② 的区别：
  • 规则 ② 看「今天总共还能压多少在途量」，会随已成功笔数变少而变紧。
  • 规则 ③ 只看「此刻正在支付/审核的单」，固定上限 4 笔。
  • 两条同时生效，取更严的那条。
• 试探期（更严）：若这张卡「最近一次成功之后又已连续失败 5 笔」，失败计数还没被新成功清零，那么即使冷却已过，同时进行的活单也临时只允许 1 笔：
  • 冷却结束后先派 1 笔试水；
  • 试水单还在跑时，不再派第 2 笔；
  • 试水成功 → 失败计数清零，恢复 4 笔上限；
  • 试水又失败 → 重新进入冷却（时长按规则 ④ 的金额浮动）。

规则 ④：连续失败 5 笔，冷却（时长按金额浮动）

• 什么意思：最近一次成功之后已连续失败 5 笔，且最近一笔失败仍在冷却窗口内 → 暂停派单。
• 冷却时长按金额浮动：大额单本身更容易失败，连续失败几笔大额单不代表卡有问题，因此这几笔连续失败单的平均金额越大，冷却时间越短。按平均金额（卢比）折算：
  • 平均金额 ≤ 500：冷却 15 分钟（基准）；
  • 500 ~ 1500：冷却从 15 分钟线性缩短到 10 分钟；
  • 1500 ~ 3000：冷却从 10 分钟线性缩短到 6 分钟；
  • 大于 3000：冷却 5 分钟。
• 哪些算失败：取消、支付超时、订单失败。
• 哪些算成功：银行到账成功，或平台代收订单成功，取最近的那一次。
• 怎么解除：
  • 等满对应冷却时长 → 可以重新派单，但失败计数不会清零，进入规则 ③ 的「试探期」，一次只放 1 笔；
  • 出现一笔新的成功 → 失败计数清零，完全恢复正常。

规则 ⑤：10 分钟内同一钱包同金额不能重复接

• 什么意思：同一个钱包账号过去 10 分钟内，已经有一笔相同金额的代收单还在支付中或审核中，则该钱包下所有收款码（UPI）都不再接新的同金额单。
• 钱包维度（重要）：互斥按「钱包账号」算，不是按单个收款码算。判断口径为「钱包类型 + 钱包登录手机号」——同一个登录账号下绑定的多个 UPI 视为同一个钱包。例如某用户的 Navi 钱包绑了 3 个 UPI，其中一个接了一笔 200 的单，另外两个 UPI 在 10 分钟内也不能再接 200 的单。
• 为什么这样改：Navi 等钱包支持一个登录账号绑定多个 UPI，且账单是按账号合并的，爬一个 UPI 的账单时也会爬到同账号其它 UPI 的账单。到账匹配主要靠「金额 + 时间窗口」，同钱包短时间两笔同金额，容易把一笔到账对错单。
• 并发保护：选中前，系统会立刻给「这个钱包账号 + 这个金额」加一把短期锁（默认 10 分钟），和上面的查询规则一起用，避免高并发下重复派单。锁没抢到就换下一张卡；订单结束或派单失败时会自动释放。
• 特殊情况：极少数没有登录手机号的卡，仍按单卡维度互斥。

兜底：代收金额主动偏移（默认关闭，后台可开）

热门金额（如 200）容易被本规则挡住全部候选卡，订单只能外流到其它通道。为此提供一个兜底开关：管理后台「下游通道 → LOCAL 策略」中的代收金额主动偏移。

• 什么时候才生效：必须同时满足两个条件——① 后台开关已开启；② 本规则过滤后 LOCAL 已经无卡可派。任何一个不满足都不会偏移，派单行为与本功能上线前完全一致。
• 怎么偏移：在原金额下方找一个没有被同金额互斥占用的金额作为 App 侧实付金额，例如 200 → 199.37。系统在配置上限内随机选取向下偏移量（如 -1～-100 分打乱后尝试），只允许向下偏移，不允许向上；单笔订单最多尝试 3 个偏移量，仍找不到就照旧外流。
• 只在被挡住的卡里重选：偏移轮次直接复用上一轮「其余规则全部通过、仅被同金额互斥挡住」的那批卡，不会把整个卡池重新过一遍规则，也不重复查任何统计，因此对创单耗时的影响很小。
• 最大偏移量：后台可配，默认 100 分（即最多向下 1 卢比），允许范围 1～100 分。
• 金额口径（重要）：偏移只影响 App 侧——用户实际付款金额、收款二维码金额、余额冻结与解冻金额、同金额占位、到账账单匹配金额，都用偏移后的金额。商户下单金额、手续费、商户回调金额一律不变，商户侧完全无感知。
• 在哪里能看到：
• 订单管理中，主单金额为商户金额，LOCAL 子单金额为 App 侧实付金额，两者相差即本次偏移量。
• 订单日志 → 查看详情 → LOCAL 选卡：偏移成功时顶部会出现一条橙色横幅「代收金额主动偏移」，标出商户下单金额、App 侧实付金额、本次偏移与尝试轮数；偏移后仍无卡可派时显示为红色横幅，并标出最大偏移与已尝试轮数——看到红色横幅就说明当前最大偏移量偏小或卡池确实枯竭，可据此调参。
• 同一页的选卡漏斗中，每个偏移轮次会单独成一轮，轮次标题旁的「本轮金额」标签即该轮尝试的偏移后金额。

规则 ⑥：当天接太多且成功率太低（门槛按金额浮动）

• 什么意思：这张卡今天代收已经不少，但整体成功率很差 → 暂停派单，让给更稳的卡。
• 怎么算（派单过滤专用口径，与管理后台「今日接单量 / 今日成功率」展示略有不同）：
  • 统计今天印度时间 0 点到次日 0 点之间，这张卡接的代收子单；
  • 总笔数 = 上述范围内全部子单，但不含单笔 ≥ ₹8000 且已终态失败的子单（大额失败不拉低成功率）；
  • 成功笔数 = 其中已成功的子单（含大额成功）；
  • 成功率 = 成功笔数 ÷ 总笔数；
  • 平均金额 = 参与统计的子单金额合计 ÷ 总笔数（大额失败金额亦不计入）。
• 成功率门槛按金额浮动：大额单本身成功率就偏低，如果一张卡接到的大额单偏多，成功率自然更低，不能一律按 15% 卡。当天平均金额越高，要求的成功率门槛越低。按平均金额（卢比）折算：
  • 平均金额 ≤ 200：门槛 15%；
  • 200 ~ 1500：门槛从 15% 线性降到 9%；
  • 1500 ~ 3000：门槛从 9% 线性降到 6%；
  • 大于 3000：门槛 6%。
• 拦截条件（须同时满足）：
  • 总笔数 ≥ 10 笔；
  • 成功率 低于上面按平均金额算出的门槛（恰好等于门槛不拦截）。
• 怎么恢复：
  • 印度时间次日 0 点后重新计数；
  • 或当天再成功几笔，让成功率回到门槛以上。
• 用户通知：被拦截时，会给该卡用户发 Telegram 英文提醒，建议更换 UPI 绑定的主银行；每张卡每天最多提醒一次。

边界示例（门槛随平均金额变化）：

规则特例：大额代收（≥ ₹8000）

当单笔代收金额 ≥ ₹8000（且已通过余额初筛、卡处于认证免检期内）时，为减少大额外流到外部下游，系统会临时豁免以下统计规则，允许该卡参与派单：

大额代收失败不计入（避免误伤卡健康度）：

• 卡风险连续失败次数（failed_count）：大额代收终态失败不累加，不因此进入风险态
• 连续失败冷却统计（规则 ④ / 试探期）：大额失败单不参与 recentFailureCount 统计，避免误拦后续小额单
• 当天低成功率统计（规则 ⑥）：大额终态失败不计入总笔数与金额合计，避免拉低成功率导致小额单被误拦
• 大额代收成功仍正常计入规则 ⑥ 并清零风险计数；冷却仍以「最近一次成功」为分界

仍生效的限制（大额也不例外）：

• 认证免检期、同钱包同金额 10 分钟互斥
• 余额冻结、同金额 Redis 占位

管理后台「可代收」统计不套用本特例，仍按常规 6 条规则展示。

5. 谁优先接单？（加权随机抽签）

过滤完之后，候选名单往往还剩很多张。这一步决定「先试哪张」——不是完全随机，也不是简单谁成交量大谁第一，而是综合「最近表现 + 新人照顾」来抽签排序。

5.1 得分怎么算

压缩效果示例：

举例：A 卡近两天收款 20 笔、今天失败 2 笔，基础得分 19，压缩后约 5.87；B 卡近两天 0 笔、今天没失败，基础得分 1。A 仍更容易排前面，但不会把 B 完全封死。

新人加分阶梯（按累计成功代付笔数）：

新人逻辑：代付越少 → 越需要多接代收攒余额 → 更快完成首笔出款。同一App账户名下的多张卡共享同一份新人加分，避免开多卡刷加成。

绑卡数增长曲线（五人同池、单卡 raw=10）：

绑卡数越多概率越高，50 卡约为 1 卡的 4.1 倍（旧策略约 50 倍）。曲线按锚点 log 插值，中间绑卡数平滑过渡。

5.2 抽签怎么理解

可以想成 加权抽奖：

• 得分越高的卡，「抽奖券」越多，越可能排在前面先试。
• 一次性排出全部卡的尝试顺序（抽过的不再重复）。
• 压缩算法让头部卡有优势，但不会通吃全部机会。

5.3 当天失败为什么要扣分？

如果只看昨天表现，今天已经连续失败的卡仍可能被优先派单，成功率会继续变差。把当天失败从得分里扣掉，能让「今天状态差的卡」快速靠后。

5.4 为什么要照顾新App用户？

App用户要完成「接代收 → 攒余额 → 申请代付出款」才算走通流程。新人近两天活跃度往往是 0，按旧规则很难排到前面，首笔出款慢、体验差。

加上新人加分后，从未出款的用户会明显靠前；每完成一笔代付，加分逐步减少；代付满 6 笔后回归正常竞争。

6. 认证免检期与按卡自扫描

6.1 选卡侧（不再调爬虫）

加权排序后，系统只从处于「认证免检期」内的卡里取第一张，尝试同金额占位与余额冻结；全程不调爬虫。

6.2 后台按卡自扫描

每张已认证卡有各自的下一次扫描时刻。活跃卡默认 20 分钟免检/扫描间隔（PhonePe 按 token 过期时间动态调度，约 10–40 分钟）；写入 nextDue 时在 [interval, 2×interval) 窗口内按分钟桶查 ZSET 负载，选最空时段（并列时用 userCardId 打破平局），避免到期扎堆：

不活跃卡降频（1 天 1 次）：为降低爬虫压力，满足以下任一条件的卡，扫描与免检间隔改为 1 天：

绑卡保护窗：绑卡或重认证后 5 天内，即使历史子单很久以前，也不会仅因「历史久无子单」而降频，给新认证卡保留常规扫描节奏。

恢复常规频率：不活跃卡一旦重新接到代收单，系统立即把扫描间隔恢复为 20 分钟（PhonePe 恢复动态调度）。

• 扫描通过 → 写入免检期（TTL 与 nextDue 对齐），并自适应调度下一轮扫描。
• 确认失效 → 降级为未认证、清免检期、通知用户。
• 瞬时异常（网络抖动、爬虫繁忙等） → 约 2 分钟后重试，不立刻降级。
• 绑卡/重认证成功 → 立即写入免检期并入队扫描。
• 仍在免检期内被 tick 扫到 → 仅重排 nextDue，不延长 TTL。

每分钟 tick 从队列取出已到期的卡，每轮最多处理 80 张、4 路并发调 crawler，把爬虫压力均匀摊开。

查账成功也算「卡在线」（与自扫描共用节奏）

每当系统实时查账（HIS 爬虫）成功拉到该卡的钱包流水（订单匹配、定时账单同步等），即说明这张卡此刻在线，系统会把它当作一次自扫描通过：续期免检期并把下一次自扫描往后顺延。这样活跃卡（不断有订单在查账）就不必再额外跑一遍验卡，减少对钱包的请求。

• 续期同样从当前时刻往后顺延（不是固定第 20 分钟节拍）；例如第 10 分钟查账成功，下一次验卡约在第 30–50 分钟。
• 只有真的调用了钱包实时查账并成功才算；命中「用户账单总表」直接出结果、关单后只查总表等没真正访问钱包的情况不算在线证明。
• PhonePe 例外：查账不会主动给 token 续期，为避免「一直靠查账续期、却始终不刷新 token」，PhonePe 一旦进入 token 刷新窗口，就不再用查账延长免检，而是由后台自扫描在该窗口内主动刷新 token。

6.3 上线预热

新版本发版前，需运行 profile_valid_warmup.py（见服务端仓库脚本）对全部已认证卡写入初始免检期与扫描队列，避免切换瞬间 LOCAL 无可用卡。

7. 选中之后做了什么？

选中 = 同金额占位成功 + 余额冻结成功（选卡时完成，不调爬虫）：

• 冻结余额：避免同一笔钱被多单重复占用。
• 生成 UPI 收款码：返回给商户/用户付款。
• 后续付款、提交 UTR、爬虫对账、补单、超时关单等，由其它流程继续处理。

8. 常见场景速查

9. 关键参数一览（运营可读版）

所有时间窗口均按印度时间（UTC+5:30）计算。

10. 如何用「订单日志」排查创单失败

平台管理员可在管理后台的「订单管理 → 订单日志」按发单方、商户订单号、订单类型、接单方、创建结果和印度时间范围查询。

排查 LOCAL 代收时，先看详情顶部的首要失败阶段，再展开时间线：

1. 请求校验：确认商户状态、渠道开关、金额规则、认证令牌或签名是否通过。
2. 路由接单：按实际尝试顺序查看每个接单方的耗时、成功或失败摘要；只有前一个失败后才会继续尝试下一个。
3. LOCAL 选卡：先看初始有效卡数，再逐条查看最低接单门槛、认证免检期、连续失败冷却、日成功上限、进行中容量、活单硬上限、同金额互斥、低成功率和卡 ID 去重分别过滤了多少张卡。
4. 最终候选与命中：查看最终候选卡数、同金额占位失败数、余额冻结争抢失败数，以及最终用户 ID / 卡 ID。
5. 订单落库：确认主单、LOCAL 子单和冻结记录是否全部创建成功。

日志中的 UPI、银行卡号等收款信息会脱敏展示；日志只覆盖“创建成功/创建失败”，不包含后续到账匹配、爬虫、取消和商户回调。

11. 设计意图回顾

1. 保护单卡日承载：默认 30 笔/天上限（可按卡调整），避免单卡过载、被风控盯上。
2. 保护单卡瞬时承载：活单硬上限 4 笔，降低误匹配和失败堆积。
3. 保护账户健康：连续失败立刻冷却，让卡先「喘口气」。
4. 保护试探期：冷却刚结束时一次只放 1 笔，避免并行试探全失败。
5. 保护到账匹配：同一钱包账号同金额 10 分钟互斥（含其下所有 UPI），减少对错账。
6. 保护大盘质量：接够 10 笔仍低于「按平均金额浮动门槛（6%～15%）」成功率的卡暂停派单；大额单偏多的卡用更低门槛，避免被一刀切误伤。
7. 保留公平性：冷门卡仍有抽签机会；压缩算法避免一家通吃。
8. 保留快速反应：当天失败立刻扣分。
9. 降低创单延迟：选卡只读 Redis，不调爬虫，商户侧响应更快。
10. 降低爬虫峰值：按卡分散自扫描，替代全局批量扫描。
11. 照顾新人：代付少的用户优先接代收，加快首笔出款。
12. 大额优先留 LOCAL：≥₹8000 豁免部分统计规则（含 paying/audit 并发硬上限），减少大额外流。
13. 平衡多卡用户：绑卡数增长曲线锚点校准（五人同池 8/14/21/24/33%），既抑制 50 倍碾压，也保留合理多卡优势。
14. 接受可控滞后：免检窗口内 token 掉线最多滞后一个扫描周期才降级，换取性能与负载均衡。