Radar 规则调优最怕凭感觉。客服说「客户都被拦了」，工程说「那就放开一点」，一周后争议率上来，还是没人知道是哪条规则惹的祸。
先抽 50-100 笔订单看什么？
表 1：Radar 人审样本表
| 字段 | 后台位置 | 为什么要看 |
|---|---|---|
| amount / currency | Payment details | 金额是否触发规则 |
risk_level / risk score | Radar evaluation | 风险等级是否真的异常 |
is_3d_secure / is_3d_secure_authenticated | Payment details | 是否完成 3DS，是否有 liability shift |
card_country / ip_country | Payment method、Radar | 国家不一致是否影响判断 |
| billing postal code / CVC check | Payment details | 地址证据是否完整 |
| Radar action | Radar rules | allow、block、review、request 3DS 哪条命中 |
| review outcome | Review queue | 人审最终 approve、refund、block |
| dispute / refund | Disputes、Refunds | 规则后续是否真的减少坏单 |
50 笔不多，但足够暴露粗规则。比如 8 笔进人审，7 笔最后放行，说明队列里好客户太多。反过来，如果进人审的单子后来很多退款或争议，规则还不够硬。
四类规则动作有什么差别？
表 2：Radar 规则动作表
| 动作 | Stripe 行为 | 适合场景 | 风险 |
|---|---|---|---|
| Request 3D Secure | 让符合条件的客户完成 3DS | 高金额、新卡、风险等级异常 | 多一步验证会掉转化 |
| Review | 成功付款进入人工审核队列 | 不确定是否欺诈，需要人工看 | 不阻止付款，队列太宽会压垮团队 |
| Block | 在完成前阻止付款 | 明确欺诈或业务不接受 | 误伤好客户最严重 |
| Allow | 放行匹配付款 | 老客户、白名单企业邮箱、合同客户 | 会覆盖其他规则和部分默认保护 |
Stripe 文档明确提醒，Allow 规则要非常谨慎。一个 Allow if :ip_country: = 'GB' 看起来方便，但会把高风险付款也放进来。更安全的写法至少加 :risk_level: != 'highest' 之类的排除条件。
哪些规则写法最容易误伤？
表 3：常见误伤规则表
| 太硬的写法 | 问题 | 更稳的方向 |
|---|---|---|
Block if :card_country: != 'US' | 把海外真实客户全挡掉 | 加 risk_level、金额、3DS、地址完整度组合 |
Review if :amount_in_usd: > 99 | 年付客户全进队列 | 只看新客户、高风险、无 3DS 的大额付款 |
Block if not :is_3d_secure: | 不支持 3DS 的好卡也被挡 | 区分 3DS 失败、off-session、钱包支付 |
Allow if email domain in @customers | 老域名被滥用时也放行 | 加 customer age、risk level、历史争议排除 |
Review if prepaid card | 预付卡不等于欺诈 | 叠加 disposable email、风险等级、国家冲突 |
Stripe 的规则 tester 能用最近 6 个月 charges 做模拟。启用前先看它会命中多少 legitimate payments、多少 fraudulent/disputed payments。没有样本时，用 Review，不要直接 Block。
3DS 什么时候该触发？
3DS 适合高风险和高客单价，不适合每笔低价订阅都强制。Stripe 文档里的典型思路是：risk level 不正常且金额超过某个阈值时 request 3DS。
更细一点，可以分三层：
- 新卡、新客户、高金额，请求 3DS。
- 3DS 尝试了但没完成，阻止或送人审。
- off-session 订阅、Apple Pay、带 cryptogram 的钱包支付，单独处理，不要被一刀切规则误伤。
如果你卖 $9/月工具，每笔都 3DS，损失可能比欺诈还大。如果你卖 $499 年付 B2B 套餐，多一步验证通常值得。
改完规则要盯哪些指标？
表 4：规则改动复盘表
| 指标 | 看哪里 | 判断 |
|---|---|---|
| Payments sent to review | Radar rule performance | 是否队列变小 |
| Approved reviews | Review queue | 好客户是否还被大量拦进来 |
| Refund rate | Radar performance / Refunds | 人审通过后是否又退款 |
| Disputes from approved reviews | Radar metrics / Disputes | 放行单是否带来 chargeback |
| Blocked payments | Block rule metrics | 是否误杀明显下降 |
| Estimated false positive rate | Radar for Fraud Teams | Block 规则是否太宽 |
| 3DS Requested | 3DS rule metrics | 3DS 触发是否过多 |
每次改规则，记录规则名、旧条件、新条件、修改人、修改时间。不要今天改国家，明天改金额，后天改 3DS，最后没有人能复盘。
人审队列怎么交给客服处理？
给客服一张 5 分钟判断表：老客户、企业邮箱、合同客户、地址完整、3DS 成功，可以优先放行；新客户、高金额、地址缺失、临时邮箱、风险等级 highest，先联系客户或退款。
人审、退款和争议都发生在 Stripe Dashboard，客服和创始人来回切设备、切网络时，很容易被验证码打断，最后连同一笔付款的判断记录都不连续。可以用Stripe Dashboard 稳定访问承载这些高频后台动作，把审核、退款和争议处理放在固定工作环境里。
什么时候该把 Review 改成 Block？
只有一种情况：样本证明这条规则命中的付款大多后续退款、争议或确认欺诈，而且误伤率低。比如某个临时邮箱模式 + prepaid card + highest risk + 无 3DS，连续命中坏单，才值得从 review 升到 block。
反过来，Review 队列里多数订单最终 approve，就不要升级 block。应该缩窄条件，或者把 Checkout 里的地址、CVC、账单信息收完整。