各站点盈利看板

5 站合计：5 站当月销售总和 + 环比上月。各站点 tile：当月销售额（取「整体经营 sheet」营收，缺失时回退站长月报，不回退 ERP 收款），盈利金额，盈利率（盈利 ÷ 销售），环比上月销售增速。标了「站长月报」角标的月份表示整体经营 sheet 还没填、用的是二级来源，填完重跑即自动覆盖。

5 个站销售额与盈利的合计（数据源同 KPI：优先「整体经营 sheet」营收，缺失回退站长月报；不拿 ERP 收款兜底——那是资金到账不是销售真值，当月半个月的流水会冒充整月。用了站长月报兜底的月份，上方 KPI 卡会标「站长月报」角标）。线 = 总销售额（左轴 USD），柱 = 总盈利（右轴 RMB）， 黄虚线 = 发货单量（第三轴 · 单，2022-02 起，点图例可开关）。 发货量和销售额一起看，能分出「卖得更多」还是「卖得更贵」。

五个站实际发出去的订单笔数（平台订单表里有发货日期的单，按付款月归月，和上面销售额同基准）。 跟销售额那几张图是两回事：这里数的是单量不是钱。 订单数 ≠ 包裹数——一单可能拆几个包裹寄，易仓账单上的件数会比这个大。 从 2022 年 2 月起算：再往前 ERP 没录全（2021 年 Show.Z 做了 $694 万却只有 9,313 单，用销售额反推的客单价高到 $745，正常是 ~$85），画上去就是一条假曲线。 最新一个月是没走完的部分月，柱子矮属正常；另外刚付款的单还没走到"已完成"， 所以最近月份的数还会往上长（hover 看完成率）。

每站一张独立图，从该站「整体经营 sheet」最早记录月开始。线：销售额历史（左 Y 轴 USD）。柱：盈利金额（右 Y 轴 USD）。三条线源对比可勾选切换：YYS 营收（你在「整体经营 sheet」维护的真值）/ 站长月报（站长每月填的 checklist）/ ERP 收款（PayPal 直接拉，原始流水）。右上 badge 显示当月「站长 vs ERP」差距，>15% 灰、>30% 红/绿。

盈利率 = 盈利 ÷ 销售额 × 100%。把 5 个站放到同一图同一轴，方便看哪个站赚钱率高、哪个站在亏（线掉到 0% 以下）。例如 GK 长期 20-30%（高毛利定制），CB 多月在 0-5% 甚至亏损，77 维持 15-20%。数据源优先取「整体经营 sheet」营收 tab 的"平均盈利率"列；缺失时回退站长月报。

⚠️ 这不是销售对账线。是 PayPal 直接到账的钱，按收款时间统计，含跨站借收（GKLoot 历史借用 ShowZ paypal@showzstore.com）、订阅延迟收款等。和 ERP 后台「已确认订单」口径不一致。仅作资金流监控参考。
正经销售/盈利真值请看上面「5 站销售 + 盈利历史」（YYS 营收 + 站长月报）。

Adyen 是 2026-06-01 才上线的信用卡收款通道（ShowZ 先跑，GundamIt 260721 接入，GKLoot 260723 起有零星单）。 口径 = 成功授权（AUTHORISATION success=1），按交易时间统计，外币按固定汇率折 USD。
🔴 站点归属按订单反查，不按 merchant account 名字——三个 merchant account 没有一个是一站一号， 详见下方左栏。历史短、量还小，不要拿它和 PayPal 的月度体量直接比增长。

两家的费率都是从流水逐笔实算的，不是抄合同：PayPal 用 (手续费−$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、按订单反查得到的。两个数不一样是口径不同，不是算错。

260727 把 GKLoot 的 Apple Pay 从 Adyen 切到 PayPal，理由是「PayPal 费率低 0.51pp」。 260729 实测发现这个前提站不住：两家收费结构不同（PayPal 百分比低、但每笔固定费高 4 倍）， 在我们的客单价上谁便宜要看金额。这个板块就是把结论固化下来，免得下次又凭印象决策。

Apple Pay 要能收钱，两个条件必须同时成立：① 网站根目录有那家支付商的验证文件（按支付商，全平台一份） ② 那个收款账号的后台登记了该域名（🔴 按收款账号，换号不继承）。 ②是所有人都会漏的——换一次收款账号，按钮照样渲染、买家照样点、点了付不掉、前后台零报错。 四站曾因此静默坏了 26 个月（7,150 次点击打水漂，成功率 0.83%）。

公司层面的运营杂费（不分站），来自「整体经营 sheet」的杂费 tab。按月堆叠分类显示，包含：国内货物运费 / 运杂打包费 / 包材费 / 营销宣传 / 网店 ERP 运维 / 律师费 / 网红营销 / 通勤 / 其他杂费等。鼠标 hover 看每月每项具体金额。注意：这是手填数据，最近月份可能未完整录入。

站长月报和「整体经营 sheet」YYS 营收本来都是站长每月去 ERP 后台抄的同一份数据，理论上应该完全一致。这里逐月逐站对比，差异 = 录入误差/漏填。差异 > 5% 标灰，> 15% 标红/绿。不再和 PayPal 流水对账（PayPal 不是销售真值）。

🔴 Adyen 开通 ≠ 买家能用。一个本地支付方式要真正上线，三件事缺一不可： ① Adyen 侧已开通 ② 站点开了它要求的币种 ③ Ueeshop 里有对应的支付方式行且打开。 下表把三者拆开列，缺哪一环写哪一环 —— 「还缺什么」那列就是待办。

🔴 两层实测对不上，且不一致本身就是信息：Ueeshop 后台关掉的方式（如 gd 的 GrabPay/Boost）， 买家点进 Adyen 托管页照样能选能付——Ueeshop 开关只管第一屏图标，管不住 Adyen 页面里放什么。 表中 仍可付 标的就是这种行；收不到钱 = 图标摆着但通道没开通。

口径（方案 A）：Adyen 流水有 payment_method 字段，按方式细拆； PayPal 流水表没有任何"买家用的什么"字段（260820 实查全部列），Apple Pay / 刷卡 / 余额全混在一起， 只能整体呈现一个通道——这是账表限制，不是没做。⚠️ 两边口径也不同：Adyen=成功授权按交易时间， PayPal=ERP 到账流水（含跨站借收/订阅延迟，不是销售真值）。

两笔钱合起来看：手续费是收单机构收的（收美元也要付），换汇价差是把外币变成美元时被吃掉的。 选走哪个通道看「综合成本」列；定挂牌汇率只看「换汇价差」列 —— 手续费不是收外币的额外成本，挂牌加成只需覆盖换汇差（下面第二张表）。
🔴 「笔数」两种含义不可比，已分开：有流水的通道是实际成交笔数； 零流水的通道给的是该国订单量（潜在量，那个国家有多少单，不是这个通道做成了多少单）。 混在一列排序会让人以为 GCash 比 iDEAL 火。
🔴 只收单一币种的通道，买家不把币种切过去就根本看不见它（收货地址还得对上那个国家）—— 所以「收款币种」那列不只是信息，它是这个方式能不能被用上的前提。多币种那几行列的是 整个 Adyen 账户实际有流水的币种（含 iDEAL 的 EUR、P24 的 PLN），不是这三行各自的收款币种， 也不是「站点开了哪些」—— 开了没人用的币种列上去，会让人以为它在收钱。
两家收单机构谁便宜（PayPal vs Adyen）是另一个问题，看「支付通道」子页的支付费率板块。

这里是换汇价差，跟手续费是两笔钱（每个通道的手续费见本页上面那张表； PayPal vs Adyen 两家横向比见「支付通道」子页的支付费率板块）。 「保本加成」= 挂牌汇率要比市场价高多少，收外币才跟直接收美元一样赚。

钱从 Adyen 到我们账上，只有三条路
① 本地清算 —— USD / EUR / GBP 走这条，原币到账。 美元走 ACH（Adyen 的美国 payout 表单只要账号 + ACH routing，不要 SWIFT/Fedwire）； 欧元走 SEPA（那个户只支持 SEPA/TARGET2）； 英镑那个户 FPS / CHAPS / BACS / SWIFT 都能收，具体走哪条我们判不出，别当成已知。 按笔费用几乎为零 —— ⚠️ 例外见下表 GBP 行：Airwallex 收 GBP 进账另收 0.3% （260606 记的，260718 jmj 又说不收，两说打架、至今未证实）。
② 换汇成美元 —— 其余币种全走这条，被吃合同的 FX Management Fee： 0.90%（15 币种名单内）或 1.80%（名单外，含 MYR）。
③ SWIFT 原币电汇 —— 只有 JPY 那个户是这条路（且只能走这条），而我们主动没绑它。
🔴 关键事实：我们的收款账户里有三个根本收不了 SWIFT （一手源：杂事儿/260325 Adyen支付账户/260723 钧帆Airwallex收款账户证明/）—— AUD 仅 NPP / Osko / Direct Entry、CAD 仅 EFT / Interac e-Transfer、 EUR 仅 SEPA / TARGET2（EUR 那个尤其坑：显示了 SWIFT 代码但实际不支持）。 USD / GBP / JPY 三个可以收 SWIFT。
⚠️ 四种「换汇」的原因完全不同，别混为一谈：
· AUD / CAD —— 🔴 两端对不上，这条路是断的，不是「太贵」： Adyen 这头对 AUD/CAD 不支持本地打款、只能发 SWIFT（Adyen 香港主体支持币种表，260903 核过）； 我们这头的 Airwallex AUD/CAD 账户只能收本地清算、收不了 SWIFT（账户证明一手源）。 一头只能发 SWIFT、一头只能收本地 ⟹ 钱过不来，Adyen 只好换成 USD。 年成本约 $1,900（敞口按 260829 的 AUD 260 笔 / CAD 477 笔算，现在 routed 已涨到 307/606，这个数偏旧）。
⚠️ 所以「问 Lynn 要个便宜的 SWIFT 报价」救不了它 —— 260903 挂的那条判据 「除非 SWIFT 费低于每笔 $10 才追」前提就不成立，钱汇过来账户也收不了。 真要救得先换一个能收 SWIFT 的 AUD/CAD 账户，那是开新户的事，不是找 Airwallex 要个号码。
· JPY —— 我们有日元账户但主动没绑（260723 张驰拍板）。日元没有本地清算通道， 那个户开在香港、只能走 SWIFT，中间行每笔约 $20 ⟹ T+3 日结一月约 22 笔，固定费吃不消。 当时算的盈亏平衡是单次提款 > $5,000。年换汇成本才约 $100，折腾不回来。 ⚠️ 这个 $5,000 是按日元这个户的 $20/笔推的，只对 JPY 成立，别拿去套别的币种。
⚠️ 另：提款频率只能按 merchant account 整体设，没有「按币种」这一层 （260723 CA 后台走完 Balances → Payout schedule 实测；🔴 但 260829 另有一次自查说 该设置在 company 层，两条档案打架、尚未复核）—— 为某个小币种拉长周期会连累美元主力回款。
· SGD —— 🟡 它在香港主体的原币结算名单内（Lynn 260903），跟下面两个不是一回事： 不是没路，是路开着我们还没走 —— 差的是 Airwallex 能不能开 SGD 收款户（jmj 未回）+ 后台加个 payout account。PayNow 260905 刚开张，这件事从「反正零流水」变成了有实际收益。
· PLN / MYR —— 香港主体压根不支持这两个币种原币结算（Lynn 260905）。 不是我们没绑账户，是这条路不存在。

方案已定，待配置 本次确定的是下方 R3 人工核验规则；R1、R2 仍待验证。
新增规则重点：首次下单至本次付款未满 6 个月，并且收货国家为菲律宾或哥伦比亚。 首单已满 6 个月的老客默认不进入这些新增规则，不把客户加入全局 Trust 名单。 已有银行明确怀疑欺诈、已确认团伙关联等强信号，仍按原规则处理。
本次仅更新方案，Adyen 与 ERP 均未配置这套新增规则。下方现有规则表保留上次核验记录，不能把本次看板更新当作支付风控已经上线。

🔴 Adyen 的规则分两类，行为完全不一样，这是看这一页的前提：
① 拦截类（Block） —— 建好就生效，直接拒绝交易，买家点付款直接失败。不需要挂任何东西。
② 验证类（Check for 3DS） —— 建好只是判断「这笔该不该让买家验证」，没有执行权； 必须再去 Dynamic 3D Secure 页面挂一条才会真正请求认证，是否弹挑战由发卡行决定。
⟹ 一条验证类规则在 Risk profile 里显示 Enabled，不代表它在干活。 比方说：装了摄像头 ≠ 接了警铃。

3DS 认证与挑战验证要分开看：认证可能走挑战流程，也可能无感完成。

什么是挑战 —— 付款时银行弹一个页面出来，要买家当场证明自己是本人：输短信验证码、 打开银行 App 点确认、或者刷脸。

给挑战（ALWAYS request challenge）—— 买家要多做一步。 通过持卡人交互提高冒用难度，但不能保证挡住所有盗刷。真客户也可能多做一步，影响付款转化。

不给挑战（NEVER request challenge）—— 我们把这笔的信息发给发卡行（卡号、金额、 收货地址、设备、IP、这张卡以前在这台设备买过没有），银行拿去跟它自己知道的比对，然后放行。 银行可以无感认证，也可以要求挑战或拒绝，不是一定付款成功。

无感认证也能判断风险；责任转移要看该笔实际认证结果、liabilityShift 和适用条件。 不能仅凭“发起过 3DS”就认定以后一定由银行赔付。

⚠️ 更正一个容易想错的地方：「不给挑战」只是我们的偏好，不是命令。 发卡行拿到信息后如果自己觉得可疑，它照样可以要求挑战，也可能直接拒。最终拍板的是银行。

近 30 天 ShowZStoreECOM：授权成功 87.63% · 被风控拦 2.51% · 被发卡行拒 9.86% · 拒付 0.24% · 欺诈举报 1.63%。
20 条里真正拦到人的只有 2 条，其余要么关着、要么 30 天零命中。没有一条是我们自建的，全是 Adyen 内置。

这里回答两个不同的问题，别混：
① 钱压在哪儿 —— PayPal 按账号冻钱，一笔保证金锁在一个具体的收款号里，退也只能从那个号退。
② 算谁头上 —— 内部成本归属，按项目（网站）分摊。两者不要求一一对应： 比如老轮的 $8 万压在超砖的收款号上，但按分摊超砖只承担 $4,300。

什么时候用：某个站要把 PayPal 收款换到另一个账号（换主体、旧号停用、把量挪走）。
整个换绑过程前台断流约 16 分钟（260827 实测一次），但动手前的准备比操作本身重要 —— 下面第一步那几项没确认就开干，出事概率很高。
🔴 Ueeshop 后台没有「换绑」按钮。是靠把「启用」开关关掉再打开来触发重新授权的。 在页面上找不到换绑入口是正常的，别找了。
🔴 换绑那一步不能用脚本做：授权要跳到 PayPal 页面登录，脚本跑的是独立会话、没有登录态。必须人在浏览器里操作。

💡 Apple Pay 域名那套单独有一份（为什么换号会让 Apple Pay 静默失效、验证文件怎么放、 和 Adyen 冲突怎么办）→ 见「支付通道」页最下面的「换绑 / 切通道操作手册」。

收两类事：①别人审我们（PP 的年审／大额审核／账户级审查／TRO 处置，AD 的核保 KYC／支付方式开通／尽调） ②我们自己做的风控动作（上规则、查误伤、定不定强制 3DS）。 不收通道开关、退款个案、双扣事故这类运维事 —— 那些在时间线档案里。
🔴 这一页是档案事实，不是数据库查出来的：数据手写在前端常量里，只有我们又跟对方走完一轮才会变。 看板上别的数字每次刷新都会动，这一页不会 —— 它旧了不等于对，等于还没人来更新。
🔴 两家的「审核」根本不是一回事：PP 那边基本是它主动来审我们，结果直接落到准备金比例和收款额度上； AD 这边多数是我们去申请、对方来审（开新商户号、开新支付方式），卡住了只是某个通道开不成。 看的时候别把两栏的严重程度并列。
🔴 这一页是映射，不是原件：每条点开后底下标了它在档案里的段落， 完整往返、原始材料、我方测算和待办都在档案里 —— 看板只映射核心结论，两边不一致时以档案为准。