摘要：独立站已经在用 Stripe 收款时，先在 Dashboard 的 Radar 规则页把拦截（block）、放行（allow）、审核（review）分开看：默认规则会筛所有交易；自定义规则要套餐支持，且只作用于未来付款。Allow 会覆盖其他规则，需要联系 Stripe 才能创建。依据 Stripe 官方文档，查询日期 2026-11-13。只放官网普通链接（affiliate_later）。

依据：Stripe 文档 Radar（对照英文原文）、欺诈预防规则（对照英文原文）、列表（对照英文原文），以及 Radar 的运作机制（对照英文原文）。查询日期：2026-11-13（北京时间）。只放官网普通链接（affiliate_later: 1）。未在当前文档写明的套餐价格、具体误杀率百分比和按钮文案，本文不编。本文不是开户、支付集成或法律意见。

独立站已经接通 Stripe、银行卡付款能进余额之后，下一件容易对不上的事，是一笔看起来正常的订单被拦下，或一笔高风险付款被放过去。先不要改结账页，先到管理平台的 Radar 规则页，把拦截（block）、放行（allow）和审核（review）三条动作分开看。开户国家和结算币种，见独立站收 Stripe。结账弹出 3D Secure、责任转移怎么核对，见Stripe 3D Secure。拒付来了怎么准备材料，见独立站拒付怎么处理。本文只核这一层：默认规则筛什么、自定义规则怎么建、allow 为什么要特别谨慎。

1. 先分清：默认规则在筛所有交易，自定义规则要看套餐

欺诈预防规则开头写明：Stripe Radar 提供内置规则，帮助检测和防范所有支持的支付方式中的欺诈风险。所有交易均使用 Radar 的默认规则进行筛查。 如果你的 Radar 方案支持此功能，才可以在管理平台中创建自定义规则。文档没有在规则页列出各档价格，对照运作机制里的套餐功能表，自定义规则、回测、允许列表和拦截列表出现在 Radar Plus 和 Radar Pro；本文不写费率。

同一页还提示：欧盟企业可能受到地理封锁条例（Geo-blocking Regulation）及其关于禁止封锁欧盟成员国客户付款规定的影响。如果你的客户在欧盟成员国，不要只因为对方所在成员国就写一条拦截规则。

默认规则里，有一组基于 AI 风险的规则。查询当天中文文档里可以看到：if :risk_level: = '最高'（对应英文 'highest'）标记为已废弃，该规则会拦截具有较高欺诈风险的付款且不会处理，并写明此规则默认启用；Review if :risk_level: = 'elevated' 则是：默认情况下，Stripe 要求对怀疑具有较高欺诈风险的支付进行审核。另外还有账户级 AI 规则，用 KYC 信息、交易记录、地理风险因素和行为模式计算账户级风险。文档还提到 CVC / AVS 相关内置规则：2024 年 12 月 17 日起，新客户以及尚未用过旧版规则的现有客户，看到的是「按风险分数」版本；旧版留给已经启用过这些规则的客户。不要把自己账户里还在用的旧版文案，当成所有新账户的默认界面。

也可以写自定义规则来请求 3DS，或按 3DS 结果再决定 allow / block / review。常用属性里有 is_3d_secure、is_3d_secure_authenticated，以及 has_liability_shift（Stripe 预期责任转移可以覆盖该笔付款，它和 3DS 并不总是同一件事，例如部分地区的 Apple Pay）。3DS 失败后支付意图到哪个状态、成功验证也不等于责任一定转移，细步骤看3DS 前文，本文不重写那一套测试卡流程。

2. 谁能建规则，规则只作用于未来付款

只有账户所有者、管理员和开发人员可以创建规则。如果要让团队成员也能建，文档要求先检查团队设置，确认他们具有管理员权限。

自定义交易规则最多 200 条，账户规则最多 100 条。账户级规则（例如对 connected account 发起审核，或暂停自动打款）主要给平台 / Connect 场景用。独立站核对交易拦截和误杀，先盯交易规则；不要把本页理解成 Connect 平台教程。自动提现计划和到账，见Stripe 自动提现。

文档在「创建有效的规则」里还写了几条会直接影响你怎么测：

• 默认情况下，规则适用于所有支持的支付方式，除非你在规则里用 payment_method_type 限定。
• 规则仅适用于未来支付，不适用于已处理的支付。 今天启用一条拦截规则，不会回头去改已经成功或已经失败的旧单。
• 请求 3DS 的规则，只在使用 Stripe Checkout、Payment Intents 或 Setup Intents 时适用，并且会在审核、阻止和允许规则之前先评估。
• 实施拦截规则去拦下所有匹配付款、或对符合条件的账户暂停提现之前，先考虑要不要改用审核。
• 允许规则会覆盖 Stripe 的默认规则，以及任何符合相同条件的其他自定义规则，要谨慎。

3. 官方给出的添加交易规则步骤

在管理平台打开 Radar 规则页面后，文档「添加交易规则」的步骤是：

1. 点击 + 添加规则。
2. 在「发生此情况时」中，选择「尝试付款」（Payment is attempted）。
3. 在「执行此操作」中，选择满足条件时的响应，例如「阻止」或「审核」。
4. 在「如果满足此条件」中，用 {attribute} {operator} {value} 写条件。属性以 : 开头，输入冒号可打开有效属性列表；自定义 metadata 用双冒号，例如 ::product_sku::。
5. 点击「测试规则」。
6. 如有必要，修改检测到的验证错误。
7. 在「审核新规则」页面上，根据最近的支付查看这条规则的表现。文档写明：测试界面会用近 6 个月 的收款做模拟。如果可能影响多种支付方式，可以用筛选器按 ACH 或银行卡查看。
8. 点击「调整流量分配」，先选一个较小的百分比，再按效果逐步提高。
9. 点击「添加规则」，将此规则应用于所有未来交易。

4. 流量分配：可先小比例，0% 是影子模式

「逐步启用规则」一节写明：流量分配用来控制受自定义交易规则影响的匹配付款百分比。例如把拦截规则的流量分配设为 5%，Radar 就只拦截 5% 的匹配付款。默认是 100%。设为 100% 时，对每笔匹配付款都执行该动作。

同一笔交易的重试会落在同一个分配桶里，每次重试的结果和原始尝试相同。对银行卡，分组信号按优先级是：相同账单；没有账单时相同客户和金额；没有客户时相同银行卡和金额。其他支付方式则把同一笔付款的重试分到同一桶。

若只想看规则会怎样、先不要真正执行动作，把流量分配设为 0%。文档把这一档称为影子模式（shadow）：Radar 会评估规则，并报告如果不执行规则操作会发生什么。流量分配仅适用于自定义交易规则。

5. 审核、拦截、放行：三条动作不要混着用

审核（review）。 支付符合审核规则时，Stripe 仍会正常处理这些支付，并把它们放到审查队列里，供团队再看一眼。规则写得过宽，队列会被撑满，团队审不过来，客户这边也会变慢。测试时文档建议看近 6 个月的模拟结果：进入队列的量会不会把团队压住、人工审核能不能比自动系统更能分清风险、样本里是不是既有成功付款也有退款或争议。官方举例：只写 Review if :card_funding: = 'prepaid' 会太宽，补上一次性邮箱之类的条件后，审核量会小一些。文档里的「估计误杀率」是管理平台里的指标名称，本文不编具体百分比。

拦截（block）。 文档建议把拦截规则用在你比较有把握的欺诈，或业务上已经明确的限制（例如拦截预付卡）。拿不准时，官方建议先用审核规则放进审查队列，排除误报后再决定要不要改成拦截。测试时要尽量压低误杀：一个好的阻止规则，被拦住的欺诈性付款应比合法付款多得多。测试结果如果参差不齐，先维持审核，再收集信息。官方举例：Block if :card_country: != 'US' 可能过宽，加上 :risk_level: = 'elevated' 后更集中。

放行（allow）。 这一条要单独看。文档在「允许规则的可用性」里写明：如果你希望创建允许规则，请联系我们。 不要理解成每个账户打开规则页就能直接新建一条 allow。允许规则会覆盖你的所有其他规则（含 Stripe 默认规则和其它自定义规则），因此要谨慎。创建后会立即应用到所有新付款，也包括和此前被拦截付款类似的新单。测试时要看：原先被拦截的付款里，有多少会被这条 allow 放行；其中是否包含后来发生争议的付款。官方建议在允许规则里加上 and :risk_level: != 'highest'，避免把最高风险付款一并放过去。举例：Allow if :ip_country: = 'GB' 过宽，加上 and :risk_level: != 'highest' 更稳。

6. 列表：用 @list_alias 引用，不必为每个值单写一条规则

如果套餐支持，可以自建列表，再在规则里引用，避免为每一个邮箱或 IP 单独写规则。文档举例：受信任客户的 Customer ID 可用来自动允许；与欺诈关联的电子邮箱可用来自动拦截；可疑 IP 可以把匹配付款送进审核队列。英文规则写法如 Block if :email: in @fraud_emails，@ 后面是列表别名。管理平台创建列表时，会自动生成别名，也可以覆盖。

查看列表时可以按值、作者和添加日期筛选。文档写明：每个列表最多可包含 50,000 个项目。默认列表可以增减条目，但不能编辑或删除列表本身。默认指纹允许列表里的条目最长有效期为 30 天。查询日期为 2026-11-13，若后来文档改了容量，以当时页面为准。

7. 上线前可勾的核对项

1. □ 已确认当前 Radar 套餐是否支持自定义规则；不支持时，不要在文档步骤之外找「非官方开启方法」
2. □ 建规则的人是账户所有者、管理员或开发人员
3. □ 已分清拦截、审核、放行：审核不会拦住付款，只是送进队列；拦截用在较有把握的情况；放行会覆盖默认规则，且需要先联系 Stripe 才能创建
4. □ 新规则只作用于未来付款；请求 3DS 的规则会在 review / block / allow 之前评估，且只适用于 Checkout / Payment Intents / Setup Intents
5. □ 测试时看过近 6 个月模拟；流量分配先从小比例或 0% 影子模式试起，同一笔交易的重试会落在同一桶
6. □ 允许规则若启用，测试结果里检查了「原先被拦截的付款有多少会被放行」，并考虑加上 :risk_level: != 'highest'
7. □ 没有只因为客户位于某个欧盟成员国就拦截付款
8. □ 自定义交易规则未超过 200 条，账户规则未超过 100 条；列表容量按文档的 50,000 封顶来规划

风险与范围

本文面向已经在 Stripe 支持地区持有账户、并用银行卡收款的独立站读者，只整理官方文档里关于 Radar 默认规则、自定义交易规则和列表的部分。能否开户取决于企业注册地和银行所在地是否在当前支持名单，见账户国家前文。跨境收款和结汇还要遵守所在地外汇与税务规定，不要用第三方「镜像」或绕开官方账户国家限制的做法。账户被冻结时的处理，见跨境收款账户冻结怎么办。收款工具怎么选，见独立站收款：PayPal、Stripe 与 Paddle。本文不构成开户、外汇、支付集成或法律意见。

来源（查询日期 2026-11-13 北京时间）

• Radar（对照英文原文）
• 欺诈预防规则（对照英文原文）
• 列表（对照英文原文；每个列表最多 50,000 个项目）
• Radar 的运作机制（对照英文原文；自定义规则出现在 Plus / Pro 功能表，本文不写价格）

中英文或页面更新不一致时，以英文原文和当前文档为准。未写明的套餐价格、误杀率百分比和未出现的按钮文案不编。只放官网普通链接（affiliate_later: 1）。

相关阅读

• Stripe 3D Secure：买家验证失败、责任转移和测试卡怎么核对
• Stripe 自动提现：计划、可用余额和银行到账怎么核对
• 独立站收 Stripe：账户国家、拒付率门槛与结算币种怎么核对
• 独立站拒付（Chargeback）来了怎么办：材料、时限与预防
• 跨境收款账户被冻结怎么办
• 独立站收款：PayPal、Stripe 和 Paddle 怎么选