核心 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 到账流水(含跨站借收/订阅延迟,不是销售真值)。
每个通道到底吃掉多少
手续费 + 换汇价差 = 综合成本 · 收款币种决定换不换汇 · 按成交笔数排,零流水的沉底
两笔钱合起来看:手续费是收单机构收的(收美元也要付),换汇价差是把外币变成美元时被吃掉的。
选走哪个通道看「综合成本」列;定挂牌汇率只看「换汇价差」列 ——
手续费不是收外币的额外成本,挂牌加成只需覆盖换汇差(下面第二张表)。
🔴 「笔数」两种含义不可比,已分开:有流水的通道是实际成交笔数; 零流水的通道给的是该国订单量(潜在量,那个国家有多少单,不是这个通道做成了多少单)。 混在一列排序会让人以为 GCash 比 iDEAL 火。
🔴 只收单一币种的通道,买家不把币种切过去就根本看不见它(收货地址还得对上那个国家)—— 所以「收款币种」那列不只是信息,它是这个方式能不能被用上的前提。多币种那几行列的是 整个 Adyen 账户实际有流水的币种(含 iDEAL 的 EUR、P24 的 PLN),不是这三行各自的收款币种, 也不是「站点开了哪些」—— 开了没人用的币种列上去,会让人以为它在收钱。
两家收单机构谁便宜(PayPal vs Adyen)是另一个问题,看「支付通道」子页的支付费率板块。
🔴 「笔数」两种含义不可比,已分开:有流水的通道是实际成交笔数; 零流水的通道给的是该国订单量(潜在量,那个国家有多少单,不是这个通道做成了多少单)。 混在一列排序会让人以为 GCash 比 iDEAL 火。
🔴 只收单一币种的通道,买家不把币种切过去就根本看不见它(收货地址还得对上那个国家)—— 所以「收款币种」那列不只是信息,它是这个方式能不能被用上的前提。多币种那几行列的是 整个 Adyen 账户实际有流水的币种(含 iDEAL 的 EUR、P24 的 PLN),不是这三行各自的收款币种, 也不是「站点开了哪些」—— 开了没人用的币种列上去,会让人以为它在收钱。
两家收单机构谁便宜(PayPal vs Adyen)是另一个问题,看「支付通道」子页的支付费率板块。
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 (一手源:
⚠️ 四种「换汇」的原因完全不同,别混为一谈:
· 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 后台走完
· SGD —— 🟡 它在香港主体的原币结算名单内(Lynn 260903),跟下面两个不是一回事: 不是没路,是路开着我们还没走 —— 差的是 Airwallex 能不能开 SGD 收款户(jmj 未回)+ 后台加个 payout account。PayNow 260905 刚开张,这件事从「反正零流水」变成了有实际收益。
· PLN / MYR —— 香港主体压根不支持这两个币种原币结算(Lynn 260905)。 不是我们没绑账户,是这条路不存在。
① 本地清算 —— 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)。 不是我们没绑账户,是这条路不存在。
实测
成本算出来了,这个数可以直接拿去挂牌。
用真实结算流水还原隐含汇率、跟当日市场价比得出,例:CAD 519 笔算出 0.980%。
路由实测
只测到「Adyen 这一段不换汇」,成本没测。
欧元按欧元结算,中间确实没有换汇动作 —— 但这笔钱最终还要变成美元,
那一步在哪儿换、吃多少,完全没测过。所以 ×1.000 只覆盖半条路:
下游若也吃约 1%,保本加成要回到 ×1.010。
理论值
没有实测,按合同费率推的。
该币种在 Adyen 零流水(或刚上线),数字取自合同 Schedule 1 的 FX Management Fee 档位。
有了实测就要换掉。
未验证
别人给的数,我们没有能力验证。
目前只有 PayPal 那 2.72% —— ERP 流水表里根本没有换汇记录,我们测不了。
不要当成我们的结论拿去对外谈判。
PayPal 换汇成本
🔴 我们目前测不了 —— 下面的数字是别人给的,没验证过
最新方案:重点审核新客的异常付款
2026-09-06 已上线 · R3 每天两次邮件提醒
已启用,测试邮件已发送 本次确定的是下方 R3 邮件提醒规则;R1、R2 仍待验证。
新增规则重点:首次下单至本次付款未满 6 个月,并且收货国家为菲律宾或哥伦比亚。 首单已满 6 个月的老客默认不进入这些新增规则,不把客户加入全局 Trust 名单。 已有银行明确怀疑欺诈、已确认团伙关联等强信号,仍按原规则处理。
R3 由 fraud-watch 只读检测后邮件通知张驰;张驰通知同事审核,需要时手动暂停发货。 按已确认方案,北京时间每天 07:00、19:00 两次检查,不加每 5 分钟轮询。实际通知还受数据同步和邮件送达影响。
R3 检查程序和每天两次定时任务已部署;2026-09-06 首次手动试跑 0 命中,13:00 测试邮件已发送。首轮定时检查计划为今天 19:00。R3 不在 Adyen 配置支付拦截,也不在 ERP 自动暂停发货。下方现有规则表保留上次核验记录,不能把本次看板更新当作支付风控已经上线。
新增规则重点:首次下单至本次付款未满 6 个月,并且收货国家为菲律宾或哥伦比亚。 首单已满 6 个月的老客默认不进入这些新增规则,不把客户加入全局 Trust 名单。 已有银行明确怀疑欺诈、已确认团伙关联等强信号,仍按原规则处理。
R3 由 fraud-watch 只读检测后邮件通知张驰;张驰通知同事审核,需要时手动暂停发货。 按已确认方案,北京时间每天 07:00、19:00 两次检查,不加每 5 分钟轮询。实际通知还受数据同步和邮件送达影响。
R3 检查程序和每天两次定时任务已部署;2026-09-06 首次手动试跑 0 命中,13:00 测试邮件已发送。首轮定时检查计划为今天 19:00。R3 不在 Adyen 配置支付拦截,也不在 ERP 自动暂停发货。下方现有规则表保留上次核验记录,不能把本次看板更新当作支付风控已经上线。
| 规则 | 条件(全部满足) | 动作 / 当前状态 | 历史回放 |
|---|---|---|---|
| R1 · 多卡主规则 | 新客+收货菲律宾/哥伦比亚;跨订单、跨站累计 24 小时 ≥5 张不同普通银行卡,包含失败尝试 | 请求 3DS 认证+挑战验证 待验证计数 仍需确认 Adyen 是否计入失败卡、当前卡,以及跨账号关联;不是直接拒单 |
8/7—9/5 本地回放:1 个订单 / 1 名买家 4 次命中尝试;不是 Adyen Matched 实测 |
| R2 · 连续失败提前认证 | 新客+收货菲律宾/哥伦比亚;24 小时 ≥3 张卡,其中至少 2 张不同卡已有明确支付失败 区分银行拒绝、3DS 失败、自定义风控拒绝和技术错误;排除旧规则误拒与技术错误 |
提前请求 3DS 认证+挑战验证 待验证失败来源 不能用“失败 2 次”替代“2 张不同卡失败”,也不能直接套用名称相近的旧规则 |
同一新客+两国口径,排除风控来源不清的失败后:0 个订单 本期样本结果,不表示未来不会出现 |
| R3 · 商务卡组合邮件提醒 | ① 首单未满 6 个月 ② 收货菲律宾或哥伦比亚 ③ 24 小时 ≥2 张普通银行卡 ④ 当前成功付款的卡为商业/商务卡 ⑤ CVC 结果明确为 0 Unknown(未知) 卡数含成功与失败尝试、包含当前卡;字段缺失不是 Unknown;Apple Pay / Google Pay 不按普通卡计入本条 |
邮件通知张驰 → 张驰通知同事审核 → 需要时手动暂停发货 已启用,测试邮件已发送 每天北京时间 07:00、19:00 检查;同一买家合并提醒,只列新增命中订单。系统只发邮件,不自动暂停发货,不自动拉黑或退款 |
6 个已付订单 / 1 名买家 分布在 5 天,单日最多 2 单 全部来自菲律宾疑似买家 K;首次在第 2 笔付款出现,此前成功授权 $35.02 |
统计窗口:2026-08-07—2026-09-05,ERP 只读历史回放。R3 平均约 0.2 单/天,但不是未来每月保证 6 单,也不是 6 个独立案件。
按买家邮箱跨站聚合,优先注册邮箱;会员镜像缺失时采用随单邮箱并在邮件披露。卡组织+卡尾号仅用于估算;不等于 Adyen 实际命中数。较早记录部分字段缺失,CVC 数据自 8/17 起较完整。
K 仍为疑似,小样本不能证明零误伤。
老客账龄用于减少打扰,不是绝对安全证明。首单时间取跨站历史最早订单;查不到首单时间的标“待核”,不直接当作老客豁免。 首单时间缺失但其余四项满足的,单独标为“资料待核”,不冒充完整 R3 命中。邮件列出订单和证据,由张驰与同事决定是否暂停发货及后续处置。
Adyen CVC 结果码:0 = Unknown;4 / 6 才是未提供安全码。 3DS 挑战是请求偏好,最终是否弹验证由发卡行决定。
老客账龄用于减少打扰,不是绝对安全证明。首单时间取跨站历史最早订单;查不到首单时间的标“待核”,不直接当作老客豁免。 首单时间缺失但其余四项满足的,单独标为“资料待核”,不冒充完整 R3 命中。邮件列出订单和证据,由张驰与同事决定是否暂停发货及后续处置。
Adyen CVC 结果码:0 = Unknown;4 / 6 才是未提供安全码。 3DS 挑战是请求偏好,最终是否弹验证由发卡行决定。
防盗刷规则
Adyen 现在到底在拦什么、验什么 · 哪些建了但没生效
先看状态,再看条件。“已启用”表示后台开关和必要挂接已核对;“已停用”不执行;“未接入执行”只是条件检查;拿不准的单列“待核”。
Block 是拦截动作,要在规则启用且条件满足时才可能执行,不能把“建了规则”写成“正在拦截”。
Check for 3DS 只判断条件,还要连接已启用的 Dynamic 3DS 才会由这条规则请求认证。 R3 是我们自己的邮件提醒,不属于 Adyen 的支付拦截或 3DS 规则。
Block 是拦截动作,要在规则启用且条件满足时才可能执行,不能把“建了规则”写成“正在拦截”。
Check for 3DS 只判断条件,还要连接已启用的 Dynamic 3DS 才会由这条规则请求认证。 R3 是我们自己的邮件提醒,不属于 Adyen 的支付拦截或 3DS 规则。
请求 3DS 不等于一定弹挑战,也不能保证挡住所有盗刷。
挑战是让买家输验证码、确认银行 App 等交互;无感认证也能判断风险。是否有责任转移要看实际认证结果与
“请求挑战”只是我们的偏好,不是命令;最终拍板的是银行。 Adyen 官方说明
liabilityShift。“请求挑战”只是我们的偏好,不是命令;最终拍板的是银行。 Adyen 官方说明
Adyen 3DS 规则:已启用 / 已停用
2026-09-06 直接读取后台复核 · Company 与三个商户号逐个核对 · 本次只更新看板,没有修改支付规则
6 项已启用,2 条已停用。TrustList 已找到真实付款触发记录。
状态放在最左列;不再把停用项放进“已生效”清单。
已启用:已核对开关与必要挂接
| 当前状态 | 触发条件 | 执行动作 | 范围 | 后台规则 / 核验依据 |
|---|---|---|---|---|
| 已启用 | 买家 IP 在哥伦比亚 | 请求 3DS +请求挑战 | Company 三个商户继承 | shopperCountryCO_Always3DSChallengeActive 已勾选;国家 CO;请求认证/挑战均 ALWAYS |
| 已启用 | 收货国家为哥伦比亚 | 请求 3DS +请求挑战 | 商户层 ×3 | deliveryCountryCO_Always3DSChallenge挂接 deliveryCountryColombiaCheck3DS(82-202203);条件规则 On、三个商户动态规则 Active 均已勾选 |
| 已启用 | 点名买家 karlsantos(user_182441) | 请求 3DS +请求挑战 | 商户层 ×3 | user182441Always3DSChallenge挂接 user182441KarlSantosCheck3DS(82-203904);条件规则 On、三个商户动态规则 Active 均已勾选 |
| 已启用 | 24 小时 ≥6 张不同卡 且收货菲律宾 / 哥伦比亚 | 请求 3DS +请求挑战 | 商户层 ×3 | multiCardHighRiskCountry_Always3DSChallenge挂接 multiCardHighRiskCountryCheck3DS(82-203912):distinctCardsInLast24Hours >= 6;条件规则 On、三个商户动态规则 Active 均已勾选。ShowZStoreECOM后台近30天 Matched=0;不同于以前的历史估算3次 |
| 已启用 历史触发已证实 | 买家命中 Shopper reference 允许名单 检查82-122994 | 当前请求3DS+请求挑战 9/5已设Always;改后普通卡挑战待新样本 | Company 三个商户继承 | TrustListAlways3DS8/28、9/1普通Visa付款详情明确记录本规则触发,风险分-100,当时挑战偏好为Prefer not。9/5改后仅查到一笔Apple Pay,页面显示offerTxVariantNotSupported,无普通卡新样本。旧说明气泡与实际交易表现矛盾,不能仅凭Trigger on TRUST未勾选就判定失效;本次未改配置。 |
| 已启用 | 符合 RBA 处理条件的高风险付款 | RBA 发起 3DS 时请求挑战 | Company 三个商户继承 | Force 3DS Challenge for RBARisk management、Risk-based authentication 和 Force 3DS Challenge 均 On;三个商户都未勾选 Override company setting |
已停用:当前不执行
| 当前状态 | 原触发条件 | 当前执行情况 | 范围 | 后台规则 / 核验依据 |
|---|---|---|---|---|
| 已停用 | 买家 IP 在菲律宾 | 本条不执行 保存过“请求挑战”偏好,不代表仍在生效 | Company | shopperCountryPH_Always3DSChallengeActive 未勾选;2026-09-06 复核 |
| 已停用 | 旧版买家 IP 在哥伦比亚 | 本条不执行 旧配置是不请求挑战 | Company | FraudRiskCheck3DSActive 未勾选;不能按名称把它当 ML 高风险规则 |
三个商户号:ShowZStoreECOM / LuteHKECOM / JunfanHKECOM。商户层先判断,再判断公司层;三个商户默认
这里是既有 Adyen 规则,不自带 R3 的“新客未满六个月”条件。开关启用、规则命中、银行实际挑战,是三件不同的事。历史流量/估算次数不再当作当前生效证据。
Use company settings,公司默认 Prefer not。规则按顺序匹配,不代表每项都会叠加执行。这里是既有 Adyen 规则,不自带 R3 的“新客未满六个月”条件。开关启用、规则命中、银行实际挑战,是三件不同的事。历史流量/估算次数不再当作当前生效证据。
盗刷画像:两波真实案例长什么样
他们换什么、不换什么 · 哪条规则抓得到 · 结合历史档案与260905只读回放;确证、疑似与未知分开记录
| 特征 | 哥伦比亚团伙(8/2–8/5,已确证 66 单欺诈举报) | 菲律宾 karlsantos(8/17 起,疑似 无举报无拒付) |
|---|---|---|
| 规模 / 节奏 | 8/2—8/5 115 次成功授权 / $17,370.51,四站涉及 GD 89 单 $11,783 / gkloot 11 单 $3,614 / CB 9 单 $1,201 / ShowZ 6 单 $772;8/2 晚开始,8/5 凌晨 01:39 停 |
19 天 25 次尝试 / 10 笔成功 / 合计 $720 小额反复,$10 定金、$60 这个量级;首单北京时间8/18;账号年龄随查询日期变化 |
| 换不换卡 | 换:49 组成功卡标识(Visa / MC / Amex),一天十几张 | 换:9 组卡标识,只看成功付款会看见3组(…0243 / …4065 / …6077 成功扣过款) 08-25 八分钟换 6 张卡刷同一单,在系统眼里是「一笔 $60 成功订单、一张卡」 |
| 换不换账号 | 注册邮箱两个(andres_capone90@hotmail.com / andrescapone80@gmail.com)按注册邮箱得到两组;历史档案另称支付邮箱变化,但旧回调字段缺失,本次未逐单核实。跨账号关联需要验证 |
不换:单账号 karlsantos0777@gmail.com |
| 收货地址 | 🔴 不换:主地址 Cra. 30 # 102C-48, Medellín, Antioquia, Colombia,收货人 Andres molina,电话 3245641436历史涉及麦德林与佛州转运仓;“29单已发货”已被后续核查纠正,不作为损失依据 |
不换:收货菲律宾 |
| IP / 设备 | 不换:IP 179.50.104.177(哥伦比亚)两天相同;设备指纹 effae6e3…4329 两天相同,清了 cookie 也没变 |
PLDT / Converge 家宽动态 IP(112.200.206.129 / 139.135.241.31),拉黑会误伤 |
| 卡的类型 | 混合;被拒那笔是墨西哥 SCOTIABANK INVERLAT 的 Visa。90 天欺诈举报的发卡国:US 50 / GB 10 / NL 9 / CA 4 | 本次付款记录为 Business / isCardCommercial=true;商业/商务卡不等于预付或虚拟卡 |
| 稀有信号 | 每单换邮箱 + 同一设备指纹 + 同一收货地址 | CVC = 0 Unknown(未知),不是“未提供”。10笔成功付款的AVS前8笔未知、后2笔地址/邮编不匹配。15次失败:11次FRAUD、2次余额不足、2次Declined Non Generic;11次FRAUD中9次有自定义规则打分100 |
| Adyen 自己拦住了吗 | 历史档案:66单欺诈举报样本中63单未发起3DS、31单风险等级veryLow。成功欺诈订单曾漏过,不能把全部尝试写成零拦截 | 付款成功与风控拒绝均存在;有成功记录为authenticated=false、liabilityShift=true,不能仅凭一个字段推定安全 |
| 什么挡住了他们 | ✅ 「哥伦比亚 IP → 3DS 验证」实战拒付 8+ 次(3D Not Authenticated,Fraud scoring 0 = 是 3DS 拦的不是评分拦的),敞口 $0 | ✅ 点名规则 + 「≥6 张卡 AND 收货 PH/CO」(19 天 3 笔全是他) |
| 损失 / 定性 | 90 天哥伦比亚 163 单已付 / 66 单欺诈举报 = 40.5%(全站 0.13%);撤回“29单已发货 / $2,835净损失”旧结论:8/6后续记录显示29单取消、无ERP物流单号;本次未重新核验物流或计算净损失 | 无拒付、无欺诈举报 ⟹ 只能写 suspected;首笔扣款距 9/4 仅 17 天,举报要 30–90 天才回来 |
两波的核心区别,一句话:
哥伦比亚靠的是「换账号 + 换卡」,唯一不换的是收货地址、IP、设备 —— 需要同时考虑地址 / IP 与多卡行为;仅按注册邮箱会拆成两组。
菲律宾靠的是「一个账号反复换卡」 —— 所以能抓住他的是多卡规则,新客+收货菲律宾可以收窄异常组合的审核范围。
🔴 两条线互相顶替不了。「≥N 张卡不分国别」能不能抓哥伦比亚这种,取决于 Adyen 的 ShopperDNA 能不能把「每单换邮箱、但同设备同地址」的马甲并成一个人 —— 没有实证,档案里明写他们当时「每单换邮箱正好绕开 ML」。
哥伦比亚靠的是「换账号 + 换卡」,唯一不换的是收货地址、IP、设备 —— 需要同时考虑地址 / IP 与多卡行为;仅按注册邮箱会拆成两组。
菲律宾靠的是「一个账号反复换卡」 —— 所以能抓住他的是多卡规则,新客+收货菲律宾可以收窄异常组合的审核范围。
🔴 两条线互相顶替不了。「≥N 张卡不分国别」能不能抓哥伦比亚这种,取决于 Adyen 的 ShopperDNA 能不能把「每单换邮箱、但同设备同地址」的马甲并成一个人 —— 没有实证,档案里明写他们当时「每单换邮箱正好绕开 ML」。
| 手段 | 对哥伦比亚团伙 | 对菲律宾 karlsantos |
|---|---|---|
| 收货地址 = CO / PH → 验证 | 实战挡住 | 收货 PH 那条建了没挂(空跑) |
| IP = CO / PH → 验证 | 实战拒付 8+ 次(他们没换 IP) | PH 那条已停(90 天 0 举报) |
| ≥N 张卡(不分国别) | 未验证 取决于马甲能否被并成一人 | 抓得住 7 张卡,阈值 4/5/6 都中 |
| Adyen ML / RBA | 漏 31 单 veryLow | 漏 评分 0 |
| 设备指纹点名 Block | 可行未启用 260805 已验证写法,无需传新数据 | — 家宽动态,不适用 |
| 多卡+商务卡+CVC 未知 | — | R3邮件提醒已启用 新客+两国6单/1人;小样本不证明零误伤 |
出处:Adyen 时间线 260805a(团伙事件)/ 260805e(实战拒付逐笔)/ 260904(40.5% 那张表,ERP 通知日志对订单 76/76 全对上)/ 260904 karlsantos 25 笔逐笔核。买家标识是我们自己档案里的,看板有登录墙。
未接入验证:条件已建,但未挂接执行
2026-09-06复核:下列5条条件规则为On,但公司和三个商户的Dynamic 3DS中均未挂接这些规则
| 规则名 | 条件 | 效果(影响多少笔) | 状态 |
|---|---|---|---|
sameShopperMultipleCards48hBlock |
同一买家 48 小时内用过不止一张卡 字段 differentCardOrBankAccountsUsedByTheSameShopperInLast48Hours == true;阈值 Adyen 内定,看不见也调不了 |
历史记录:30 天 168 笔 260904留档,本次未刷新命中数 |
未接入验证 |
multiCardPlusIssuerRefusalsCheck3DS |
上面那条 AND 该买家 24 小时内被发卡行拒过 ≥2 次transactionsRefusedByIssuerInLast24Hour >= 2 |
260904创建;本次仅核对开关和挂接 | 未接入验证 |
🆕 distinctCards2DryRunControl阳性对照 |
24 小时内用过 ≥2 张不同的卡distinctCardsInLast24Hours >= 2,历史估算约21笔/天,需读取实际Matched验证 |
260905创建;本次未刷新Matched统计 | 未接入验证(对照) |
🆕 distinctCards5Check3DS |
24 小时内用过 ≥5 张不同的卡distinctCardsInLast24Hours >= 5,不加任何国别条件 |
260905创建;本次未刷新Matched统计 | 未接入验证 |
deliveryCountryPhilippinesCheck3DS |
收货地址 = 菲律宾deliveryCountry == Philippines |
≈1 单/天 90 天 94 单 / $6,072(订单表算的) |
未接入验证 |
🔴 这5条未挂接 Dynamic 3DS,当前不会由它们单独请求买家验证;买家仍可能被其他已启用规则要求验证。
🔴
🔴 为什么要有
(原先列在这里的「24h ≥4 张卡」提案已被 260905 落地的「≥6 张卡 + 收货 PH/CO」取代,规则没建。)
🔴 「效果」里的估算值不等于 Adyen 实际命中数 —— 我按
🔴
distinctCards5Check3DS 是专门为了回答一个问题建的:Adyen 的「24 小时内不同卡数」这个数,
刷失败的卡算不算一张?算,规则才拦得住试卡的人;不算,规则就是摆设。
Adyen 自己没写清楚 —— 后台字段说明、官方文档、单笔交易明细三处都只说 "used",没说成功还是被拒
(对比它别的字段:totalAuthorizedAmountInLast24Hours 明写 "authorised"、还有专门数被拒的
transactionsRefusedByIssuerInLast24Hour ⟹ 它分得清、只是这里没写)。
倾向是「含被拒」,但没实证。🔴 为什么要有
distinctCards2DryRunControl 这条阳性对照(四审 Kimi 指出、我的疏漏):≥5 张卡的事件很稀有,
跑几天可能就是 0 命中——0 分不清是「真没人到 5 张」还是「规则压根没记账」。只有对照规则确实有命中、≥5 是 0,
才能说 0 是真的。验法:跑几天后拿 ≥5 命中的人回订单表比对,
命中了「成功卡数不足 5 张」的人就证明含被拒。顺带还能量出 ≥5 会打到几个人、几个是真客户。(原先列在这里的「24h ≥4 张卡」提案已被 260905 落地的「≥6 张卡 + 收货 PH/CO」取代,规则没建。)
🔴 「效果」里的估算值不等于 Adyen 实际命中数 —— 我按
shopperReference + 卡尾4位/有效期 数,Adyen 用 ShopperDNA 认人(跨设备/邮箱/卡)。量级可参考,绝对值必须挂上去空跑几天读真值(张驰 260904:「先定规则,最后一起确定命中」)。Adyen 拦截规则:15 项开启,5 项关闭
2026-09-06后台复核 · 20项包含名单子规则,不是20项都在拦截 · 下列统计为ShowZStoreECOM近30天页面显示值
| 当前状态 | 规则 | 类型 / 范围 | 后台拦截统计 |
|---|---|---|---|
| 已启用 | Machine learning: fraud risk | Pre auth | 28 |
| 已启用 | Machine learning: bot attack risk | Pre auth | —(后台未显示数值) |
| 13项已启用 | Default block lists 中的13项授权前名单 | Pre auth;逐项读取均On | 组内8次,来自Shopper reference |
| 已停用 | Refund abuse: high risk | Pre auth | — |
| 已停用 | Liability shift status blocked | Post auth | — |
| 已停用 | Address Verification System (AVS) | Post auth | — |
| 已停用 | Card Verification Code (CVC) | Post auth | — |
| 已停用 | Paypal Payer Id(名单子项) | Post auth | — |
On表示该检查已开启,具体支付仍需满足条件,且可能由RBA等机制进入认证流程。后台显示“—”不直接改写成0,也不把历史命中数当成当前开关状态。
判断依据:为什么多卡规则不该直接挂上去
260904 实测,全部来自命中名单 join 订单表
| 结论 | 数据 |
|---|---|
| 168笔历史命中的18个买家有购买史,不宜仅凭换卡拒单 | 最多的 737 单、次多 558 单 / $41,832;最少的也有 11 单。连「3 个月内新买家」档里的也是 20 天下了 32 单的活跃客 |
| 本站买家天生高频换卡,48h 内换卡是常态不是信号 | 活跃买家人均历史 39.7 单;$1.00 小额授权近 7 天 178 笔 / 93 个买家 / 158 笔成功,是最高频的一档 |
| 账龄用于收窄范围,不能单独定性 | 4 个会被误伤的真客户账龄 20 / 30 / 32 / 88 天;疑似买家K也属于新客,混在里面。历史单数也分不开(他 17 单,比其中 3 个真客户还多) |
| 连续失败要核实来源 | K的15次失败中11次为FRAUD,其中9次有自定义规则打分100。不能把旧规则误拒再当成独立盗刷证据 |
| 疑似买家K已有点名措施 | 点名规则 user182441Always3DSChallenge 与≥6+两国规则已有记录;菲律宾IP规则已停。新增规则仍需验证其他买家 |
| 老买家占大头,新增规则默认排除首单已满6个月者 | 近 30 天活跃买家按人:6 个月以上占 62.6%(1,951 人);按笔 67.3% |
| 🔴 8/15–8/18 有一波误伤,算任何基线都要剔掉 | 那 4 天两个大客户(107 单 / 558 单)合计被判 FRAUD 54 笔,而这两人零拒付、零欺诈举报 |
| 🟢 换成「24h 内 ≥4 张卡」,信噪比明显好转 | 8/17 起 19 天命中 20 笔 / 11 人:1 个疑似买家(karlsantos,飙到 7 张卡、3 笔被判 FRAUD)+ 2 个可疑新号(首单 3 天前 / iCloud 隐藏邮箱)+ 8 个真客户。 对比 48h 那条的 18 人全是真客户 —— 但误伤仍占 8/11,所以动作只能是挑战,不能是拒单 |
| 🔴 为什么不设成 Block | 命中里 mrdiazjj 是 2022 年起 157 单的老客户,这 19 天 24h 内用了 4 张卡、3 笔全部成功。设 Block = 这 3 笔直接拒掉,就是 8/15–18 那波干过的事 |
| ✅ 最终落地方案:≥6 张卡 AND 收货 PH/CO(260905) | 19 天命中 3 笔,全部来自 karlsantos(收货菲律宾,他卡数飙到 7 张);本地样本未见其他买家,不代表未来零误伤。
同期收货 PH/CO 的授权共 45 笔 / 13 个买家,哥伦比亚组最高卡数只有 1(完全没有多卡行为)。
≥6 张这条线本身也干净:第二名 bigjrock25 只有 5 张 |
| 🔴 算这个数时先修了一个假阴性 | 第一版 join「授权 → 订单表」用 merchantReference 直连 oid,命中 0 笔。
实际 merchantReference 带后缀(23042901382871_17_balance),join 断了不是真没有。
截断 _ 后覆盖率 99.8%,才算出上面那些数。「0 笔」永远要先怀疑是不是自己接错了 |
Adyen 能写出什么规则(积木清单)
提新规则前先在这儿确认「这个条件写得出来吗」
| 能力 | 细节 |
|---|---|
| 动作 | Allow 放行 / Block 拒绝 / Review 进人工审核队列 / Check for 3DS 条件检查,需另挂Dynamic 3DS执行 |
| 条件组合 | 支持多条 AND,也支持 OR 分组。数值字段有 > < >= <= == !=;文字字段有 是/不是 / 在列表里 / 不在列表里(可挂自定义名单) |
| 买家历史(ShopperDNA,Adyen 自己攒,不用我们传) | 24h/7d/30d/365d 授权次数、不同卡数、不同设备/IP/邮箱/收货地址数、被发卡行拒次数、被 Adyen 风控拒次数、有没有过欺诈拒付、以前过没过 3DS、成为忠诚买家多少天、首次出现至今多少小时、退款占比 |
| 本单信息 | 金额 / 币种 / 收货国·州·城·邮编 / 账单地址 / 账单与收货是否一致 / 卡 BIN / 发卡行 / 发卡国 / 卡种(信用·借记·预付) / 支付方式 / 买家 IP·国家 / 邮箱域名 / 邮箱是否像机器生成 / 持卡人姓名特征 / 设备指纹 / 浏览器 / 下单时段 / 3DS 结果 / AVS / CVC / 责任转移 |
| 速度类(短窗口计数) | 同一卡号/持卡人姓名/邮箱/IP/收货地址 在 30 分钟 ~ 30 天内被用过几次;同一买家用过几套支付信息;同一套支付信息被几个买家用过 |
| 账龄 | shopperAccountAgeHours 存在,但数据来自支付请求里的 accountInfo.accountCreationDate —— 我们现在没传,所以是空的(待办:找希尔加) |
| 🔴 不能做的 | ① Check for 3DS 类规则不能回测(后台明写)② 回测对「买家历史 / 速度类」字段是废的 —— 实测:同一条件线上命中 168 笔,回测只出 1 笔(这类计数器是交易发生时实时算的,重放不出来)。信了它会得出「这规则不命中、开了没风险」的反向错误结论 ③ 规则名建完不能改 |
实施清单与历史决定
以上方最新方案为准 · 本次尚未修改 Adyen / ERP
| 事项 | 当前决定 | 下一步 |
|---|---|---|
| R3 新客+两国+商务卡组合 | 已启用,测试邮件已发送 只发邮件,张驰通知同事审核,需要时手动暂停发货 | fraud-watch 只读 ERP 授权日志与四站订单,按买家邮箱跨站聚合;会员镜像缺失时采用随单邮箱。每天 07:00、19:00 检查。124 条本地测试、27 条服务器专项测试通过;检查与定时任务已部署。发信凭据已同步修复,2026-09-06 13:00 测试邮件已被邮件服务器接受,收件箱到达情况待张驰确认 |
| R1 ≥5 张卡 | 待验证 Check for 3DS,不是 Block | 读取 distinctCards5Check3DS 与 distinctCards2DryRunControl 实际命中,核实失败卡、当前卡与跨账号关联;现有空跑条件尚未改成新客+两国 |
| R2 多卡+不同卡失败 | 待验证 不能直接挂上旧 multiCardPlusIssuerRefusalsCheck3DS | 确认不同失败卡数与失败来源能否表达;银行拒绝次数不等于不同失败卡数 |
| 老客与钱包 | 首单已满 6 个月默认不进入新增规则,不做全局 Trust 白名单;R3 不按普通卡计入钱包 | 已有明确欺诈信号按原规则处理;首单时间缺失先核实。邮件不执行暂停或放行;人工处置由张驰与同事决定 |
| 哥伦比亚专项、点名、≥6+两国 | 2026-09-06复核已启用 本次未改规则 | 新规则上线验证后再比较覆盖范围;新客规则不能直接替代覆盖老客的现有规则,不预先删除旧规则 |
| 历史 ≥4 张卡版本 | 没有建,已被 ≥6+国别版本取代 | 保留历史记录,不把旧方案当作已生效 |
| 旧版“不分国家、只发邮件”方案 | 已被最新方案取代 | 历史:阈值定 5 —— 张驰 260905 拍板;当时提及的 bigjrock25 未定性。如今 R3 限定新客与两国,2026-09-06 确定只发邮件,暂停发货由张驰安排人工处理 |
| 信任名单 / RBA | 本次实核:RBA On且三个商户继承;TrustList规则已开启,8/28、9/1已有真实触发记录 | 9/5改为Always请求挑战后,尚无普通卡新样本;继续以付款详情核验,不因旧界面说明与历史实证矛盾而贸然改开关 |
| 菲律宾全体收货验证 / 原始48h多卡 | 不直接挂上 | 本次范围是新客+两国+异常组合,不是菲律宾所有订单 |
| 欺诈举报率1.63%明细 | 保留张驰260904「先不查」决定 | 不纳入本次更新 |
固定保证金归属
每一笔压在哪个号 · 内部算哪个网站头上
这里回答两个不同的问题,别混:
① 钱压在哪儿 —— PayPal 按账号冻钱,一笔保证金锁在一个具体的收款号里,退也只能从那个号退。
② 算谁头上 —— 内部成本归属,按项目(网站)分摊。两者不要求一一对应: 比如老轮的 $8 万压在超砖的收款号上,但按分摊超砖只承担 $4,300。
① 钱压在哪儿 —— PayPal 按账号冻钱,一笔保证金锁在一个具体的收款号里,退也只能从那个号退。
② 算谁头上 —— 内部成本归属,按项目(网站)分摊。两者不要求一一对应: 比如老轮的 $8 万压在超砖的收款号上,但按分摊超砖只承担 $4,300。
① 逐笔明细 每一笔保证金压在哪个号、什么时候冻的、谁先垫的
② 按项目归属 每个网站分别承担多少
换 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 这边多数是我们去申请、对方来审(开新商户号、开新支付方式),卡住了只是某个通道开不成。 看的时候别把两栏的严重程度并列。
🔴 这一页是映射,不是原件:每条点开后底下标了它在档案里的段落, 完整往返、原始材料、我方测算和待办都在档案里 —— 看板只映射核心结论,两边不一致时以档案为准。