规则参考
创建规则前,您需要理解其处理方式以及您能够用哪些付款属性来设置评估标准。Stripe 的机器学习欺诈系统可为您阻止很多欺诈性付款,但您也可以用支持的属性为您的业务量身设置规则。
规则处理和排序
规则所采取的操作决定着其处理顺序。Radar 会依据您创建的规则来评估每笔付款,这些规则的优先顺序如下:
- 要求 3DS 验证:这些规则在使用 Payment Intents API 或 Checkout 时会_要求_发卡行支持 3DS 验证。Radar 会先于任何阻止、审核或允许规则来评估这些付款。
- 允许:这些规则_允许_付款被处理。落入允许规则的付款不会根据阻止或审核规则来评估。
- 阻止:这些规则会_阻止_付款并将其拒绝。被阻止的付款不会再根据审核规则来评估。
- 审核:这些规则允许处理付款,但之后会将其送入_审核_。
如果一笔付款匹配某个规则的标准,Radar 将采取适当的操作,不再进一步评估这笔付款。如果一笔付款匹配某个允许规则,则正常处理——之后不再评估阻止或审核规则,即使付款也满足它们的标准。可以是下边这样一组规则:
- **允许**小于
$10
的付款 - **允许**美国进行的且风险等级为
normal
的付款 - **阻止**风险等级为
high
的付款 - 阻止
greater than $1,000
的付款 - **审核**用
outside the US
签发的卡进行的付款
使用上述规则的话,小于 10 美元的所有付款都会被处理,无论其风险等级如何,也无论卡是哪里签发的。这是因为第一个规则会允许付款通过,因此不再评估其之后的规则。与之类似,在美国进行的、风险水平正常的 1500 美元以上的付款也将被允许,尽管该规则会阻止 1000 美元以上的付款。这是因为列表中的第二条规则,即允许来自美国的风险水平正常的付款。触发了某个特定规则时,不再评估其之后的规则。
规则结构
规则结构分为两部分——一个是它应采取的_操作_,一个是要评估的_条件_:
{action} if {condition}
它们一起被称为_谓词_。具体来说,一个阻止超过 1000 美元的所有付款的规则大致是这样:
Block if :amount_in_usd: > 1000.00
- _操作_是
Block
- _条件_是
:amount_in_usd: > 1000.00
操作
对于满足某个标准的付款,它可执行四项操作之一,按照这个特定顺序执行。
要求 3DS 验证
当与 Payment Intents API 一起使用时,此规则确定 Stripe 是否要求发卡行尝试 3DS 验证。单独请求 3DS 验证并不能屏蔽所有可能的 3DS 验证结果。无论此规则是否匹配,我们事后都会评估允许、阻止和审核规则。
允许
这个规则决定着何时始终阻止满足特定标准的付款,无论 Stripe 的评估结果如何,也无论其是否匹配其他规则。如果一笔付款匹配某个允许规则的标准,Stripe 会正常处理它,不再评估其之后的规则。即使 Stripe 处理了一笔付款,发卡行仍有可能会拒绝它。
阻止
阻止规则会指定 Stripe 应始终阻止的付款。如果一笔付款匹配某个阻止规则的标准,Stripe 会拒绝它,不再评估其之后的规则。
审核
您可能想允许特定类型的付款,但同时可以选择更进一步来研究一下。通过审核规则,您可以将付款放入审核。这对于非常见模式的付款尤其有用,例如金额较大或您很少向付款来自的国家发货。Stripe 仍会处理这些付款并对客户扣款,但您有额外的机会来审核订单并检查欺诈信号。
条件
如果付款与某个规则的条件匹配,则采取相应的操作。一个基本条件本身由三个部分构成:
[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_value]
:: [operator]
例如,假设我们的一些付款具有元数据字段中存储的以下键值数据:
Metadata Name | Metadata Value |
---|---|
Customer Age | 22 |
Item ID | 5A381D |
Category ID | groceries |
可编写一个规则,将匹配以下标准的付款放入审核。
Review if < 30
还可以用元数据属性和本文档中提及的其他支持的属性用来编写规则。例如,可编写一个规则,仅当 Item ID
匹配 5A381D
且付款金额大于 1000 美元才将付款放入审核。
Review if =
'5A381D'
and :amount_in_usd: > 1000
元数据属性还支持 IN
运算符来匹配多个数值。例如,可编写一个规则,在 Category ID
为杂货店、电子产品或服饰时将付款放入审核。
Review if IN (
'groceries'
, 'electronics'
, 'clothing'
)
您可以将 INCLUDES
运算符与元数据属性和其他字符串属性的规则结合使用来匹配子串。例如,您可以编写一个规则,如果 Item ID
包含字符串 A381
,则将付款放入审核。该字符串将匹配 A381、5A381D、A381D、5A381 等。
Review if INCLUDES
'A381'
注意
用作字串使用时,元数据属性区分大小写。一定保证在规则中指定的元数据的值与付款中关联的完全相同。
Customer 和 Destination 对象上的元数据
您也可以访问 Customer 和 Destination 对象上的元数据(如果它们被用于特定的付款)。这些属性使用以下结构:
::[customer|destination]:[metadata_value]
:: [operator]
例如,假设您有个客户的元数据如下:
Metadata Name | Metadata Value |
---|---|
Trusted | true |
如果客户的 Trusted
元数据字段为 true
,则您可以写一个规则始终允许付款。
Allow if =
'true'
或者,如果您的目的地有下列元数据时:
Metadata Name | Metadata Value |
---|---|
Category | new |
如果目的地的 Category
元数据字段为 new
,则您可以写一个规则将付款放入审核。
Review if =
'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:
或 :address_line1_check:
)要求 Stripe 与发卡行交换数据,作为授权过程的一部分。发卡行对照其保存的持卡人的信息验证该数据并检查是否匹配。使用授权后属性的规则在不使用授权后属性的规则之后执行。(这不会影响收款是否被阻止,但可能影响由哪个规则阻止收款。)
如果您在某个规则中使用授权后属性,则您客户的对账单会暂时性地显示一笔授权,即使收款最终被阻止——授权一般会在几天后消失。
Attribute value | Explanation |
---|---|
pass | 提供的数据正确。 |
fail | 提供的数据不正确。 |
unavailable | 客户的发卡行将不检查提供的数据。并非所有发卡行或国家都支持国家地址验证。 |
unchecked | 提供了数据,但尚未检查。客户的发卡行将最终检查提供的数据。 |
not_provided | 数据未提供给 Stripe。 |
一些规则示例:
Block if :address_line1_check: =
'fail'
Block if :cvc_check: !=
'pass'
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 小时内更新。
运算符
条件的运算符表示付款的属性和您提供的值之间的比较。可以使用不同的运算符,取决于使用中的属性的类型。
运算符 | 字符串 | 元数据 | 国家/地区 | 州 | 数字 | 描述 | 示例 |
---|---|---|---|---|---|---|---|
= | ✔︎ | ✔︎ | ✔︎ | ✔︎ | ✔︎ | 等于 | :card_country: = |
!= | ✔︎ | ✔︎ | ✔︎ | ✔︎ | ✔︎ | 不等于 | :card_funding: != |
< | ✔︎ | 小于 | :amount_in_gbp: < 10.00 | ||||
> | ✔︎ | 大于 | :amount_in_usd: > 500.00 | ||||
<= | ︎ | ✔︎ | 小于或等于 | :amount_in_eur: <= 100.00 | |||
>= | ✔︎ | 大于或等于 | :amount_in_cad: >= 10.00 | ||||
IN | ✔ | ✔︎ | ✔ | ✔︎ | ✔︎ | 在组中 | :card_country: IN ( |
INCLUDES | ✔ | ✔︎ | ✔ | ✔ | 包含字串 | :ip_address: INCLUDES | |
LIKE | ✔ | ✔︎ | ✔ | ✔ | 匹配给定的模式。用通配符 % 匹配零或任意个数的字母、数字或符号。 | :email: LIKE |
列表
您可以通过列表在您的规则中引用一组数值。在规则中引用的所有列表的别名都应以 @
开头。要构建一个引用列表的规则,遵循以下结构:
{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'
更一般地说:对照另一静态值或功能对比(例如,=
、!=
、>
、<
)缺少的功能时,始终会返回错误。
用 is_missing
函数显示地处理
如果想显示的检查是否存在某个属性或元数据属性,可使用 is_missing
函数。为该函数提供可能缺少的属性或元数据属性。
例如,可以书写一个规则来匹配您不能访问客户邮件地址的所有付款:
Review if is_missing(:email_domain:)
或者,也可以书写一个规则来匹配具有特定元数据属性集的所有付款:
Review if !(is_missing( ))
还可以使用在 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
)。这些被称为速度规则。
这些属性是作为滚动窗口计算的,基于固定的秒数,而不非基于日历。例如,daily
意味着规则属性中两次收款之间的时间间隔必须最大为 24 小时或 86400 秒才能匹配。
这些属性的定义如下:
hourly
为 3600 秒daily
为 86400 秒weekly
为 604800 秒yearly
为 31536000 秒
这些属性的一个常见用例是减少银行卡测试或枚举攻击场景,如 Radar 101 指南中所述。