Stripe 的默认规则利用机器学习来预测和阻止大量的欺诈性付款。对于需要更多控制能力来管理审核、允许或阻止哪些付款的商家,规则是定制您的欺诈保护的强大工具。
本指南涵盖了与 Radar 规则相关的各种主题,包括您可以使用的 100 多种 Radar 规则,以及关于回溯测试、规则编写等方面的最佳做法。
让我们开始吧。
规则顺序和等级的重要性
规则在您的 Radar 页面中的排列顺序非常重要。根据您创建的规则评估每笔付款,并按以下顺序执行:
- 请求 3DS 验证:该规则与 Payment Intents API 或 Checkout 一起使用时会请求 3DS 验证。即使匹配这个规则,仍会评估允许、阻止和审核规则。
- 允许: 这些规则允许付款被处理。应小心实施允许规则,因为它们会覆盖除 3DS 验证规则之外的其他所有规则,包括 Stripe 的机器学习模型,使用时应最为谨慎。只有处理金额超过 100,000 美元的商家才能编写允许规则。
- 阻止: 这些规则会阻止付款并将其拒绝。如果付款被拒绝,则不会根据任何审核规则进行评估。
- 审核:这些付款仍在处理中,客户已被扣款,但这些付款已被标记,如果愿意,可以重新查看。
为了将此付诸实践,我们来看看下面的规则示例。低于 10 美元的所有付款都会被处理。这是因为第一个规则会允许付款通过,因此不再评估其之后的规则。同样,根据这些规则,在美国境内进行的具有正常风险的 1500 美元的付款也会被允许,尽管该规则禁止超过 1000 美元的付款。这是因为列表中的第二条规则,即允许来自美国的风险水平正常的付款。触发了某个特定规则时,不再评估其之后的规则。
允许低于
$10
的付款允许美国境内风险等级
normal
的付款阻止风险等级
high
的付款阻止超过
greater than $1,000
的付款审核用
outside the US
的卡进行付款
规则语言备忘单
规则类似于 SQL,根据您用来创建规则的数据类型,可以使用不同的运算符。这是一张备忘单。
运算符
|
字符串
|
元数据
|
国家/地区
|
数字
|
描述
|
示例
|
---|---|---|---|---|---|---|
=
|
等于 |
|
||||
!=
|
不等于 |
|
||||
<
|
小于 |
|
||||
>
|
大于 |
|
||||
<=
|
小于或等于 |
|
||||
>=
|
大于或等于 |
|
||||
IN
|
在组中 |
|
||||
INCLUDES
|
包含字串 |
|
||||
LIKE
|
匹配给定的模式 |
|
如果想明确检查某个属性或元数据属性是否存在,那么请勿使用 !=
运算符,而应使用 is_missing
函数。为该函数提供可能缺少的属性或元数据属性。例如,可以书写一个规则来匹配您不能访问客户邮件地址的所有付款:
Review if is_missing(:email_domain:)
或者,可以编写一个规则来匹配“不”缺少客户的电子邮件地址的所有付款:
Review if !(is_missing(:email_domain:))
使用自然语言编写规则
如果您想更轻松地编写规则,或者不确定使用哪些属性来解决特定的欺诈场景,AI 驱动的 Radar 助手会将您的自然语言提示转换为 Rdar 语法中的规则。您还可以直接从 Radar 助手对规则进行回溯测试,这样就可以在实施规则之前查看它的历史表现。
![](https://images.ctfassets.net/fzn2n1nzq965/2E0RvOCw4IyVcmD7Pqcdv0/fff500c887847f47cc2287c196dbc182/Screenshot_2024-04-18_at_3.11.00_PM.png?w=1611&q=80)
常用 Radar 规则
下方为基于不同目标的常用 Radar 规则的非详尽列表。
有助于防止银行卡测试或信用卡套现的规则
|
该规则对银行卡测试很有帮助。如果一个 IP 地址在您的账户上被多次成功授权,它将阻止收款。 |
---|---|
|
如果您想更积极地防止银行卡测试,请将此规则与 |
|
该规则对信用卡套现很有帮助。如果您的账户在最近一小时内对某个卡号多次成功授权,它将阻止收款。 |
|
如果您想更积极地防止信用卡套现,请将此规则与 |
|
务必在您的结账表单中收集邮政编码以使用此规则。如果发卡行无法验证所提供的邮编是否与他们的保存的银行卡信息相符,则该规则将阻止收款。 |
|
务必在您的结账表单中收集 CVC以使用此规则。如果发卡行无法验证所提供的 CVC(或 CVV)是否与他们的保存的银行卡信息相符,则该规则将阻止收款。 |
有助于防止已知风险 SKU 欺诈的规则
该规则要求提供元数据或传递 SKU 信息作为收款描述。这些付款仍在处理中,客户已被扣款,但它们已被标记,以便您可以再次查看。
|
假设您是一家杂货店,您将向我们发送 SKU 类别的元数据。您已经注意到,包含标有 SKU 类别的 'personal hygiene' 或 'baby formula' 的商品的订单往往更具风险。此规则会将带有这些项的任何订单放在您的 Stripe 管理平台的手动审核列表中,以便您可以再次查看。请注意,除非您手动取消订单,否则仍会处理这些付款并向客户收款。 |
---|---|
|
假设您销售两种产品('Trial class' 和 '10 class package'),并将产品名称作为收款说明发送给 Stripe。此规则会将具体收款描述为 'Trial class' 的任何订单放在您的 Stripe 管理平台的手动审核列表中,以便您可以再次查看。请注意,除非您手动取消订单,否则仍会处理这些付款并向客户收款。 |
有助于防止胡乱试用预付卡的规则
|
假设您是一家提供在家试用的零售商,并注意到使用预付卡的欺诈行为激增,然后您无法收取来自预付卡的付费。该规则将阻止任何未使用信用卡或借记卡支付的订单。 |
---|
分析您的欺诈行为以指导规则的创建
欺诈审核
为了制定最有效的规则,您必须深入了解您账户上的欺诈活动。描述当前不同类型的欺诈手段非常重要。需思考的一些问题:
账户是否使用新的电子邮件地址和持卡人姓名注册并立即进行欺诈性购买?
欺诈者是否访问过期账户并以异常高的金额进行购买?
欺诈是否倾向于特定的卡组织或发卡国家?
是否有高速率欺诈发生,即在短时间内通过同一卡、电子邮件地址或 IP 地址进行多次尝试?
![](https://images.ctfassets.net/fzn2n1nzq965/1z2Ibaq51UGdJelWS8WtYq/6e7b28e6d2f4a12ac7df62e9139cce49/Related_payments.png?w=1976&q=80)
仔细回顾上面截图中的高速率欺诈,利用 authorized_charges_per_card_number_hourly
或 authorized_charges_per_ip_address_hourly
的规则可能会解决这一欺诈方式。
更好理解欺诈的推动因素
欺诈洞察可帮助您快速识别和解决欺诈原因,而无需手动分析交易数据。管理平台中的洞察选项卡显示与欺诈交易相关的主要属性。在这里,您可以添加一个规则,直接从“洞察”选项卡中处理该属性。
创建规则时的三类属性
第 1 类
授权后属性:任何人都可使用这些属性。使用这些属性时,需要在授权后属性前后使用冒号,如:cvc_check:。
属性
|
描述
|
---|---|
|
发卡行根据保存的持卡人信息匹配提供的账单地址的第一行(通常为街道名称和编号)时进行的一项检查。 |
|
发卡行根据保存的持卡人信息匹配提供的邮编时进行的一项检查。 |
|
发卡行根据保存的持卡人信息匹配提供的 CVC(有时也说 CVV)时进行的一项检查。 |
可能的值
|
描述
|
---|---|
|
提供的数据正确。 |
|
提供的数据不正确。 |
|
客户的发卡行不会检查提供的数据。并非所有发卡行或国家都支持国家地址验证。 |
|
数据已经提供,但尚未核对。客户的发卡行将最终检查提供的数据。 |
|
数据未提供给 Stripe。 |
这些值区分大小写。 |
以下是如何使用授权后属性的示例:
Block if :address_line1_check: != 'pass'
有了这条规则后,如果没有通过发卡行的检查,无法将所提供的账单地址的第一行与持卡人档案中的信息进行匹配,那么任何收款都将被阻止。这意味着,如果这项检查“不可用”,如果该数据“未经发卡行检查”,或者如果发卡行“not_provided”,则付款将被阻止。
第 2 类
标准属性:任何人都可使用这些属性。您需要在标准属性前后使用冒号,例如 :card_bin: 我们将标准属性分为四类:
- 基于频率的属性——有助于防止银行卡测试或信用卡套现
- 基于银行卡详情的属性
- 基于付款详情的属性
- 基于客户详情的属性
一些属性需要字符串形式的值,而另一些属性需要数字形式的值。我们为每个属性提供了一个示例来阐明这一点。如果属性需要像 :card_bin: 这样的字符串,那么在示例中您会看到这个数字加上了 ‘ ’。例如,:card_bin: = ‘424242’,但它要求一个号码,不会有 ‘ ’ like :amount_in_usd: > 250。
基于频率的属性
基于频率的属性有四类,在防止盗卡欺诈、银行卡测试和信用卡套现方面特别有用。
1.授权:基于发卡行的授权
2.收款:基于收款
3.拒付:基于发卡行的拒付
4.阻止:基于 Radar 机器学习执行的阻止操作
还有基于收款结果的属性,包括授权(基于发卡行的成功授权)、收款(基于收款尝试)、拒付(基于发卡行的拒付)、争议(之前的交易被以欺诈之名提出争议)和阻止(基于 Radar 机器学习执行的阻止操作)。结果与客户详情(电子邮件、IP 地址、姓名或客户 ID)结合在一起构成一个属性。
此外,您可以将客户详情(电子邮件、姓名)的频率与交易中使用的卡或 IP 地址结合起来。换句话说,频率规则有两种类型:
1.基于收款结果(例如,authorized_charges_per_email_hourly, blocked_charges_per_email_hourly)。其中,结果为成功授权,收款尝试、拒绝、争议、阻止
2.基于客户信息与卡或 IP 之间的联系(例如,name_count_for_card_weekly, email_count_for_ip_hourly)
频率规则不包括您当前正在处理的付款。例如,authorized_charges_per_email_hourly
表示前一小时内对某个电子邮件地址成功收款的次数。因此,对于某个邮件地址在具体某一小时内的第一次收款尝试,authorized_charges_per_email_hourly
的值为 0。如果第一次成功,那么同一小时内对这个邮件地址的第二次收款尝试,其值为 1,以此类推。
属性
|
描述
|
---|---|
|
您的账户中这张卡的收款被成功授权的笔数。考虑了 2020 年以来的付款。(注意:上限 <= 25)。 |
|
您的账户过去一周内这张卡的收款被成功授权的笔数。(注意:上限 <= 25)。 |
|
您的账户过去一天内这张卡的收款被成功授权的笔数。(注意:上限 <= 25)。 |
|
您的账户过去一小时内这张卡的收款被成功授权的笔数。(注意:上限 <= 25)。 |
|
您的账户中来自该邮件地址的收款被成功授权的笔数。考虑了 2020 年以来的付款。(注意:上限 <= 25)。 |
|
您的账户过去一周内来自该邮件地址的收款被成功授权的笔数。(注意:上限 <= 25)。 |
|
您的账户过去一天内来自该邮件地址的收款被成功授权的笔数。(注意:上限 <= 25)。 |
|
您的账户过去一小时内来自该邮件地址的收款被成功授权的笔数。(注意:上限 <= 25)。 |
|
您的账户中来自该 IP 地址的收款被成功授权的笔数。考虑了 2020 年以来的付款。(注意:上限 <= 25)。 |
|
您的账户中过去一周内来自该 IP 地址的收款被成功授权的笔数。(注意:上限 <= 25)。 |
|
您的账户中过去一天内来自该 IP 地址的收款被成功授权的笔数。(注意:上限 <= 25)。 |
|
您的账户中过去一小时内来自该 IP 地址的收款被成功授权的笔数。(注意:上限 <= 25)。 |
|
您的账户在最近 24 小时内对某个客户成功授权的次数。(这个计数中不包含当前评估中的付款。) |
|
您的账户在最近一小时内对某个客户成功授权的次数。(这个计数中不包含当前评估中的付款。) |
|
Stripe 的机器学习模型在最近 24 小时内拒绝的您账户中的某个卡号的次数。这个计数中不包含当前评估中的付款(例如,4)。 |
|
Stripe 的机器学习模型在最近一小时内拒绝的您账户中的某个卡号的次数。这个计数中不包含当前评估中的付款(例如,4)。 |
|
Stripe 的机器学习模型在最近 24 小时内拒绝的您账户中的某个客户的次数。这个计数中不包含当前评估中的付款(例如,4)。 |
|
Stripe 的机器学习模型在最近一小时内拒绝的您账户中的某个客户的次数。这个计数中不包含当前评估中的付款(例如,4)。 |
|
Stripe 的机器学习模型在最近 24 小时内拒绝的您账户中的某个 IP 地址的次数。这个计数中不包含当前评估中的付款(例如,4)。 |
|
Stripe 的机器学习模型在最近一小时内拒绝的您账户中的某个 IP 地址的次数。这个计数中不包含当前评估中的付款(例如,4)。 |
|
过去 24 小时内在您的账户上尝试用某个卡扣款的次数。这个计数中不包含当前评估中的付款(例如,4)。 |
|
过去 1 小时内在您的账户上尝试用某个卡扣款的次数。这个计数中不包含当前评估中的付款(例如,4)。 |
|
您的账户在最近 24 小时内尝试对某个客户扣款的次数。这个计数中不包含当前评估中的付款(例如,4)。 |
|
您的账户在最近 1 小时内尝试对某个客户扣款的次数。这个计数中不包含当前评估中的付款(例如,4)。 |
|
您的账户在最近 24 小时内尝试对某个 IP 地址扣款的次数。这个计数中不包含当前评估中的付款(例如,4)。 |
|
您的账户在最近 1 小时内尝试对某个 IP 地址扣款的次数。这个计数中不包含当前评估中的付款(例如,4)。 |
|
发卡行在最近 24 小时内拒绝的您账户中的某个卡号的次数。这个计数中不包含当前评估中的付款(例如,4)。 |
|
发卡行在最近一小时内拒绝的您账户中的某个卡号的次数。这个计数中不包含当前评估中的付款(例如,4)。 |
|
发卡行在最近 24 小时内拒绝的您账户中的某个客户的次数。这个计数中不包含当前评估中的付款(例如,4)。 |
|
发卡行在最近一小时内拒绝的您账户中的某个客户的次数。这个计数中不包含当前评估中的付款(例如,4)。 |
|
发卡行在最近 24 小时内拒绝的您账户中的某个 IP 地址的次数。这个计数中不包含当前评估中的付款(例如,4)。 |
|
发卡行在最近一小时内拒绝的您账户中的某个 IP 地址的次数。这个计数中不包含当前评估中的付款(例如,4)。 |
|
您的账户拒绝的来自这个邮件地址的收款的笔数。考虑了 2020 年以来的付款。(注意:上限 <= 25)。 |
|
您的账户过去一周内拒绝的来自这个邮件地址的收款的笔数。(注意:上限 <= 25)。 |
|
您的账户过去一天内拒绝的来自这个邮件地址的收款的笔数。(注意:上限 <= 25)。 |
|
您的账户过去一小时内拒绝的来自这个邮件地址的收款的笔数。(注意:上限 <= 25)。 |
|
您的账户中与来自这个 IP 地址的收款关联的欺诈性争议的个数。考虑了 2020 年以来的付款。(注意:上限 <= 25)。 |
|
您的账户中过去一周内与来自这个 IP 地址的收款关联的欺诈性争议的个数。(注意:上限 <= 25)。 |
|
您的账户中过去一天内与来自这个 IP 地址的收款关联的欺诈性争议的个数。(注意:上限 <= 25)。 |
|
您的账户中过去一小时内与来自这个 IP 地址的收款关联的欺诈性争议的个数。(注意:上限 <= 25)。 |
|
您的账户中的交易与这张卡关联的邮件地址的个数。考虑了 2020 年以来的付款。(注意:上限 <= 25)。 |
|
您的账户过去一周内的交易与这张卡关联的邮件地址的个数。(注意:上限 <= 25)。 |
|
您的账户过去一天内的交易与这张卡关联的邮件地址的个数。(注意:上限 <= 25)。 |
|
您的账户过去一小时内的交易与这张卡关联的邮件地址的个数。(注意:上限 <= 25)。 |
|
您的账户中的交易与这个 IP 地址关联的邮件地址的个数。考虑了 2020 年以来的付款。(注意:上限 <= 25)。 |
|
您的账户中过去一周内的交易与这个 IP 地址关联的邮件地址的个数。(注意:上限 <= 25)。 |
|
您的账户中过去一天内的交易与这个 IP 地址关联的邮件地址的个数。(注意:上限 <= 25)。 |
|
您的账户中过去一小时内的交易与这个 IP 地址关联的邮件地址的个数。(注意:上限 <= 25)。 |
|
您的账户中的交易与这张卡关联的名字的个数。考虑了 2020 年以来的付款。(注意:上限 <= 25)。 |
|
您的账户过去一周内的交易与这张卡关联的名字的个数。(注意:上限 <= 25)。 |
|
您的账户过去一天内的交易与这张卡关联的名字的个数。(注意:上限 <= 25)。 |
|
您的账户过去一小时内的交易与这张卡关联的名字的个数。(注意:上限 <= 25)。 |
|
您的账户从这张卡收款的总笔数。考虑了 2020 年以来的付款。(注意:上限 <= 25)。 |
|
您的账户过去一周内从这张卡收款的总笔数。(注意:上限 <= 25)。 |
|
您的账户过去一天内从这张卡收款的总笔数。(注意:上限 <= 25)。 |
|
您的账户过去一小时内从这张卡收款的总笔数。(注意:上限 <= 25)。 |
|
您的账户从这个邮件地址收款的总笔数。考虑了 2020 年以来的付款。(注意:上限 <= 25)。 |
|
您的账户过去一周内从这个邮件地址收款的总笔数。(注意:上限 <= 25)。 |
|
您的账户过去一天内从这个邮件地址收款的总笔数。(注意:上限 <= 25)。 |
|
您的账户过去一小时内从这个邮件地址收款的总笔数。(注意:上限 <= 25)。 |
|
您的账户从这个 IP 地址收款的总笔数。考虑了 2020 年以来的付款。(注意:上限 <= 25)。 |
|
您的账户过去一周内从这个 IP 地址收款的总笔数。(注意:上限 <= 25)。 |
|
您的账户过去一天内从这个 IP 地址收款的总笔数。(注意:上限 <= 25)。 |
|
您的账户过去一小时内从这个 IP 地址收款的总笔数。(注意:上限 <= 25)。 |
基于银行卡详情的属性
属性
|
描述
|
---|---|
|
用来付款的卡的银行识别码 (BIN)。这是卡号的前六位数字(例如,'424242')。 |
|
用来付款的卡的品牌。支持的值为:'amex' (American Express)、'visa' (Visa)、'mc' (Mastercard)、'dscvr' (Discover)、'diners' (Diners Club)、'interac' (Interac)、'jcb' (JCB) 和 'cup'(中国银联)。 |
|
发卡行所在国家对应的两字母代码(例如,'US')。有关国家代码的列表,请查看此页。要指定多个国家/地区,使用 IN 运算符。 |
|
用来付款的卡的指纹。银行卡指纹是特定卡号的唯一标识符,您可以前往“付款”并在“支付方式”部分查看付款来找到这个号码(例如, 'VfE3rx3VlaQhS8Lp')。区分大小写。 |
|
卡是预付卡、借记卡还是信用卡。支持的值为:'credit'、'debit'、'prepaid'、'unknown'。 |
|
对用来付款的银行卡的 3DS 验证的支持等级。支持的值为:'required'、'recommended'、'optional’ 和 'not_supported'。 |
基于付款详情的属性
属性
|
描述
|
---|---|
|
兑换为由 xyz 指定货币后的付款金额(例如, |
|
对您账户上的银行卡尝试过的交易的平均金额 (USD)。考虑了 2020 年以来的付款。 |
|
使您账户上的银行卡成功授权的交易的平均金额 (USD)。考虑了 2020 年以来的付款。 |
|
给定付款的风险等级,由 Stripe 确定。支持的值为:‘normal’、‘elevated’、‘highest’ 和 ‘not_assessed’。 |
|
给定付款的风险评分,由 Stripe 确定(例如,> 50)。这些值的范围为 0(风险最低)至 100(风险最高)。65 分或以上对应的风险级别为‘风险升高’,75 分或以上对应的级别为‘最高’。 |
|
付款时提供的描述(例如,‘Class trial’)。 |
|
识别付款是否是经常性的——例如,来自订阅。(这是布尔值,因此当它为真时,您可以使用 |
|
指示直接的用户操作未触发 Stripe Billing 付款,或 PaymentIntent 确认中设置 |
|
用于存储支付信息的数字钱包的类型。支持的值为:‘android_pay’、‘amex_express_checkout’、‘apple_pay’、‘masterpass’、‘samsung_pay’、‘unknown’、’visa_checkout’、‘none’。 |
|
对于创建定向收款的 Connect 用户,指的是代表所创建收款的目标(例如,‘acct_19KCB9AlaaEw6AgR’)账户。区分大小写。 |
|
识别付款是否是通过 Checkout 处理的。该属性仅适用于通过新版本的 Checkout 处理的付款,不会通过旧版 Checkout 捕获付款。(这是布尔值,因此当它为真时,您可以使用 |
|
识别该付款是否成功完成了 3DS 验证的认证。认证可能是基于风险,也可能基于验证。(这是布尔值,因此当它为真时,您可以使用 |
|
识别付款是否使用了要求 3DS 验证的来源。(这是布尔值,因此当它为真时,您可以使用 |
|
如果这笔付款的欺诈责任已转移,则为 True。(这是布尔值,因此当它为真时,您可以使用 |
|
在您的账户上首次看到进行该笔付款的卡账后的秒数。考虑了 2020 年以来的付款。 |
|
自与您的账户上发生的付款有关的卡第一次成功授权后的秒数。考虑了 2020 年以来的付款。 |
|
您账户上这个卡未成功的交易(被阻止或拒绝)的总金额 (USD)。考虑了 2020 年以来的付款。 |
|
使您账户上的银行卡成功授权的交易的总金额 (USD)。考虑了 2020 年以来的付款。 |
基于客户详情的属性
属性
|
描述
|
---|---|
|
与付款来自的 IP 地址所属国家地域对应的两字母代码(例如,'GB')。有关国家代码的列表,请查看此页。要指定多个国家/地区,使用 IN 运算符。 |
|
支付来源的 IP 地址(例如,'192.168.0.1' 指定一个 IP 地址,或者如果您想广撒网,可以使用 |
|
识别付款来自的 IP 地址是否是一个已知的代理或 Tor 退出节点。该信息每日更新。(这是布尔值,因此当它为真时,您可以使用 |
|
识别付款来自的 IP 地址是否曾用于登录您的 Stripe 账户。这个属性可用作“是我的 IP 地址”的代理。(这是布尔值,因此当它为真时,您可以使用 |
|
付款时提供的邮件地址(例如,'user@example.com')。 |
|
付款时提供的邮件地址的域名(例如,'example.com')。 |
|
识别付款时提供的邮件地址是否是来自已知的一次性邮件地址提供商。Stripe 会维护一个与一次性邮件地址对应的域名列表来提供这个属性。(这是布尔值,因此当它为真时,您可以使用 |
|
完整提供的持卡人账单地址(例如,'510 Townsend, San Francisco, CA 94110')。 |
|
提供的持卡人账单地址的第一行——通常是街道名称和编号(例如,'510 Townsend')。 |
|
提供的持卡人账单地址的第二行——通常是公寓或单元号(例如,'Apt 5b')。 |
|
提供的持卡人账单地址所属的邮编 (ZIP)(例如,'94110')。 |
|
提供的持卡人账单地址所属的城市(例如,'San Francisco')。 |
|
提供的持卡人账单地址所属的州(例如,'CA')。 |
|
与提供的持卡人账单地址所属国家对应的两字母代码(例如,'US')。有关国家代码的列表,请查看此页。要指定多个国家/地区,使用 IN 运算符。 |
|
自付款时提供的电子邮件地址首次出现在您的帐户上开始所过的秒数。考虑了 2020 年以来的付款。 |
|
自付款时提供的电子邮件地址首次出现在您的整个 Stripe 账户上开始所过的秒数。考虑了 2020 年以来的付款。 |
|
提供的完整账单地址(例如,'510 Townsend, San Francisco, CA 94110')。 |
|
提供的收货地址的第一行——通常是街道名称和编号(例如,'510 Townsend')。 |
|
提供的收货地址的第二行——通常是公寓或单元号(例如,'Apt 5b')。 |
|
提供的收货地址的邮编 (ZIP)(例如,'94110')。 |
|
提供的收货地址所属的城市(例如,'San Francisco')。 |
|
提供的收货地址所属的州(例如,'CA')。 |
|
与所提供的收货地址所属国家对应的两字母代码(例如,'US')。有关国家代码的列表,请查看此页。要指定多个国家/地区,使用 IN 运算符。 |
以下是如何标准属性的方法示例:
Block if :card_country: IN ('CA', 'DE', 'AE')
有了这项规则,在加拿大、德国或阿拉伯联合酋长国发行的信用卡的任何收款都将被阻止。
第 3 类
元数据属性:这些属性将取决于您发送到 Stripe 的元数据。对于这些属性,您需要在标准属性前后使用双冒号,如 ::Customer Age::。元数据属性可以作为字符串或数字来操作。用作字串时,元数据属性要区分大小写。
元数据可以用来创建非常强大的规则,比如根据购买订单的 SKU 将收款放入人工审核,或者减小回头客的支付阻力。要了解如何传递更多元数据,请阅读本指南。
元数据属性以下列结构书写:
::[metadata attribute name]:: [operator] [metadata_value]
假设我们的一些付款具有元数据字段中存储的以下键值数据:
元数据名称
|
元数据名称
|
---|---|
Customer age
|
22 |
Item ID
|
5A381D |
Category ID
|
groceries |
您可以编写一个规则,将匹配以下标准的付款放入审核。
Review if ::Customer Age:: < 30
还可以将元数据属性与本文档中提及的其他支持属性结合使用来编写规则。例如,可编写一个规则,仅当 Item ID 匹配 5A381D 且付款金额大于 1,000 美元才将付款放入审核。
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]:[metadata attribute name]::[operator][metadata_value]:
假设您有一个具有以下元数据的客户:
元数据名称
|
元数据名称
|
---|---|
Trusted
|
true |
如果客户的 Trusted 元数据字段为 true,则您可以写一个规则始终允许付款。
Allow if ::customer:Trusted:: = 'true'
或者,如果您的目的地有下列元数据时:
元数据名称
|
元数据名称
|
---|---|
Category
|
new |
如果目的地的Category元数据字段为new,则您可以写一个规则将付款放入审核。
Review if ::destination:Category:: = 'new'
使用您的规则中保存的列表(例如,允许列表,阻止列表)
您可以通过以前创建的列表(例如,允许列表或阻止列表)在规则中引用一组值。如果您试图阻止一系列电子邮件地址,应创建一个阻止列表,而非为想要阻止的每个邮件地址创建多个规则。
在规则中引用的所有列表的别名都应以 @ 开头。要构建一个引用列表的规则,应遵循以下结构:
{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
使用列表的规则不仅更简洁,而且更容易编辑和添加大量项目。
注意:欧盟商家在阻止欧盟成员国客户的付款时,应了解与地域有关的规则及限制。了解有关该规范的更多信息。
通过多个条件编写复杂规则
可以用运算符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})
通过在不同位置使用括号,这些复杂条件中的每一个都会导致不同的结果。
is_missing 函数也可以用于 OR 或 AND 连词中:
Review if is_missing(:email_domain:) OR :email_domain: IN ('yopmail.net', 'yandex.ru')
或者也可以在不缺少的情况使用 is_missing 函数。在这种情况下,在“不”缺少 :ip_country:并且 IP 来自 US 或 PR 时,它将阻止付款。
Block if !(is_missing(:ip_country:))AND :ip_country: IN ('US', 'PR')
回溯测试规则
作为规则分析的一般原则,在防止欺诈和阻止良好交易或误报之间需要做出取舍。回溯测试有助于确定符合您风险偏好的规则,或者在预防争议和增加误报之间取得适当平衡。要估计规则的影响,您可以通过 Radar 管理平台使用过去六个月的交易数据对组合进行回溯测试,并进行更有针对性的分析,以了解规则在最近实施时的表现情况。
管理平台中的回溯测试
![](https://images.ctfassets.net/fzn2n1nzq965/3DXNvXULUnqWFbn5Ir55NF/1ebb15a9eef5ba49e919b6c066783af9/Test_results__1_.png?w=2664&q=80)
根据您测试的规则类型,欺诈性付款和其他成功付款的定义有所不同:
阻止规则
被提出争议、收到早期欺诈预警或因欺诈而退款:因欺诈而被提出争议或退款的成功收款或因欺诈而被提出争议或退款的审核中的成功收款
其他成功的付款:未因欺诈而被提出争议或退款的成功收款或被放入审核且未因欺诈而被提出争议或退款的成功收款
失败的付款尝试:被发卡行拒绝或被 Radar 阻止
审核规则
因欺诈而被提出争议、收到早期欺诈预警或被退款:因欺诈而被提出争议或退款的成功收款
其他成功的付款:未因欺诈而被提出争议或退款的成功收款
失败或已被放入审核:被发卡行拒绝、被 Radar 阻止,或被放入审核的成功收款(无论争议或退款状态如何)
允许规则
被 Stripe 或您的自定义规则阻止:被 Radar 阻止的收款
被提出争议、收到早期欺诈预警或因欺诈而退款:因欺诈而被提出争议或退款的成功收款或因欺诈而被提出争议或退款的审核中的成功收款
其他成功或银行拒绝的付款:被发卡行拒绝,未被提出争议的成功收款或因欺诈而被退款或被放入审核且未因欺诈而被提出争议或退款的成功收款
执行自定义回溯测试分析
Radar 管理平台中的回溯测试功能专注于过去六个月的交易,包括争议、早期欺诈预警和因欺诈而被退款的收款。
例如,如果您在 Visa 欺诈监控计划中面临被识别的风险(专门关注早期欺诈预警),或者您注意到最近来自特定 IP 国家或钱包类型的欺诈激增,那么您可能希望执行更有针对性的分析。为此,您可以在 Sigma 中构建 SQL 查询,或者在管理平台中导出和分析付款数据报告。自定义回测允许时间范围的灵活性(超过六个月)和更有针对性的分析(例如,您可以只关注争议或早期欺诈预警)。如果您假设发现最近更高价值上的欺诈量激增,并且交易的高风险评分带来了监控计划风险,那么可通过下面的查询示例对大于 100 美元的交易的 Visa 早期欺诈预警 (EFWs) 进行回溯测试:
Using fields and tables available in Sigma
with base as (
select
c.id,
c.amount,
c.captured,
e.created as efw_created
from charges c
left join early_fraud_warnings on e.charge_id = c._id
where card_brand = ‘visa’
and (c.amount / 100) >= 100
and c.captured >= dateadd(‘day’, -180, current_date)
)
select
count(case when efw_created >= dateadd(‘day’, -60, current_date) then id else null end) as fraud_charge_count,
sum(case when efw_created >= dateadd(‘day’, -60, current_date) then amount else null end) as fraud_amount,
count(case when efw_created is null and captured between dateadd(‘day’, -120, current_date) and dateadd(‘day’, -60, current_date) then id else null end) as false_positive_charge_count,
count(case when efw_created is null and captured between dateadd(‘day’, -120, current_date) and dateadd(‘day’, -60, current_date) then amount else null end) as false_positive_amount
from base
根据早期欺诈预警创建日期对过去 60 天进行回溯测试可以锁定最近的欺诈行为,而对过去 60-120 天的非欺诈销售进行回测,则可以让欺诈行为有足够的时间完全暴露出来或变得更明显。
常见欺诈模式
大多数欺诈者都遵循一种常见的欺诈模式。首先,他们验证被盗的支付信息(例如,银行卡)。一旦验证这些凭证有效,他们就会利用这些凭证提取价值,形式包括用于个人使用或转售的实物商品(奢侈品或电子产品)、用于个人使用或转售的服务(食品配送服务),或用于进一步实施欺诈的服务和产品(例如,网络托管服务、消息群发服务等)。
请继续阅读,了解一些最常见的欺诈手段的更多详情,以及推荐的使用 Radar 规则来减少欺诈的方法。
测试
银行卡测试是指欺诈者使用脚本或手动流程来测试被盗的原始卡号是否仍然有效。这个阶段的欺诈并不是为了获取实物商品或服务,而是为了验证这些卡片是否有效。这些交易通常是金额较低的交易或授权。测试通常在短时间内迅速连续进行,并且具有高频率。可能有帮助的属性是分组和速度特征,例如:
total_charges_per_customer
card_count_for_email
card_count_for_ip_address
total_charges_per_ip
欺诈者通常会通过创建虚假电子邮件和使用不同的电子邮件地址来规避检测。更高级的欺诈者会隐藏 IP 地址,甚至使用多个设备来提供独特的设备数据。在这一点上,了解正常的和典型的客户行为变得非常重要。电子邮件域名和 IP 国家等特征,以及其他更广泛的类别,可以帮助识别高风险交易。许多实施欺诈的客户会使用知名电子邮件提供商的流行域名,例如 gmail.com。您可能会看到像 gmail.comms 或 gmail.comms 这样的域名,它们试图掩盖欺诈者的身份。银行卡所在国家和 IP 所在国家也可用于帮助细分客户,并确保交易来自您的用户群的典型地区。来自这些地区以外的交易可能需要进行审核或将其阻止。
防止这种测试行为的一个最终功能是引入 CAPTCHA。
在 Stripe Checkout 中,当我们的机器学习检测到银行卡测试攻击时,会自动提供 CAPTCHA 验证。为了减少银行卡测试,Stripe 使用了一系列自动化和手动控制措施,包括速率限制器、警报和持续审查,同时训练银行卡测试模型以自动检测攻击。这些模型只有在银行卡测试攻击进行时才会提供验证,因此真实用户几乎不会看到 CAPTCHA,只是机器人看到。这将使用 Stripe Checkout 的商家的银行卡测试减少了高达 80%,对转化的影响,微乎其微。
为所有 Checkout 用户添加 Stripe 管理的 CAPTCHA 将银行卡测试减少了 80%,而它对授权率的影响不到 2 个基点 (0.02%)。
注意,您还可以编写诸如“如果一个 IP 地址被拒绝超过 3 次,则将其阻止”这样的自定义规则来减少银行卡测试攻击。
价值提取
被盗信用卡(新行为)
在这种欺诈方式中,欺诈者在其个人设备或用于实施欺诈的设备上使用经过验证的被盗信用卡。
这种方式通常通过脚本化的大规模攻击或较小规模的更有针对性的欺诈团伙和小组来实施。不管是哪种方式,使用衡量 Stripe 上账户的新旧度的规则属性(例如,hours_since_email_first_seen_on_stripe
),结合 risk_score 和其他特征,可以防止这些全新的持卡人进入。此外,对 IP、电子邮件和卡片的速率限制可以进一步保护商家,使其免受那些试图尽快利用被盗凭证获利的欺诈者的大规模攻击。
被盗信用卡(伪装行为)
在这种欺诈方式中,欺诈者在其个人设备或用于实施欺诈的设备上使用经过验证的被盗信用卡,或者欺诈者已经攻破了一个订阅账户并获得了该账户中存储的信用卡信息。
欺诈者会尽力掩盖其存在,具体方式有:
使用与之前完成的交易相同的名称
使用与之前完成的交易相同的账单地址
使用 VPN 试图使其看起来像是持卡人本人。他们可能通过 VPN 进入同一个城市,有时甚至是同一个街区
只更改小细节,如电子邮件地址或电话号码
对于实物商品,更改以前交易的发货地址,账单和发货地址之间的距离可能会有存在较大差异。这是一个松散的信号
上面描述的伪装行为使得很难解析出谁是真正进行交易的人——持卡人本人还是盗取了账户的欺诈者。这通常意味着这种欺诈在更长时间内不会被商家和持卡人本人发觉。
这种情况的应对策略是相同的:欺诈者将试图从盗来的凭证中提取尽可能多的价值。使用速率限制功能以及 riskscore, cvccheck 失败或邮编检查失败的规则有助于防止这种行为。
其他最佳做法
以下是帮助您优化在 Radar 中编写规则时的其他最佳做法。
结账流程
|
|
---|---|
在结账流程中,需明确提及您的服务条款
|
在发生撤单的情况下,提供结账流程中显示的服务条款的清晰截屏,并解释其重要性。这会增加您的赢率。 |
验证 CVS 和邮编
|
允许发卡行验证持卡人。可能会增加您的赢率,并且通常会提高授权率。考虑阻止失败的检查。 |
尽可能多地收集客户信息
|
收集这些细节有助于发卡行在发生撤单时评估您的情况,从而提高您的赢率。这些被视为是尽职调查。 |
黄金标准包括:CVC 和邮编,客户名称,电子邮件地址,完整的账单地址,IP 地址,设备信息等。
|
实施 Stripe.js 可以为 Radar 提供 IP 地址、设备和行为信息,从而改进欺诈检测。 |
客户互动
|
|
---|---|
将发生撤单的银行卡列入“欺诈”类阻止列表
|
如果客户认为某笔收款是欺诈性的,那么未来的收款也可能会被提出争议。 |
退还可疑/欺诈性的付款
|
70–85% 的 TC40 交易会演变成争议,只有全额退款方能妥善避免。 |
使用清晰的对账单描述符
|
减少未被识别的争议的数量。 |
使用 Stripe.js 的重要性
![](https://images.ctfassets.net/fzn2n1nzq965/74X36lTlA80oZNxgFVptEk/ce4de3423675886e24d346dcefd1c451/Screen_Shot_2022-04-05_at_11.57.23_AM.png?w=2078&q=80)
- 将 stripe.js 包含在完整的支付路径中,以最大化欺诈信号
- 为了在不影响页面加载时间的情况下充分利用 Radar,请在非支付页面上异步加载 stripe.js
- 最容易放在 Google Analytics 脚本标签旁边
- 完整的 stripe.js 包大小为 29.6kb 的 gzipped
- 未来的 state: radar.js 将可以从 stripe.js 中独立出来
- 未来的 state: radar.js 将可以从 stripe.js 中独立出来
结论
规则可以是一个非常强大的工具,帮助您定制您的欺诈保护。通过实施独特的逻辑,并参考本指南中概述的一些最佳做法,您可以在 Radar 中创建一个特定于您的业务需求的防欺诈设置。
如果您想了解更多有关 Radar 风控团队版的信息,请参见此处。
如果您已经是 Radar 风控团队版用户,请查看管理平台中的规则页面开始编写规则。
其他注意事项
平台对 Radar 的使用
您是使用 Stripe Connect 的平台吗?如果是,那么您创建的任何规则仅适用于在平台账户上创建的付款(在 Connect 术语中,这些是指定向或代为收款)。
在 Connect 子账户上直接创建的付款需遵循该账户的规则。
Terminal 的 Radar
Radar 不对 Terminal 收款进行筛查。这意味着,如果您使用 Terminal,那么可以根据 IP 频率编写规则,而不必担心阻止您的线下付款。