规则参考

创建规则前，您需要理解其处理方式以及您能够用哪些交易和账户属性来设置评估标准。Stripe 的机器学习欺诈系统可为您阻止很多欺诈性付款，但您也可以用受支持的属性为您的业务量身设置规则。

交易规则处理和排序

Radar 会根据您创建的规则对每笔付款进行评估，这些规则是根据付款的活动类型制定的，并采用以下优先顺序：

1. 请求 3DS 验证：与 Payment Intents API 或 Checkout 一起使用时，这些规则会_请求_发卡行进行 3DS 验证（如果支持）。Radar 会先于任何阻止、审核或允许规则来评估这些付款。
2. 允许：这些规则_允许_付款被处理。落入允许规则的付款不会根据阻止或审核规则来评估。
3. 阻止：这些规则会_阻止_付款并将其拒绝。被阻止的付款不会再根据审核规则来评估。
4. 审核：这些规则允许处理付款，但之后会将其送入_审核_。

不对相同操作类型的规则排序。

如果一笔付款匹配某个规则的标准，Radar 将采取适当的措施并中止评估。例如，如果一笔付款匹配一个允许规则，则正常处理，不评估任何后续的阻止或审核规则，即使付款也满足它们的标准。下面是一组规则：

• **允许**小于 $10 的付款
• **允许**美国进行的且风险等级为 normal 的付款
• **阻止**风险等级为 high 的付款
• 阻止 greater than $1,000 的付款
• **审核**用 outside the US 签发的卡进行的付款

使用以上规则：

• 10 美元以下的所有付款都会得到处理，无论其风险等级如何或发卡地是哪里。由于第一个规则允许付款，因此不评估进一步的规则。
• 一笔在美国境内进行的 1500 美元的付款（正常风险级别）会正常处理，因为它满足第二个规则的标准，所以不根据阻止超过 1000 美元的付款的规则进行评估。
• 一笔超过 1000 美元的高风险付款被阻止，原因是它不满足两个允许规则的标准，然后无论评估顺序如何，都会触发两个阻止规则。

账户规则处理

Radar for Platforms 可让您的平台为交易和账户级操作创建规则。您可以在暂停账户提现或不暂停账户提现的情况下提交账户以供审核。

规则结构

规则结构分为两个部分——要执行的_操作_和要评估的_条件_：

{action} if {condition}

这些规则共同构成了_谓词_。在实践中，一条阻止所有超过 1,000 美元的付款的规则将显示为：

Block if :amount_in_usd: > 1000.00

• _操作_是 Block
• _条件_是 :amount_in_usd: > 1000.00

交易操作

当付款满足其标准时，规则将执行该部分描述的四个操作中的一个。以下操作类型的顺序表示 Radar 评估每个规则时所遵循的优先级。

要求 3DS 验证

与 Payment Intents API 一起使用时，此规则确定 Stripe 是否请求发卡行尝试 3DS 验证。仅请求 3DS 验证并不能阻止所有可能的 3DS 验证结果。无论此规则是否匹配，我们事后都会评估允许、阻止和审核规则。

允许

该规则决定是否允许符合特定条件的付款，无论其他匹配规则如何。当一笔付款符合允许规则中的标准时，不会进一步应用 Radar 规则进行评估。Stripe 会正常处理付款，但发卡行可能仍会拒绝支付请求。

阻止

阻止规则建议 Stripe 始终阻止付款。如果一笔付款匹配某个阻止规则的标准，Stripe 会拒绝它，不再评估其之后的规则。

审核

您可能想允许特定类型的付款，但同时可以选择进一步研究。通过审核规则，您可以将付款放入审核。这对于非常见模式的付款尤其有用，例如金额较大或您很少向付款来自的国家发货。Stripe 仍会处理这些付款并对客户扣款，但您有额外的机会来审核订单并检查欺诈信号。

触发特定规则时，Radar 将采取规定的操作，并中止任何进一步的规则评估。

账户操作

Radar for Platforms 包含一些规则，用于在账户满足其条件时执行以下两种操作中的一项：

• 提出审核
• 提出审核，然后在审核期间暂停提现

审核

您的平台可以对账户提出审核，这些审核会显示在 Connect 子账户列表的 Radar 审核队列部分。审核规则可帮助您确定账户本身何时可能对您的平台造成财务损失。

提现暂停 （和审核）

您可以快速采取行动来防止损失，方法是在审核账户时设置一个规则来自动暂停提现。这些审核也会显示在 Radar 审核队列中。建议您先提请账户审核，然后仅在确信该规则会按预期影响账户时才暂停自动提现。

条件

如果付款与某个规则的条件匹配，则采取相应的操作。一个基本条件本身由三个部分构成：

[attribute] [operator] [value]

• 属性：付款的属性（例如，金额_或_卡的类型）
• 运算符：对比属性与值时使用的算法（例如，大于_或_不等于）
• 值：您想使用的标准（例如，100.00 或 debit）

组合操作和条件后，规则的结构为：

{action} if {[attribute] [operator] [value]}

条件类型有四种，取决于属性的类型：

• [string_attribute] [operator] [string_value]
• [country_attribute] [operator] [country_value]
• [numeric_attribute] [operator] [numeric_value]
• [boolean_attribute]

您还可以将属性用作条件中的对应值。例如，您可以创建一条规则来阻止发卡国家/国家与支付发生地不匹配的付款：

Block if :card_country: != :ip_country:

有关所有可能情况的列表，请参考支持的属性。

字串属性

包括任意字符组合。字串属性和数值通常表示一条文本，例如银行卡的品牌（例如，visa、amex）或风险水平（例如，elevated）。可以在规则中使用它们来仅允许来自特定国家的付款，或阻止用预付卡进行的付款。

元数据属性

这些属性源自您已关联到付款的元数据。元数据属性可以作为字符串或数字来操作。用作字符串时，元数据属性_区分大小写_。

您可以在创建 Radar 规则时使用这些属性，进而依据您通过向付款关联的元数据字段给 Stripe 传递的任何自定义业务数据来编写规则。

元数据属性以下列结构书写：

::[metadata attribute name]:: [operator] [metadata_value]

例如，假设我们的一些付款具有元数据字段中存储的以下键值数据：

可编写一个规则，将匹配以下标准的付款放入审核。

Review if ::Customer Age:: < 30

还可以用元数据属性和本文档中提及的其他支持的属性用来编写规则。例如，可编写一个规则，仅当 Item ID 匹配 5A381D 且付款金额大于 1000 美元才将付款放入审核。

Review if ::Item ID:: = '5A381D' and :amount_in_usd: > 1000

元数据属性还支持 IN 运算符来匹配多个数值。例如，可编写一个规则，在 Category ID 为杂货店、电子产品或服饰时将付款放入审核。

Review if ::Category ID:: IN ('groceries', 'electronics', 'clothing')

您可以将 INCLUDES 运算符与元数据属性和其他字符串属性的规则结合使用来匹配子串。例如，您可以编写一个规则，如果 Item ID 包含字符串 A381，则将付款放入审核。该字符串将匹配 A381、5A381D、A381D、5A381 等。

Review if ::Item ID:: INCLUDES 'A381'

Customer 和 Destination 对象上的元数据

您也可以访问 Customer 和 Destination 对象上的元数据（如果它们被用于特定的付款）。这些属性使用以下结构：

::[customer|destination]:[metadata attribute name]:: [operator] [metadata_value]

例如，假设您有个客户的元数据如下：

如果客户的 Trusted 元数据字段为 true，则您可以写一个规则始终允许付款。

Allow if ::customer:Trusted:: = 'true'

或者，如果您的目的地有下列元数据时：

如果目的地的 Category 元数据字段为 new，则您可以写一个规则将付款放入审核。

Review if ::destination:Category:: = 'new'

国家属性

这些属性用两字母国家代码来表示国家，例如，US 表示美国、GB 表示英国、AR 表示阿根廷。国家属性的运行方式与字串属性相同，唯一的区别是数值必须是国家代码。

州属性

这些属性用 ISO 代码来表示州或某个国家的主要分区，例如用 CA 表示美国的加利福尼亚州、用 ENG 表示英国的英格兰，用 L 表示阿根廷的拉潘帕省。我们省略了州 ISO 代码中的两位字母的国家代码，因此如果您想阻止来自加利福尼亚的交易，请将州属性与 CA 进行比较。

Block if :ip_state: = 'CA'

州属性的运行方式与字串属性相同，唯一的区别是数值必须是 ISO 代码。

数值属性

由于这些只包含数字，因此它们支持的运算符比字串属性和值要多。付款的_金额_即为一个数值属性的示例。如果金额大于、小于、等于或者是不等于您指定的金额，则可以创建一个规则来执行某种操作。

对于随时间窗口计数的数值属性，计数不包括您当前正在处理的付款。例如，total_charges_per_customer_hourly 表示前一小时内从某个给定客户进行的收款尝试的次数。因此，对于某个客户在具体某一小时内的第一次收款尝试，total_charges_per_customer_hourly 的值为 0。同一小时内的第二次收款尝试，它的值为 1，以此类推。

首次见到后的时间 (Time-since-first-seen) 这一属性也没有考虑到您目前正在处理的付款。例如，没有邮件地址的付款会缺少 seconds_since_email_first_seen 的值。使用您的账户上从未出现过的邮件地址进行的付款也是如此（因为我们不包括当前正在处理的付款，该行为与第一个示例本质上是相同的）。查看下方有关缺少值的更多信息。seconds_since_email_first_seen 字段仅在处理了使用特定邮件地址的新付款后才不为空。

有界数值属性

有界数值属性类似于上述的数值属性。例如，它们排除了您当前正在处理的付款。不同之处在于，有界数值属性的可用值上限（或_界限_）为一个具体的值。

我们可以将 authorized_charges_per_email_hourly 作为示例看一看，它代表您的账户上过去一小时内来自该邮件地址已被授权的收款的个数。为了举例说明，我们假如它的界限为 5。对于该邮件地址 jenny.rosen@example.com 过去一小时内的第一笔收款尝试，计数器的值为 0。同一小时内后续收款尝试使计数器的值逐渐增加。而当授权来自 jenny.rosen@example.com 的第 6 笔收款尝试时，计数器停止增加，并保持为 5，尽管过去一小时内实际尝试次数已达到 6。

如果试图将计数器的值增加到上限以上，我们将旧值排除在外，并改用新值。例如，假如一个计数器的上限为 3，它被填写 3 次收款。将计时器可视化的一个方式是，维护一个表示收款到达时间的时间戳列表：例如 [10, 20, 30]。如果一笔收款在 50 此时间到达，则计数器的读数就是 [20, 30, 50]。

布尔属性

布尔属性表示某个特定属性是否为 true。与字串和数字型属性不同，布尔属性没有运算符和值。您可以利用布尔属性阻止用一次性邮件地址进行的付款，或将用匿名 IP 地址进行的付款放入审核。

授权后属性

授权后属性（例如 :cvc_check:, :address_zip_check:, or :address_line1_check:）需要 Stripe 在授权过程中与发卡行交换数据。发卡行会根据他们存档的信息验证这些数据，并检查是否匹配。使用授权后属性的规则在不使用授权后属性的规则之后执行。（这不会影响是否阻止某笔收款，但可能会影响阻止收款的具体规则。）

如果您在某个规则中使用授权后属性，则您客户的对账单会暂时性地显示一笔授权，即使收款最终被阻止——授权一般会在几天后消失。

地址 (AVS) 和 CVC 属性有五个可能的值：

一些规则示例：

• Block if :address_line1_check: = 'fail'
• Block if :cvc_check: = 'fail'
• Block if :address_zip_check: in ('fail', 'not_provided')

对某些规则严格要求 pass 可能会过于严格。例如，钱包通常不提供 CVC，因为它们存储的是令牌化的银行卡信息。因此，CVC 检查，比如 3DS 验证检查，通常不适用于 Apple Pay 等支付方式。Stripe 建议使用 Radar 的内置规则，该规则考虑了这些罕见情况。

支持的属性

参考所有支持的属性列表，了解可应用于规则定义的属性的完整列表。

转换金额

使用 amount_in_xyz 时，Stripe 会在检查金额是否符合您选择的标准时，自动确定任何付款的转换金额。例如，如果您用 amount_in_usd 创建了一个规则来阻止所有大于 1000 美元的付款，那么在遇到另一币种的付款（例如，900 英镑）时，如果兑换后的等效金额超过 1000 美元，则阻止这笔付款。

实际操作中“考虑了 2020 年以来的付款”

某些规则属性的描述中包含短语“考虑了从 2020 年开始的付款”，这意味着该规则将 2019 年最后一次与贵商家进行交易的卡视为与新卡相同。这可能导致一些反直觉的行为，因此需要考虑其在您的业务和规则中的应用。例如，如果您创建了一条规则来阻止新卡的大额付款，那么可能会阻止一位自 2019 年以来没有进行过购买的优质客户。

“该属性仅包含过去<week, year>中与您的账户交互的真实模式下的 Customer 对象。该数据最多每 72 小时更新一次。”实践中

某些规则属性的描述包括这样的句子：“该属性仅包含过去<week, year>中与您的账户交互的真实模式下的 Customer 对象。该数据最多每 72 小时更新一次。”这意味着这些计数中包含了过去一周、或一年中在您的账户上创建、收款或更新的真实模式下的 Customer 对象。但是，计数不会立即更新，可能需要 72 小时才能在系统中传送，但这些计数器通常会在 72 小时内更新。

运算符

条件的运算符表示付款的属性和您提供的值之间的比较。可以使用不同的运算符，取决于使用中的属性的类型。

列表

您可以通过列表在您的规则中引用一组数值。在规则中引用的所有列表的别名都应以 @ 开头。要构建一个引用列表的规则，请遵循以下结构：

{action} [attribute] in [list]

例如，假设您想阻止一个银行卡国家列表。可以用 OR 子句来编写规则：

Block if :card_country: = 'CA' OR :card_country: = 'DE' OR :card_country: = 'AE'

您也可以用内联列表来编写规则：

Block if :card_country: IN ('CA', 'DE', 'AE')

您还可以创建想阻止的银行卡国家列表，名为 card_countries_to_block。然后将您选择的国家添加到该列表并在规则中引用该列表：

Block if :card_country: in @card_countries_to_block

在某个规则中引用一个列表后，您可以在一个地方编辑大量项目，不用维持很多单个的规则。

缺少的属性

典型的规则条件要引用每个付款上设置的属性，例如 :card_country:（每笔基于卡的收款上都设置）或您每次都要付款请求中发送的元数据属性。一些情况下，某个属性可能会丢失，例如：

• 您的网站上有不同的结账流程，其中某些未收集客户的邮件地址

• 您是最近才开始使用 Stripe.js，因此新的付款上会有 :ip_country:，但以往的付款上却没有（预览规则时我们搜索的付款）。

• 对于您的某些付款，您的集成中的某个漏洞未能设置预期的元数据密钥

规则条件如何评估缺少的属性

考虑规则 Block if :email_domain: = 'definitelyfraud.com'。如果您不收集客户的邮件地址，那么 :email_domain: 属性不存在，因此规则条件与付款不匹配。

现在考虑规则 Review if :email_domain: != 'definitelysafe.com'。如果缺少 :email_domain: 属性，那么该规则_也_不匹配付款。可能看上去匹配，因为所有的值都是 'definitelysafe.com'。但是，这种情况下，我们将 != 'definitelysafe.com' 的意思理解为“该属性有一些不同于 'definitelysafe.com' 的值”，而它是缺少的属性不满足的。当使用 NOT 运算符时，缺少的属性信息也会被结转，因此在缺少 :email_domain: 属性时，规则 Review if NOT (:email_domain: = 'definitelysafe.com') 将以类似情况与付款不匹配。

当交易没有布尔属性时，布尔属性为 false 而不是缺失属性。例如，对于 ACH 和 SEPA 交易，:is_new_card_on_customer: 为 false，而不是缺失属性。

更一般地说：对照另一静态值或功能对比（例如，=、!=、>、<）缺少的功能时，始终会返回错误。对包含缺失功能的任何比较使用 NOT 运算符总是返回 false。

用 is_missing 函数显示地处理

如果想显示的检查是否存在某个属性或元数据属性，可使用 is_missing 函数。为该函数提供可能丢失的属性或元数据键。

例如，可以书写一个规则来匹配您不能访问客户邮件地址的所有付款：

• Review if is_missing(:email_domain:)

或者，也可以书写一个规则来匹配具有特定元数据属性集的所有付款：

• Review if !(is_missing(::foo::))

还可以使用在 OR 或 AND 连词中使用 is_missing 函数：

• Review if is_missing(:email_domain:) OR :email_domain: IN ('yopmail.net', 'yandex.ru')

复杂条件

可以用运算符 AND、OR 及 NOT 组合基本条件来构建复杂的条件。还可以使用它们的符号等值：分别为 &&、|| 和 !。

与 C 语言、Python 和 SQL 等编程语言类似，Stripe 支持标准运算符_优先级_（运算符的顺序）。例如，复杂条件：

{condition_X} OR NOT {condition_Y} AND {condition_Z}

解释为：

{condition_X} OR ((NOT {condition_Y}) AND {condition_Z})

也支持用圆括号在复杂条件中使用子条件分组。例如，您可以修改前面的示例，以显示地更改子谓词的评估顺序。

({condition_X} OR (NOT {condition_Y})) AND {condition_Z}

{condition_X} OR NOT ({condition_Y} AND {condition_Z})

通过在不同的位置使用括号，每一个复杂的条件都会导致不同的结果。

有效条件

以下条件为正确使用属性和支持的运算符的示例：

• :card_brand: = 'amex'
• :card_country: != 'US'
• :amount_in_usd: >= 1000.00
• :is_anonymous_ip:

无效条件

创建规则时，如果您尝试使用一个无效的条件，则 Radar 会提供反馈。作为参考，以下是无效条件的示例，其中不支持所使用的属性或运算符的值：

• :risk_level: < 'highest'（字串值只能使用运算符 = 或 !=）
• :ip_country: = 'Canada'（国家必须用两字母短代码表示）
• :amount_in_usd: >= 'one thousand dollars'（数字值必须用数字表示）
• :is_anonymous_ip: = 'true'（布尔属性不与运算符或值一起使用）

速率规则

许多受支持的属性包含不同时间范围的不变量（例如 total_charges_per_email_daily 中的 daily）。这些被称为速度规则。

Stripe 使用时间段增量来计算属性。增量长度因属性间隔而异。这意味着任何属性的速率都可能包含该间隔加一个时间段内发生的数据。例如，当前交易的每小时属性间隔可能是 3900 秒（1 小时 5 分钟），因为该间隔使用的是五分钟时间段。

这些属性的定义如下：

• hourly 高达 3900 秒（5 分钟时间段）
• daily 高达 90000 秒（1 小时时间段）
• weekly 高达 608400 秒（1 小时时间段）
• yearly 高达 31622400 秒（1 天时间段）
• all_time 包含 5 年的数据，速率高达 31622400 秒（1 天时间段）

这些属性的一个常见用例是减少银行卡测试或枚举攻击场景，如 Radar 101 指南中所述。