核心 KPI 最新月
5 站合计：5 站当月销售总和 + 环比上月。各站点 tile：当月销售额（取「整体经营 sheet」营收，缺失时回退站长月报，不回退 ERP 收款），盈利金额，盈利率（盈利 ÷ 销售），环比上月销售增速。标了「站长月报」角标的月份表示整体经营 sheet 还没填、用的是二级来源，填完重跑即自动覆盖。
5 站合计趋势 总销售额 + 总盈利
5 个站销售额与盈利的合计（数据源同 KPI：优先「整体经营 sheet」营收，缺失回退站长月报；不拿 ERP 收款兜底——那是资金到账不是销售真值，当月半个月的流水会冒充整月。用了站长月报兜底的月份，上方 KPI 卡会标「站长月报」角标）。线 = 总销售额（左轴 USD），柱 = 总盈利（右轴 RMB），
黄虚线 = 发货单量（第三轴 · 单，2022-02 起，点图例可开关）。
发货量和销售额一起看，能分出「卖得更多」还是「卖得更贵」。
同期累计对比 · 各年
全渠道发货订单量 ERP 实际发货订单数 · 2022-02 起
五个站实际发出去的订单笔数（平台订单表里有发货日期的单，按付款月归月，和上面销售额同基准）。
跟销售额那几张图是两回事：这里数的是单量不是钱。
订单数 ≠ 包裹数——一单可能拆几个包裹寄，易仓账单上的件数会比这个大。
从 2022 年 2 月起算：再往前 ERP 没录全（2021 年 Show.Z 做了 $694 万却只有 9,313 单，用销售额反推的客单价高到 $745，正常是 ~$85），画上去就是一条假曲线。
最新一个月是没走完的部分月，柱子矮属正常；另外刚付款的单还没走到"已完成"，
所以最近月份的数还会往上长（hover 看完成率）。
同期累计对比 · 各年
5 站销售 + 盈利历史 每站一张大图，线 = 销售（左轴 USD），柱 = 盈利（右轴 USD）
每站一张独立图，从该站「整体经营 sheet」最早记录月开始。线：销售额历史（左 Y 轴 USD）。柱：盈利金额（右 Y 轴 USD）。三条线源对比可勾选切换：YYS 营收（你在「整体经营 sheet」维护的真值）/ 站长月报（站长每月填的 checklist）/ ERP 收款（PayPal 直接拉，原始流水）。右上 badge 显示当月「站长 vs ERP」差距，>15% 灰、>30% 红/绿。
5 站盈利率横向对比 同一轴看 5 站
盈利率 = 盈利 ÷ 销售额 × 100%。把 5 个站放到同一图同一轴，方便看哪个站赚钱率高、哪个站在亏（线掉到 0% 以下）。例如 GK 长期 20-30%（高毛利定制），CB 多月在 0-5% 甚至亏损，77 维持 15-20%。数据源优先取「整体经营 sheet」营收 tab 的"平均盈利率"列；缺失时回退站长月报。
盈利率趋势（%）
PayPal 资金到账
仅 PayPal 入账流水，不等于销售真值
⚠️ 这不是销售对账线。是 PayPal 直接到账的钱，按收款时间统计，含跨站借收（GKLoot 历史借用 ShowZ paypal@showzstore.com）、订阅延迟收款等。和 ERP 后台「已确认订单」口径不一致。仅作资金流监控参考。
正经销售/盈利真值请看上面「5 站销售 + 盈利历史」（YYS 营收 + 站长月报）。
正经销售/盈利真值请看上面「5 站销售 + 盈利历史」（YYS 营收 + 站长月报）。
各站用的 PayPal 收款账户 期间 / 余额 / 额度使用从流水实测（使用是估算）；月收款额度抄自发给 William 的分配方案和他的回执
点任意一行看这个号的来龙去脉
5 站 PayPal 月度入账（USD）
Adyen 资金到账
2026-06 起的新卡通道，和上面的 PayPal 是两条腿
Adyen 是 2026-06-01 才上线的信用卡收款通道（ShowZ 先跑，GundamIt 260721 接入，GKLoot 260723 起有零星单）。
口径 = 成功授权（AUTHORISATION success=1），按交易时间统计，外币按固定汇率折 USD。
🔴 站点归属按订单反查，不按 merchant account 名字——三个 merchant account 没有一个是一站一号， 详见下方左栏。历史短、量还小，不要拿它和 PayPal 的月度体量直接比增长。
🔴 站点归属按订单反查，不按 merchant account 名字——三个 merchant account 没有一个是一站一号， 详见下方左栏。历史短、量还小，不要拿它和 PayPal 的月度体量直接比增长。
各站用的 Adyen 收款账户 一行 = 一个 merchant 在为一个站收款；期间/状态从流水实测
Adyen 每日入账（USD）
支付费率
PayPal vs Adyen，同一件事各收多少
两家的费率都是从流水逐笔实算的，不是抄合同：PayPal 用
口径差异要知道：PayPal 是打包价（一个百分比 + $0.30/笔）； Adyen 是 Interchange++（成本转嫁 + 固定 markup 0.55%），所以 Adyen 的费率会随卡种和买家国家浮动，PayPal 不会。 PayPal 统计自 —，Adyen 统计自 2026-06（上线即起）。
⚠️ 上面 Adyen 卡片右栏里那个「同期 PayPal 3.5x%」是另一个口径（只取 Adyen 在跑的这两个月、五站全币种）； 本板块的 PayPal 数是当年至今、仅 USD、按订单反查得到的。两个数不一样是口径不同，不是算错。
(手续费−$0.30)÷金额 反推档位，
Adyen 直接用结算报告里的 interchange / scheme fees / markup 三项。口径差异要知道：PayPal 是打包价（一个百分比 + $0.30/笔）； Adyen 是 Interchange++（成本转嫁 + 固定 markup 0.55%），所以 Adyen 的费率会随卡种和买家国家浮动，PayPal 不会。 PayPal 统计自 —，Adyen 统计自 2026-06（上线即起）。
⚠️ 上面 Adyen 卡片右栏里那个「同期 PayPal 3.5x%」是另一个口径（只取 Adyen 在跑的这两个月、五站全币种）； 本板块的 PayPal 数是当年至今、仅 USD、按订单反查得到的。两个数不一样是口径不同，不是算错。
同一种付款方式，两家各收多少
同一笔订单，两家各扣多少 上表的「有效费率」受客单价影响（固定费被稀释的程度不同），这张按统一金额折算才真能比
结论 / 该做什么 按重要性排，红边＝还没解决
Apple Pay
四个站走哪家 · 费率与分水岭全部流水实算，通道现状自动读 payment 表
260727 把 GKLoot 的 Apple Pay 从 Adyen 切到 PayPal，理由是「PayPal 费率低 0.51pp」。
260729 实测发现这个前提站不住：两家收费结构不同（PayPal 百分比低、但每笔固定费高 4 倍），
在我们的客单价上谁便宜要看金额。这个板块就是把结论固化下来，免得下次又凭印象决策。
四个站现在走谁
两家怎么收费 同一个口径：百分比 + 每笔固定费。只比「有效费率」会得出错误结论
分水岭 低于它 Adyen 便宜，高于它 PayPal 便宜。按公式算，不是写死的数
各站 Apple Pay 均单落在哪边 竖线＝分水岭；条形＝该站实际均单
同一笔订单两家各扣多少
Apple Pay 订单金额分布 决定「该走哪家」的其实是这张表，不是均值
Google Pay
260729 拍板：四站全开、全走 Adyen · 过审判据 = Adyen 流水出现 *_googlepay
四个站现在走谁
费率与分水岭 260728 GD 过审后才有实测；两侧都是流水实算，每次 refresh 自动重拟合
风控与拒付
每月 × 收单账户 · 拒付是谁拒的、盗刷有多少 · 数据源 = Adyen webhook 原始通知
每月拒付与盗刷
结论 / 该做什么
钱包通道决策的固化结论，数字全部现算
换绑 / 切通道操作手册
260729 showz 切换+当天回滚实战沉淀 · 下次动手前先读这里
Apple Pay 要能收钱，两个条件必须同时成立：① 网站根目录有那家支付商的验证文件（按支付商，全平台一份）
② 那个收款账号的后台登记了该域名（🔴 按收款账号，换号不继承）。
②是所有人都会漏的——换一次收款账号，按钮照样渲染、买家照样点、点了付不掉、前后台零报错。
四站曾因此静默坏了 26 个月（7,150 次点击打水漂，成功率 0.83%）。
场景一：换 PayPal 收款账号（最高频的坑）
| # | 动作 | 要点 |
|---|---|---|
| 1 | 查清这个站的钱现在收在哪个号 | 从 webhook 实读（`orders_paypal_webhooks_log` 抠 payee.merchant_id），别问人别翻文档——账号几个月就轮换一次，文档必过期。账号名≠归属（billing@showz.store 收的是超砖的钱） |
| 2 | 登新号，先核 Merchant ID | `businessmanage/account/aboutBusiness`，跟第 1 步查出的对上才往下走。同一主体名下有多个号，只看公司名会认错。中文界面有时不渲染 ID（值在 HTML 里，grep 得到），别点「English」——那是改账号设置 |
| 3 | 重新报备 Apple Pay 域名 | 报备页：paypal.com/uccservicing/apm/applepay → Add Domain。🔴 主域名和 www. 是两个独立域名，各报一次；🔴 站点真实域名是 showzstore.com（showz.store 只是收款邮箱域名，别填错） |
| 4 | 撞「域名已被其他人注册」→ 先证伪 | 同页填一个肯定没注册过的域名（如 zz-probe-YYMMDD.com）当对照探针：返回「找不到验证文件」≠「已被注册」→ 占用是真的（多半是自家旧号）。逐个登旧号移除再回来注册。🔴 ERP 流水不是账号全集（paypal@showzstore.com 在 ERP 里零流水）；换号排查时登出必须用 /signout（/authflow/logout 退不干净） |
| 5 | Apple Pay 报备（按账号）+ 额度（按账号）一起办 | 额度也是账户级不继承：新号默认 $1 万/月、超出扣 60 天，收款前找 William 单独配（GD settlement@ 260417 因此被冻 $16.1 万）。额度台账见上方 PayPal 账户表「月收款额度」列 |
场景二：Apple Pay 在 PayPal ↔ Adyen 之间切（260729 实战工序）
| # | 动作 | 要点 |
|---|---|---|
| 0 | 先算费率账 | 上面「Apple Pay 通道与费率」板块就是为这一步存在的：分水岭 ~$70，客单价低的站别切 PayPal。260727 gkloot 就是没算这步切错的 |
| 1 | 先关旧家的开关，再换文件 | 一个域名的 .well-known 只能放一份文件=只授权一家，文件一换旧家当场失效——不先关开关，买家看到的是坏按钮（能渲染、点了没反应），比没按钮更伤转化。开关用 payment_switch.py set <站> adyen-applepay/pp-applepay on|off --apply（先 dry-run） |
| 2 | 让希尔换文件，换完必验 md5 | 路径 /.well-known/apple-developer-merchantid-domain-association，两个域名都要。PayPal 版 md5=abe57eccf6a81f136675a54589d01312，Adyen 版=230e4592b3844d35aaac33e4344a2805。要求 200/零重定向/octet-stream。文件归档在杂事儿 260325 Adyen支付账户/260727 PayPal-ApplePay域名文件/（含回滚版）。别信「已经换好了」，curl 验过才算 |
| 3 | 新家侧报备/确认域名 | PayPal 侧见场景一第 3 步；Adyen 侧域名列表按 merchant：GET /v3/merchants/{mid}/paymentMethodSettings 看 type=applepay 的 domains。🔴 别去旧家后台删域名登记——留着回滚省一轮重验（本次 payments@showz.store 里的两条报备就是这么留的） |
| 4 | 开新家开关 | 🔴 PayPal 的 Apple Pay 开关是 PId=1.IsApplepayButton（不是 PId=70.IsUsed，脚本里也没有 70 这个开关）；Adyen 的是 PId=76.IsUsed。同站两条记录都叫 "Apple Pay"，讨论必带 PId |
| 5 | 真单验证，三样全中才算通 | ① iPhone 实测面板弹出（=域名验证生效，最快）② orders_payment_addition.PaymentMethod='applepay' 有 intent（🔴 orders 表的 PaymentMethod 记的是「点了哪个按钮」不是「用什么付的」）③ 付掉的单恢复到基准量（showz 基准 ~12 单/4 笔付掉/天）。🔴 别用 PayTime>0 算成功率（点 AP 失败改刷卡也算进去，虚高到 60%+，真值 0.83%）。GPay 当对照组：GPay 有量、AP 归零=100% 域名问题 |
回滚（260729 实测 ~20 分钟完成）
| # | 动作 | 要点 |
|---|---|---|
| 1 | 希尔把文件换回原版（验 md5） | 两个域名都换 |
| 2 | 开关切回（关新开旧） | payment_switch.py，各一条命令 |
| 3 | 🔴 最容易漏：验旧家域名验证还活着没有 | Adyen API 不返回 verificationStatus（实测 None），后台看不出来，只能真单/实测面板验。260729 实证：文件在 PayPal 版待了 ~1 小时，Adyen 验证没有失效（sz/gd/cb 三站 iPhone 实测全部付款成功）——短暂换文件不致命，但每次仍必须验 |
本手册的事实来源：skill
paypal-applepay-domain（操作规范原文）+ 杂事儿
260325 Adyen支付账户/…时间线.md 260727f/g、260729e（实战记录）。
看板这份是速查摘要，两边冲突以 skill 为准；改了 skill 记得回来同步这里。
其它常备：Ueeshop 后台地址=站点主域名+/manage/（旧 myueeshop 地址全 404）；
*.myueeshop.com 子域上的 PayPal 版文件是平台自铺的，四站都有，与我们的配置无关。
杂费明细 整体经营 sheet 杂费 tab，¥CNY
公司层面的运营杂费（不分站），来自「整体经营 sheet」的杂费 tab。按月堆叠分类显示，包含：国内货物运费 / 运杂打包费 / 包材费 / 营销宣传 / 网店 ERP 运维 / 律师费 / 网红营销 / 通勤 / 其他杂费等。鼠标 hover 看每月每项具体金额。注意：这是手填数据，最近月份可能未完整录入。
最近 12 月杂费分类堆叠
站长月报 vs YYS 营收 一致性检查 两者应一致，差异 = 录入误差
站长月报和「整体经营 sheet」YYS 营收本来都是站长每月去 ERP 后台抄的同一份数据，理论上应该完全一致。这里逐月逐站对比，差异 = 录入误差/漏填。差异 > 5% 标灰，> 15% 标红/绿。不再和 PayPal 流水对账（PayPal 不是销售真值）。
已授予 / 已接入的方式 · 待装清单
按「那个国家在我们这儿有多少单」排优先级，不是按那个方式在当地多流行
🔴 Adyen 开通 ≠ 买家能用。一个本地支付方式要真正上线，三件事缺一不可：
① Adyen 侧已开通 ② 站点开了它要求的币种 ③ Ueeshop 里有对应的支付方式行且打开。
下表把三者拆开列，缺哪一环写哪一环 —— 「还缺什么」那列就是待办。
各站接了哪些支付方式
两层各是两回事：Ueeshop 开关＝结账页摆哪些图标 / Adyen 已开通＝能不能真收到钱
🔴 两层实测对不上，且不一致本身就是信息：Ueeshop 后台关掉的方式（如 gd 的 GrabPay/Boost），
买家点进 Adyen 托管页照样能选能付——Ueeshop 开关只管第一屏图标，管不住 Adyen 页面里放什么。
表中 仍可付 标的就是这种行；收不到钱 = 图标摆着但通道没开通。
每个方式的月度销售额
Adyen 按方式细拆（成功授权）· PayPal 整体一根（到账流水）· 单位 USD
口径（方案 A）：Adyen 流水有
payment_method 字段，按方式细拆；
PayPal 流水表没有任何"买家用的什么"字段（260820 实查全部列），Apple Pay / 刷卡 / 余额全混在一起，
只能整体呈现一个通道——这是账表限制，不是没做。⚠️ 两边口径也不同：Adyen=成功授权按交易时间，
PayPal=ERP 到账流水（含跨站借收/订阅延迟，不是销售真值）。
每个方式的费率
Adyen＝流水实测（Interchange++）· PayPal＝合同价+流水回归 · 零流水的方式显示暂无数据
换 PayPal 收款账号 SOP
照着做 · 每步都写了为什么 · 出过事的地方标 🔴
什么时候用：某个站要把 PayPal 收款换到另一个账号（换主体、旧号停用、把量挪走）。
整个换绑过程前台断流约 16 分钟（260827 实测一次），但动手前的准备比操作本身重要 —— 下面第一步那几项没确认就开干，出事概率很高。
🔴 Ueeshop 后台没有「换绑」按钮。是靠把「启用」开关关掉再打开来触发重新授权的。 在页面上找不到换绑入口是正常的，别找了。
🔴 换绑那一步不能用脚本做：授权要跳到 PayPal 页面登录，脚本跑的是独立会话、没有登录态。必须人在浏览器里操作。
整个换绑过程前台断流约 16 分钟（260827 实测一次），但动手前的准备比操作本身重要 —— 下面第一步那几项没确认就开干，出事概率很高。
🔴 Ueeshop 后台没有「换绑」按钮。是靠把「启用」开关关掉再打开来触发重新授权的。 在页面上找不到换绑入口是正常的，别找了。
🔴 换绑那一步不能用脚本做：授权要跳到 PayPal 页面登录，脚本跑的是独立会话、没有登录态。必须人在浏览器里操作。
第一步 · 动手前必须确认（缺一不可）
| # | 确认什么 | 怎么做 / 为什么 |
|---|---|---|
| 1 | 新号能登进去，且 Merchant ID 是对的 | 登进去后第一件事是核 Merchant ID（Account Settings → Business information）。 🔴 只看公司名一定会认错 —— 同一家公司名下常有好几个号，名字还都以 payments@ 开头。 真事：要登 SZ 的号、登成了超砖的号，两个都叫「南京钧帆科技有限公司」，是核 ID 才拦下来的， 否则会对着错账号删域名。ID 对不上就停，别往下走。 |
| 2 | 查这个号的「实际生效额度」 | 路径：登该号 → 首页「Not available yet」金额旁的 what you can do →
右侧面板「Why your money is on hold」。里面写着
any money above $X in sales each month，那个 X 才是真生效的额度。
🔴 档案里记的额度不算数 —— 账号停用久了会被系统自动降档，客户经理设的数不变但不生效。
真事：档案记 $85 万，面板实际按 $10 万 卡，原因写着 account has been inactive。
拿不到 API，只能人工看。 额度不够就先找客户经理恢复（说辞：inactive 自动降档、属重新启用不是新申请）。
🔴 顺序不能反：额度先落实、拿到 PayPal 官方通知邮件，再换绑。 GD 的 settlement@ 就是顺序反了、按系统默认走，被冻 $16.1 万。 认账只认官方邮件（service@intl.paypal.com，按 Delivered-To 认是发给哪个号的）。 |
| 3 | 提款银行定好，和 jmj 确认 | 新号上绑的卡未必是想要的那张，绑上也不等于钱走它——还要看默认提款账户。 换号前先把「这个站的钱提到哪张卡」跟 jmj 敲定，别换完了再问。 🔴 录银行账号这一步人来做，改完让人复核「哪张多了、哪张少了」—— 真事：以为只是加一张，实际旧卡被解绑了。 |
| 4 | 抓一份改前快照 | 把 PayPal 那个编辑页的所有字段记下来（名称／启用／信用卡支付／独立信用卡／ Apple Pay／Google Pay／价格限制／手续费／附加费用／排序／图片路径，共 11–12 项）。 换绑要提交两次整表单，会把页面上所有字段一起写回，改完必须逐项对。 |
| 5 | 挑低单量时段 | 按该站的实际扣款分布挑，别抄别的站。ShowZ 实测北京时间 14–17 点最少 （每小时 11–13 笔），22–01 点最多（23–25 笔，2.2 倍）。 |
第二步 · 换绑操作（约 16 分钟，前台这期间没有 PayPal）
| # | 动作 | 说明 |
|---|---|---|
| 1 | 打开该站后台的 PayPal 编辑页 | 设置 → 支付设置 → PayPal 那行点编辑（地址是 ?m=set&a=payment&d=edit&PId=1，四个站都是 PId=1）。 页面上「账号信息 Merchant id」那行是只读的，不能改。 |
| 2 | 把「启用」开关 关掉 → 保存 | 保存后前台的 PayPal 就消失了，计时开始。 |
| 3 | 把「启用」开关 打开 → 保存 | 这一下会触发 PayPal 重新授权。 |
| 4 | 跳到 PayPal 授权页，用新账号登录并授权 | 🔴 确认登的是新号，别用浏览器里残留的旧号登录态。 不确定就先去 paypal.com/signout 退干净 （别用 /authflow/logout，那个会弹回首页、看着像退了其实没退）。 |
| 5 | 🔴 授权完成后，返回 Ueeshop 的按钮要用「新窗口打开」 | 右键选「在新标签页中打开」，或按住 Cmd/Ctrl 点。 每次换绑都是这样（张驰做过多次换绑确认），不是偶发。 🔴 点了没反应，既别当成失败、也别当成成功——这时候「启用」已经打开保存了、 前台正在收钱，而绑定可能还停在旧号。立刻回后台看「账号信息 Merchant id」变了没有， 按看到的结果决定重做还是继续。靠猜的代价是：钱在进，但不知道进了谁的号。 |
额度紧到底意味着什么（别据此做错决定）
被压住的钱不是没了，是晚 60 天到。 滚动准备金和超额留存到期会自动析出，
而析出的那笔不占用析出当月的收款额度 —— 这是 PayPal 侧的规则：
客户经理 William 260331 原话「释放出来的钱不占提款额度（额度只针对网站收款）」。
举例：月收 80 万、实际额度 10 万 → 第 1、2 月各只能动用 10 万； 第 3 月起每月 = 当月 10 万 ＋ 第 1 月析出的 70 万 = 80 万，回到原量。
⟹ 真实代价只有两条：过渡期头两个月吃紧、常态沉淀「每月超额 × 2」。
🔴 所以别说成「提款能力砍了 X%」 —— 那是把「压住」当成永久损失或逐月累积， 会让人做出错误决策，比如急着换回旧号（而旧号停收后额度可能已被调到 $1，回去更死）。
举例：月收 80 万、实际额度 10 万 → 第 1、2 月各只能动用 10 万； 第 3 月起每月 = 当月 10 万 ＋ 第 1 月析出的 70 万 = 80 万，回到原量。
⟹ 真实代价只有两条：过渡期头两个月吃紧、常态沉淀「每月超额 × 2」。
🔴 所以别说成「提款能力砍了 X%」 —— 那是把「压住」当成永久损失或逐月累积， 会让人做出错误决策，比如急着换回旧号（而旧号停收后额度可能已被调到 $1，回去更死）。
第三步 · 换完立刻验证（后台显示成功不算数）
| # | 验什么 | 怎么算过 |
|---|---|---|
| 1 | 后台的 Merchant id 变了 | 回到那个编辑页，看「账号信息」那行是不是新号的 ID。 |
| 2 | 其它字段一个都没被改掉 | 和第一步存的快照逐项对，要求零打回。 🔴 Apple Pay / Google Pay 那两个开关有静默丢的前科：当场看着是对的，过几分钟才现形 —— 隔几分钟再查一遍。 |
| 3 | 新号真的收到钱了 | 这才是唯一算数的证据。看该站的 PayPal 回调记录，新号要同时出现 「下单」「完成」「实际扣款」三段，且收款邮箱是新号。 只有前两段 = 买家点了但钱没进来。 |
| 4 | 🔴 别拿数据库/看板判断换绑成功没 | 同步库比后台慢约 20 分钟。真事：换绑已经成功了，查库读出来是 「没换成功、而且 PayPal 是关着的」，和真出事长得一模一样，差点去做多余的补救。 判当前状态一律看后台本身。 |
第四步 · 收尾
| # | 做什么 | 说明 |
|---|---|---|
| 1 | 老号那边把这个站的域名解绑 | 登老号 → Account Settings → Payment methods → Manage Apple Pay （paypal.com/uccservicing/apm/applepay），把该站的 主域名和 www. 两条都移除。 为什么要摘：域名登记是按收款账号走的，老号占着，新号将来要开 Apple Pay 会撞 「域名已被其他人注册」。 |
| 2 | 🔴 老号不能停用、不能把钱提空 | 预售尾款还会从老号扣——实测尾巴长达 45 天（新单 04-09 当天就停，扣款一直持续到 05-24）。 历史订单的退款和拒付也只能从老号出，提空了再来退款会很麻烦。 🔴 额度也别急着转走，而且「回滚回老号」不是免费的退路—— William 260331 说过「老账号停收后风控会把额度调到 $1」， 老号一停收，它的额度可能已经没了。至少观察到第 45 天再谈清尾。 |
| 3 | 记台账 + 更新看板 | 台账写：新旧 Merchant ID、中断了多久、验证结果、实测到的额度和原因。 看板改这个号的角色（谁是主力、谁在清尾）。 |
踩过的坑（每条都真出过事）
| 坑 | 真相 |
|---|---|
| 在后台找「换绑」按钮 | 没有这个按钮。是关掉再打开「启用」开关。 |
| 授权完点「返回」没反应，以为失败了 | 那个按钮要新窗口打开，直接点无效。别重来。 |
| 同一家公司名下认错号 | 名字都以 payments@ 开头。只认 Merchant ID。 |
| 拿档案里的额度当真 | 停用会被自动降档。每次都要登后台看面板，拿不到 API。 |
| 看数据库判断换绑成功没 | 同步慢 20 分钟，会读出相反的结论。看后台。 |
| 面板说「银行卡还需要验证」 | 那是通用建议文案，不是实际状态。 卡的真实状态只认卡片详情页——点进去如果只有「改昵称」「移除银行」，就是不用验。 |
| 人和脚本同时改这张表单 | 后保存的会把整张表单的旧值写回， 支付方式可能被静默关掉。同一时刻只能一个人动。 |
💡 Apple Pay 域名那套单独有一份（为什么换号会让 Apple Pay 静默失效、验证文件怎么放、
和 Adyen 冲突怎么办）→ 见「支付通道」页最下面的「换绑 / 切通道操作手册」。
审核日志
PayPal 和 Adyen 各一条时间线 · 最新的在最上面
收两类事：①别人审我们（PP 的年审／大额审核／账户级审查／TRO 处置，AD 的核保 KYC／支付方式开通／尽调）
②我们自己做的风控动作（上规则、查误伤、定不定强制 3DS）。
不收通道开关、退款个案、双扣事故这类运维事 —— 那些在时间线档案里。
🔴 这一页是档案事实，不是数据库查出来的：数据手写在前端常量里，只有我们又跟对方走完一轮才会变。 看板上别的数字每次刷新都会动，这一页不会 —— 它旧了不等于对，等于还没人来更新。
🔴 两家的「审核」根本不是一回事：PP 那边基本是它主动来审我们，结果直接落到准备金比例和收款额度上； AD 这边多数是我们去申请、对方来审（开新商户号、开新支付方式），卡住了只是某个通道开不成。 看的时候别把两栏的严重程度并列。
🔴 这一页是映射，不是原件：每条点开后底下标了它在档案里的段落， 完整往返、原始材料、我方测算和待办都在档案里 —— 看板只映射核心结论，两边不一致时以档案为准。
🔴 这一页是档案事实，不是数据库查出来的：数据手写在前端常量里，只有我们又跟对方走完一轮才会变。 看板上别的数字每次刷新都会动，这一页不会 —— 它旧了不等于对，等于还没人来更新。
🔴 两家的「审核」根本不是一回事：PP 那边基本是它主动来审我们，结果直接落到准备金比例和收款额度上； AD 这边多数是我们去申请、对方来审（开新商户号、开新支付方式），卡住了只是某个通道开不成。 看的时候别把两栏的严重程度并列。
🔴 这一页是映射，不是原件：每条点开后底下标了它在档案里的段落， 完整往返、原始材料、我方测算和待办都在档案里 —— 看板只映射核心结论，两边不一致时以档案为准。