登录 

Radar 风控团队版规则基础知识

本指南详尽介绍了与 Radar 规则相关的内容，涵盖了 100 多种实用 Radar 规则，并提供关于回溯测试、规则编写等方面的最佳实践建议。

Radar
Radar

借 Stripe 强大网络之力打击欺诈。

了解更多 
  1. 导言
  2. 规则顺序和等级的重要性
  3. 规则语言备忘单
    1. 使用自然语言编写规则
  4. 常用 Radar 规则
    1. 用于防止银行卡测试或信用卡套现的规则
    2. 用于防止已知风险 SKU 欺诈的规则
    3. 用于防止预付卡滥用试用的规则
  5. 分析欺诈行为模式以指导规则制定
    1. 欺诈审核
    2. 更深入理解欺诈的推动因素
  6. 创建规则时的三类属性
    1. 第 1 类
    2. 第 2 类
    3. 基于频率的属性
    4. 基于银行卡详情的属性
    5. 基于付款详情的属性
    6. 基于客户详情的属性
    7. 第 3 类
  7. 使用规则中的保存列表（如允许列表、阻止列表）
  8. 编写涉及多个条件的复杂规则
  9. 回溯测试规则
    1. 管理平台中的回溯测试
    2. 执行自定义回溯测试分析
  10. 常见欺诈模式
    1. 测试
    2. 价值提取
  11. 其他最佳实践
    1. 使用 Stripe.js 的重要性
  12. 结论
    1. 其他事项
  13. 开始使用 Stripe 

Stripe 的默认规则利用机器学习算法，可预测和阻止大量的欺诈性付款。对于希望更深入控制付款审核、允许或阻止标准的商家而言，定制化的规则是增强欺诈保护的有效手段。

本指南详尽介绍了与 Radar 规则相关的内容，涵盖了 100 多种实用 Radar 规则，并提供关于回溯测试、规则编写等方面的最佳实践建议。

让我们直奔主题。

规则顺序和等级的重要性

规则在您的 Radar 页面中的排列顺序非常重要。每笔付款都会根据您创建的规则顺序进行评估，并按照以下顺序执行：

  1. 请求 3DS 验证：与 Payment Intents API 或 Checkout 结合使用时，此规则会请求 3DS 验证。即便触发此规则，系统仍将评估允许、阻止和审核规则。
  2. 允许： 这类规则允许付款被处理。实施允许规则时应格外小心，因为它们会覆盖除 3DS 验证规则之外的其他所有规则使用时应最为谨慎。只有处理金额超过 100,000 美元的商家才能编写允许规则。
  3. 阻止： 这类规则会阻止付款并将其拒绝。一旦付款因阻止规则被拒绝，就不会根据任何审核规则进行评估。
  4. 审核：这些付款仍在处理中并已扣款。但此类付款已被标记为需审核，商家可按需进行复审。

为了更清晰地说明实际操作，我们可以通过以下规则示例来探讨具体的应用场景。由于第一条规则的存在，所有低于 10 美元的支付都将被自动允许。一旦满足这个条件，之后的规则将不再适用。同理，根据这些规则，在美国境内且风险等级为 normal（正常）的 1,500 美元付款也将被允许。虽然第四条规则禁止超过 1,000 美元的付款，但由于其排序靠后，来自美国、风险等级为 normal 的规则具有更高优先权。一旦触发特定规则，系统将不再评估随后的规则。

  • 允许低于$10的付款

  • 允许美国境内风险等级normal的付款

  • 阻止风险等级high的付款

  • 阻止超过greater than $1,000的付款

  • 审核用outside the US的卡进行付款

规则语言备忘单

规则的语法与 SQL 相似，您可以根据用于创建规则的数据类型选择不同的运算符。以下是一张相关的备忘单：

运算符
字符串
元数据
国家/地区
数字
描述
示例
=
等于

:card_country: = 'us'
!=
不等于

:card_funding: != 'prepaid'
<
小于

:amount_in_gbp: < 10.00
>
大于

:amount_in_usd: > 500.00
<=
小于或等于

:amount_in_eur:<= 100.00
>=
大于或等于

:amount_in_cad: >= 10.00
IN
在组中

:card_country: IN ('gb', 'ie')
INCLUDES
包含字串

:ip_address: INCLUDES '192.168'
LIKE
匹配给定的模式

:email: LIKE 'fraud%@stripe.com'

如果需要明确检查某个属性或元数据属性是否存在，建议不要使用 != 运算符，而应使用 is_missing 函数，使用这个函数来指定可能缺失的属性或元数据键。例如，您可以编写以下规则，来匹配所有缺失客户电子邮件的支付情况：

  • Review if is_missing(:email_domain:)

你也可以编写规则来匹配“不”缺少客户电子邮件地址的所有付款：

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

使用自然语言编写规则

如果您想更轻松地编写规则，或者不确定使用哪些属性来解决特定的欺诈场景，由 AI 驱动的 Radar 助手会将您的自然语言提示转换为 Radar 语法中的规则。您还可以直接利用 Radar 助手对规则进行回溯测试，这样就可以在实施规则之前查看它的历史表现。

常用 Radar 规则

下方是根据不同目标整理的常用 Radar 规则的非详尽列表。

用于防止银行卡测试或信用卡套现的规则

Block if :total_charges_per_ip​_address_hourly: > 1

该规则对阻止银行卡测试很有帮助。如果一个 IP 地址在您的账户上被多次成功授权，它将阻止收款。

Block if :blocked_charges_per_ip​_address_hourly: > 1

如果您想更积极地防止银行卡测试，请将此规则与 :total_charges_per_ip_address_hourly: 结合使用。

Block if :total_charges_per​_card_number_hourly: > 1

该规则对阻止信用卡套现很有帮助。如果您的账户在最近一小时内对某个卡号多次成功授权，它将阻止收款。

Block if :blocked_charges_per_card​_number_hourly: > 1

如果您想更积极地防止信用卡套现，请将此规则与 :total_charges_per_card_number_hourly: 结合使用。

Block if :address_zip_check: != 'pass'

务必在您的结账表单中收集邮政编码以使用此规则。如果发卡行无法验证所提供的邮编是否与他们的保存的银行卡信息相符，则该规则将阻止收款。

Block if :cvc_check:: != 'pass'

务必在您的结账表单中收集 CVC以使用此规则。如果发卡行无法验证所提供的 CVC（或 CVV）是否与他们的保存的银行卡信息相符，则该规则将阻止收款。

用于防止已知风险 SKU 欺诈的规则

此规则要求在交易描述中加入元数据或SKU信息。尽管这类支付会被正常处理并扣除客户费用，但它们会被特别标记，以便您进行复审。

Review if ::SKU Category:: IN ('baby formula', 'personal hygiene')

假设您是一家杂货店，您将向我们发送 SKU 类别的元数据。根据您的观察，包含标 'personal hygiene' 或 'baby formula' SKU 类别商品的订单通常具有较高风险。基于此，该条规则会将带有这些项的所有订单加入到您的 Stripe 管理平台的手动审核列表，供您复查。请注意，除非您手动取消订单，否则仍会处理这些付款并向客户扣款。

Review if :charge_description: = 'Trial class'

假设您销售两种产品（'Trial class' 和 '10 class package')，并将产品名称作为收款说明发送给 Stripe。此规则会将具体收款描述为 'Trial class' 的所有订单加入您 Stripe 管理平台的手动审核列表，以供复查。请注意，除非您手动取消订单，否则仍会处理这些付款并向客户收款。

用于防止预付卡滥用试用的规则

Block if :card_funding: = 'prepaid' OR :card_funding: = 'unknown'

假设您是一家提供在家试用的零售商，并注意到使用预付卡的欺诈行为激增，然后您无法收取来自预付卡的付费。该规则将阻止任何未使用信用卡或借记卡支付的订单。

分析欺诈行为模式以指导规则制定

欺诈审核

为了制定出最有效的防欺诈规则，您需要深入分析您账户上的欺诈活动。准确描述不同类型的欺诈手段至关重要。你需考虑的一些问题包括：

  • 账户是否使用新的电子邮件地址和持卡人姓名注册并立即进行欺诈性购买？

  • 欺诈者是否访问过期账户并以异常高的金额进行购买？

  • 欺诈是否倾向于特定的卡组织或发卡国家？

  • 是否有高频率欺诈发生，即在短时间内通过同一银行卡、同一电子邮件地址或同一 IP 地址进行多次尝试？

仔细观察上方截图中的高频率欺诈，利用 authorized_charges_per_card_number_hourly 或 authorized_charges_per_ip_address_hourly 的规则可能会有效防范此类欺诈行为。

更深入理解欺诈的推动因素

欺诈洞察功能可帮助您迅速识别并应对欺诈的根本原因，无需手动分析交易数据。管理平台中的洞察选项卡显示与欺诈交易相关的主要属性。在这里，您可以添加一个规则，直接从“洞察”选项卡中处理该属性。

创建规则时的三类属性

第 1 类

授权后属性：任何人都可使用这些属性。使用这些属性时，需要在授权后属性前后使用冒号，如:cvc_check:。

属性
描述

:address_line1_check:

 发卡行根据保存的持卡人信息匹配提供的账单地址的第一行（通常为街道名称和编号）时进行的一项检查。

:address_zip_check:

 发卡行根据保存的持卡人信息匹配提供的邮编时进行的一项检查。

:cvc_check​:

 发卡行根据保存的持卡人信息匹配提供的 CVC（有时也说 CVV）时进行的一项检查。
可能的值
描述

pass

 提供的数据正确。

fail

 提供的数据不正确。

unavailable

 客户的发卡行不会检查提供的数据。并非所有发卡行或国家都支持国家地址验证。

unchecked

 数据已经提供，但尚未核对。客户的发卡行将最终检查提供的数据。

not_provided

 数据未提供给 Stripe。
这些值区分大小写。

以下是如何使用授权后属性的示例：

  • Block if :address_line1_check: != 'pass' 有了这条规则后，如果没有通过发卡行的检查，无法将所提供的账单地址的第一行与持卡人档案中的信息进行匹配，那么任何收款都将被阻止。这意味着，如果这项检查“不可用”，如果该数据“未经发卡行检查”，或者如果发卡行“not_provided”，则付款将被阻止。

第 2 类

标准属性：任何人都可使用这些属性。您需要在标准属性前后使用冒号，例如 :card_bin: 我们将标准属性分为四类：

  • 基于频率的属性——用于防止银行卡测试或信用卡套现
  • 基于银行卡详情的属性
  • 基于付款详情的属性
  • 基于客户详情的属性

某些属性需要以字符串形式提供值，而其他属性则需要以数字形式。让我们为每个属性提供示例来阐明这一点。如果属性需要像 :card_bin: 这样的字符串，那么在示例中您会看到这个数字加上了 ‘ ’。例如 :card_bin: = ‘424242’。而对于需要数字的属性，就不会有单引号，如 :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，以此类推。

属性
描述

:authorized_charges_per​_card_number_all_time:

 您的账户中这张卡的收款被成功授权的笔数。考虑了 2020 年以来的付款。（注意：上限 <= 25）。

:authorized_charges_per​_card_number_weekly:

 您的账户过去一周内这张卡的收款被成功授权的笔数。（注意：上限 <= 25）。

:authorized_charges_per​_card_number_daily:

 您的账户过去一天内这张卡的收款被成功授权的笔数。（注意：上限 <= 25）。

:authorized_charges_per​_card_number_hourly:

 您的账户过去一小时内这张卡的收款被成功授权的笔数。（注意：上限 <= 25）。

:authorized_charges_per​_email_all_time:

 您的账户中来自该邮件地址的收款被成功授权的笔数。考虑了 2020 年以来的付款。（注意：上限 <= 25）。

:authorized_charges_per​_email_weekly:

 您的账户过去一周内来自该邮件地址的收款被成功授权的笔数。（注意：上限 <= 25）。

:authorized_charges_per​_email_daily:

 您的账户过去一天内来自该邮件地址的收款被成功授权的笔数。（注意：上限 <= 25）。

:authorized_charges_per​_email_hourly:

 您的账户过去一小时内来自该邮件地址的收款被成功授权的笔数。（注意：上限 <= 25）。

:authorized_charges_per​_ip_address_all_time:

 您的账户中来自该 IP 地址的收款被成功授权的笔数。考虑了 2020 年以来的付款。（注意：上限 <= 25）。

:authorized_charges_per​_ip_address_weekly:

 您的账户中过去一周内来自该 IP 地址的收款被成功授权的笔数。（注意：上限 <= 25）。

:authorized_charges_per​_ip_address_daily:

 您的账户中过去一天内来自该 IP 地址的收款被成功授权的笔数。（注意：上限 <= 25）。

:authorized_charges_per​_ip_address_hourly:

 您的账户中过去一小时内来自该 IP 地址的收款被成功授权的笔数。（注意：上限 <= 25）。

:authorized_charges_per​_customer_daily:

 您的账户在最近 24 小时内对某个客户成功授权的次数。（这个计数中不包含当前评估中的付款。）

:authorized_charges_per​_customer_hourly:

 您的账户在最近一小时内对某个客户成功授权的次数。（这个计数中不包含当前评估中的付款。）

:blocked_charges_per​_card_number_daily:

 Stripe 的机器学习模型在最近 24 小时内拒绝的您账户中的某个卡号的次数。这个计数中不包含当前评估中的付款（例如，4）。

:blocked_charges_per​_card_number_hourly:

 Stripe 的机器学习模型在最近一小时内拒绝的您账户中的某个卡号的次数。这个计数中不包含当前评估中的付款（例如，4）。

:blocked_charges_per​_customer_daily:

 Stripe 的机器学习模型在最近 24 小时内拒绝的您账户中的某个客户的次数。这个计数中不包含当前评估中的付款（例如，4）。

:blocked_charges_per​_customer_hourly:

 Stripe 的机器学习模型在最近一小时内拒绝的您账户中的某个客户的次数。这个计数中不包含当前评估中的付款（例如，4）。

:blocked_charges_per​_ip_address_daily:

 Stripe 的机器学习模型在最近 24 小时内拒绝的您账户中的某个 IP 地址的次数。这个计数中不包含当前评估中的付款（例如，4）。

:blocked_charges_per​_ip_address_hourly:

 Stripe 的机器学习模型在最近一小时内拒绝的您账户中的某个 IP 地址的次数。这个计数中不包含当前评估中的付款（例如，4）。

:total_charges_per​_card_number_daily:

 过去 24 小时内在您的账户上尝试用某个卡扣款的次数。这个计数中不包含当前评估中的付款（例如，4）。

:total_charges_per​_card_number_hourly:

 过去 1 小时内在您的账户上尝试用某个卡扣款的次数。这个计数中不包含当前评估中的付款（例如，4）。

:total_charges_per​_customer_daily:

 您的账户在最近 24 小时内尝试对某个客户扣款的次数。这个计数中不包含当前评估中的付款（例如，4）。

:total_charges_per​_customer_hourly:

 您的账户在最近 1 小时内尝试对某个客户扣款的次数。这个计数中不包含当前评估中的付款（例如，4）。

:total_charges_per​_ip_address_daily:

 您的账户在最近 24 小时内尝试对某个 IP 地址扣款的次数。这个计数中不包含当前评估中的付款（例如，4）。

:total_charges_per​_ip_address_hourly:

 您的账户在最近 1 小时内尝试对某个 IP 地址扣款的次数。这个计数中不包含当前评估中的付款（例如，4）。

:declined_charges_per​_card_number_daily:

 发卡行在最近 24 小时内拒绝的您账户中的某个卡号的次数。这个计数中不包含当前评估中的付款（例如，4）。

:declined_charges_per​_card_number_hourly:

 发卡行在最近一小时内拒绝的您账户中的某个卡号的次数。这个计数中不包含当前评估中的付款（例如，4）。

:declined_charges_per​_customer_daily:

 发卡行在最近 24 小时内拒绝的您账户中的某个客户的次数。这个计数中不包含当前评估中的付款（例如，4）。

:declined_charges_per​_customer_hourly:

 发卡行在最近一小时内拒绝的您账户中的某个客户的次数。这个计数中不包含当前评估中的付款（例如，4）。

:declined_charges_per​_ip_address_daily:

 发卡行在最近 24 小时内拒绝的您账户中的某个 IP 地址的次数。这个计数中不包含当前评估中的付款（例如，4）。

:declined_charges_per​_ip_address_hourly:

 发卡行在最近一小时内拒绝的您账户中的某个 IP 地址的次数。这个计数中不包含当前评估中的付款（例如，4）。

:declined_charges_per​_email_all_time:

 您的账户拒绝的来自这个邮件地址的收款的笔数。考虑了 2020 年以来的付款。（注意：上限 <= 25）。

:declined_charges_per​_email_weekly:

 您的账户过去一周内拒绝的来自这个邮件地址的收款的笔数。（注意：上限 <= 25）。

:declined_charges_per​_email_daily:

 您的账户过去一天内拒绝的来自这个邮件地址的收款的笔数。（注意：上限 <= 25）。

:declined_charges_per​_email_hourly:

 您的账户过去一小时内拒绝的来自这个邮件地址的收款的笔数。（注意：上限 <= 25）。

:dispute_count_on_ip_all_time:

 您的账户中与来自这个 IP 地址的收款关联的欺诈性争议数量。考虑了 2020 年以来的付款。（注意：上限 <= 25）。

:dispute_count_on_ip_weekly:

 您的账户中过去一周内与来自这个 IP 地址的收款关联的欺诈性争议数量。（注意：上限 <= 25）。

:dispute_count_on_ip_daily:

 您的账户中过去一天内与来自这个 IP 地址的收款关联的欺诈性争议数量。（注意：上限 <= 25）。

:dispute_count_on_ip_hourly:

 您的账户中过去一小时内与来自这个 IP 地址的收款关联的欺诈性争议数量。（注意：上限 <= 25）。

:email_count_for​_card_all_time:

 您的账户中的交易与这张卡关联的邮件地址数量。考虑了 2020 年以来的付款。（注意：上限 <= 25）。

:email_count_for​_card_weekly:

 您的账户过去一周内的交易与这张卡关联的邮件地址数量。（注意：上限 <= 25）。

:email_count_for​_card_daily:

 您的账户过去一天内的交易与这张卡关联的邮件地址的个数。（注意：上限 <= 25）。

:email_count_for​_card_hourly:

 您的账户过去一小时内的交易与这张卡关联的邮件地址的个数。（注意：上限 <= 25）。

:email_count_for​_ip_all_time:

 您的账户中的交易与这个 IP 地址关联的邮件地址的个数。考虑了 2020 年以来的付款。（注意：上限 <= 25）。

:email_count_for​_ip_weekly:

 您的账户中过去一周内的交易与这个 IP 地址关联的邮件地址数量。（注意：上限 <= 25）。

:email_count_for​_ip_daily:

 您的账户中过去一天内的交易与这个 IP 地址关联的邮件地址数量。（注意：上限 <= 25）。

:email_count_for​_ip_hourly:

 您的账户中过去一小时内的交易与这个 IP 地址关联的邮件地址数量。（注意：上限 <= 25）。

:name_count_for​_card_all_time:

 您的账户中的交易与这张卡关联的姓名数量。考虑了 2020 年以来的付款。（注意：上限 <= 25）。

:name_count_for​_card_weekly:

 您的账户过去一周内的交易与这张卡关联的姓名数量。（注意：上限 <= 25）。

:name_count_for​_card_daily:

 您的账户过去一天内的交易与这张卡关联的姓名数量。（注意：上限 <= 25）。

:name_count_for​_card_hourly:

 您的账户过去一小时内的交易与这张卡关联的名字的个数。（注意：上限 <= 25）。

:total_charges_per​_card_number_all_time:

 您的账户从这张卡收款的总笔数。考虑了 2020 年以来的付款。（注意：上限 <= 25）。

:total_charges_per​_card_number_weekly:

 您的账户过去一周内从这张卡收款的总笔数。（注意：上限 <= 25）。

:total_charges_per​_card_number_daily:

 您的账户过去一天内从这张卡收款的总笔数。（注意：上限 <= 25）。

:total_charges_per​_card_number_hourly:

 您的账户过去一小时内从这张卡收款的总笔数。（注意：上限 <= 25）。

:total_charges_per​_email_all_time:

 您的账户从这个邮件地址收款的总笔数。考虑了 2020 年以来的付款。（注意：上限 <= 25）。

:total_charges_per​_email_weekly:

 您的账户过去一周内从这个邮件地址收款的总笔数。（注意：上限 <= 25）。

:total_charges_per​_email_daily:

 您的账户过去一天内从这个邮件地址收款的总笔数。（注意：上限 <= 25）。

:total_charges_per​_email_hourly:

 您的账户过去一小时内从这个邮件地址收款的总笔数。（注意：上限 <= 25）。

:total_charges_per​_ip_address_all_time:

 您的账户从这个 IP 地址收款的总笔数。考虑了 2020 年以来的付款。（注意：上限 <= 25）。

:total_charges_per​_ip_address_weekly:

 您的账户过去一周内从这个 IP 地址收款的总笔数。（注意：上限 <= 25）。

:total_charges_per​_ip_address_daily:

 您的账户过去一天内从这个 IP 地址收款的总笔数。（注意：上限 <= 25）。

:total_charges_per​_ip_address_hourly:

 您的账户过去一小时内从这个 IP 地址收款的总笔数。（注意：上限 <= 25）。

基于银行卡详情的属性

属性
描述

:card_bin:

付款卡的银行识别码 (BIN)，是卡号的前六位数字（例如，'424242')。

:card_brand:

付款卡的品牌。支持的值为：'amex' (American Express)、'visa' (Visa)、'mc' (Mastercard)、'dscvr' (Discover)、'diners' (Diners Club)、'interac' (Interac)、'jcb' (JCB) 和 'cup'（中国银联）。

:card_country:

发卡行所在国家对应的双字母代码（例如，'US')。有关国家代码的列表，请查看此页。要指定多个国家/地区，使用 IN 运算符。IN ('GB', 'DE', 'AE')。

:card_fingerprint:

付款卡的指纹。银行卡指纹是特定卡号的唯一标识符，您可以前往“付款”并在“支付方式”部分查看付款来找到这个号码（例如， 'VfE3rx3VlaQhS8Lp')。区分大小写。

:card_funding:

卡是预付卡、借记卡还是信用卡。支持的值为：'credit'、'debit'、'prepaid'、'unknown'。

:card_3d_secure_support:

付款银行卡的 3DS 验证支持等级。支持的值为：'required'、'recommended'、'optional’ 和 'not_supported'。

基于付款详情的属性

属性
描述

:amount_in_xyz:

兑换为由 xyz 指定货币后的付款金额（例如，amount_in_usd）。指定以下支持的货币之一，Stripe 会自动计算要使用的兑换金额：aud、brl、cad、chf、dkk、eur、gbp、hkd、inr、jpy、mxn、nok、nzd、ron、sek、sgd 或 usd。不要使用子单位（例如，使用美元，而不是美分）（例如，:amount_in_usd: > 250）

:average_usd_amount​_attempted_on_card_all_time:

您账户中该卡尝试交易的平均金额（以美元计算），计算范围从 2020 年起至今。

:average_usd_amount​_successful_on_card_all_time:

您账户上该卡获授权的交易的平均金额（以美元计算），计算范围从 2020 年起至今。

:risk_level:

给定付款的风险等级，由 Stripe 确定。支持的值为：‘normal’、‘elevated’、‘highest’ 和 ‘not_assessed’。

:risk_score:

给定付款的风险评分由 Stripe 确定（例如 >50 分）。这些评分的范围从 0（最低风险）到 100（最高风险）。当评分达到 65 分或以上时，风险级别被视为“较高”；评分达到 75 分或以上时，则被划分为“最高”风险级别。

:charge_description:

付款时提供的描述（例如，‘Class trial’）。

:is_recurring:

识别付款是否是经常性的——例如订阅服务的定期扣款。（这是布尔值，因此当它为真时，您可以使用 :is_recurring:；当它不为真时，您可以使用 NOT :is_recurring:。不能使用 !=。）

:is_off_session:

指示直接的用户操作未触发 Stripe Billing 付款，或 PaymentIntent 确认中设置 off_session 了标志。（这是布尔值，因此当它为真时，您可以使用 :is_off_session:；当它不为真时，您可以使用 NOT :is_off_session:。不能使用 !=。）

:digital_wallet:

 用于存储支付信息的数字钱包类型。支持的值为：‘android_pay’、 ‘amex_express_checkout’、‘apple_pay’、‘masterpass’、 ‘samsung_pay’、‘unknown’、’visa_checkout’、‘none’。

:destination:

对于创建定向收款的 Connect 用户，指的是代表所创建收款的目标（例如，‘acct_19KCB9AlaaEw6AgR’）账户。区分大小写。

:is_checkout:

识别付款是否是通过 Checkout 处理的。该属性仅适用于通过新版本的 Checkout 处理的付款，不会通过旧版 Checkout 捕获付款。（这是布尔值，因此当它为真时，您可以使用 :is_checkout:；当它不为真时，您可以使用 NOT :is_checkout:。不能使用 !=。）

:is_3d_secure​_authenticated:

识别该付款是否成功完成了 3DS 验证的认证。认证可能是基于风险，也可能基于验证。（这是布尔值，因此当它为真时，您可以使用 :is_3d_secure_authenticated:；当它不为真时，您可以使用 NOT :is_3d_secure_authenticated:。不能使用 !=。）

:is_3d_secure:

识别付款是否使用了要求 3DS 验证的来源。（这是布尔值，因此当它为真时，您可以使用 :is_3d_secure:；当它不为真时，您可以使用 NOT :is_3d_secure。不能使用 !=）。

:has_liability_shift:

如果这笔付款的欺诈责任已转移，则为 True。（这是布尔值，因此当它为真时，您可以使用 :has_liability_shift:；当它不为真时，您可以使用 NOT :has_liability_shift。不能使用 !=。）

:seconds_since_card​_first_seen:

在您的账户上首次看到进行该笔付款的卡账后的秒数。考虑了 2020 年以来的付款。

:seconds_since_first_successful​_auth_on_card:

自与您的账户上发生的付款有关的卡第一次成功授权后的秒数。考虑了 2020 年以来的付款。

:total_usd_amount_failed​_on_card_all_time:

您账户上这个卡未成功的交易（被阻止或拒绝）的总金额 (USD)。考虑了 2020 年以来的付款。

:total_usd_amount_successful​_on_card_all_time:

使您账户上的银行卡成功授权的交易的总金额 (USD)。考虑了 2020 年以来的付款。

基于客户详情的属性

属性
描述

:ip_country:

与付款来自的 IP 地址所属国家地域对应的两字母代码（例如，'GB')。有关国家代码的列表，请查看此页。要指定多个国家/地区，使用 IN 运算符。IN ('GB', 'DE', 'AE')。

:ip_address:

支付来源的 IP 地址（例如，'192.168.0.1' 指定一个 IP 地址，或者如果您想广撒网，可以使用 INCLUDES '192.168' 来包含所有都有这几个前六位数字的 IP 地址）。

:is_anonymous_ip:

识别付款来自的 IP 地址是否是一个已知的代理或 Tor 退出节点。该信息每日更新。（这是布尔值，因此当它为真时，您可以使用 :is_anonymous_ip:；当它不为真时，您可以使用 NOT :is_anonymous_ip:。不能使用 !=）。

:is_my_login_ip:

识别付款来自的 IP 地址是否曾用于登录您的 Stripe 账户。这个属性可用作“是我的 IP 地址”的代理。（这是布尔值，因此当它为真时，您可以使用 :is_my_login_ip:；当它不为真时，您可以使用 NOT :is_my_login_ip:。不能使用 !=。）

:email:

付款时提供的邮件地址（例如，'user@example.com')。

:email_domain:

付款时提供的邮件地址的域名（例如，'example.com')。

:is_disposable_email:

识别付款时提供的邮件地址是否是来自已知的一次性邮件地址提供商。Stripe 会维护一个与一次性邮件地址对应的域名列表来提供这个属性。（这是布尔值，因此当它为真时，您可以使用 :is_disposable_email:；当它不为真时，您可以使用 NOT :is_disposable_email:。不能使用 !=。）

:billing_address:

完整提供的持卡人账单地址（例如，'510 Townsend, San Francisco, CA 94110')。

:billing_address_line1:

提供的持卡人账单地址的第一行——通常是街道名称和编号（例如，'510 Townsend')。

:billing_address_line2:

提供的持卡人账单地址的第二行——通常是公寓或单元号（例如，'Apt 5b')。

:billing_address_postal_code:

提供的持卡人账单地址所属的邮编 (ZIP)（例如，'94110')。

:billing_address_city:

提供的持卡人账单地址所属的城市（例如，'San Francisco')。

:billing_address_state:

提供的持卡人账单地址所属的州（例如，'CA')。

:billing_address_country:

与提供的持卡人账单地址所属国家对应的双字母代码（例如，'US')。有关国家代码的列表，请查看此页。要指定多个国家/地区，使用 IN 运算符。IN ('US', 'DE', 'AE')。

:seconds_since​_email_first_seen:

自付款时提供的电子邮件地址首次出现在您的帐户上开始所过的秒数。考虑了 2020 年以来的付款。

:seconds_since​_email_first_seen_on_stripe:

自付款时提供的电子邮件地址首次出现在您的整个 Stripe 账户上开始所过的秒数。考虑了 2020 年以来的付款。

:shipping_address:

提供的完整账单地址（例如，'510 Townsend, San Francisco, CA 94110')。

:shipping_address_line1:

提供的收货地址的第一行——通常是街道名称和编号（例如，'510 Townsend')。

:shipping_address_line2:

提供的收货地址的第二行——通常是公寓或单元号（例如，'Apt 5b')。

:shipping_address_postal_code:

提供的收货地址的邮编 (ZIP)（例如，'94110')。

:shipping_address_city:

提供的收货地址所属的城市（例如，'San Francisco')。

:shipping_address_state:

提供的收货地址所属的州（例如，'CA')。

:shipping_address_country:

与所提供的收货地址所属国家对应的双字母代码（例如，'US')。有关国家代码的列表，请查看此页。要指定多个国家/地区，使用 IN 运算符。IN ('US', 'DE', 'AE')。

以下是标准属性的使用方法示例：

  • 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 管理平台使用过去六个月的交易数据对组合进行回溯测试，并进行更有针对性的分析，以了解规则在最近实施时的表现情况。

管理平台中的回溯测试

根据您测试的规则类型，欺诈性付款和其他成功付款的定义有所不同：

阻止规则

  • 被提出争议、收到早期欺诈预警或因欺诈而退款：因欺诈而被提出争议或退款的成功收款或因欺诈而被提出争议或退款的审核中的成功收款

  • 其他成功的付款：未因欺诈而被提出争议或退款的成功收款或被放入审核且未因欺诈而被提出争议或退款的成功收款

  • 失败的付款尝试：被发卡行拒绝或被 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 的重要性

  • 将 stripe.js 包含在完整的支付路径中，以最大化欺诈信号
  • 为了在不影响页面加载时间的情况下充分利用 Radar，请在非支付页面上异步加载 stripe.js
  • 最容易放在 Google Analytics 脚本标签旁边
  • 完整 stripe.js 包 gzip 压缩后大小为 29.6kb
    • 未来状态：radar.js 将能够独立于 stripe.js 单独引入

结论

规则可以是一个非常强大的工具，帮助您定制您的欺诈保护。通过实施独特的逻辑，并参考本指南中概述的一些最佳做法，您可以在 Radar 中创建一个特定于您的业务需求的防欺诈设置。

如果您想了解更多有关 Radar 风控团队版的信息，请参见此处。

如果您已经是 Radar 风控团队版用户，请查看管理平台中的规则页面开始编写规则。

其他事项

平台对 Radar 的使用

您是正在使用 Stripe Connect 的平台吗？如果是，那么您创建的任何规则仅适用于在平台账户上创建的付款（在 Connect 术语中，这些是指定向或代为收款)。直接在 Connect 子账户上创建的付款需要遵循该子账户自身的规则。

Terminal 上的 Radar 使用

Radar 不对 Terminal 终端收款进行筛查。这意味着，如果您使用 Terminal，那么可以根据 IP 频率编写规则，而不必担心阻止您的线下付款。

准备好开始了？

无需签署合同或填写银行信息，创建账户即可开始收款。您也可以联系我们，为您的业务设计定制套餐。
Radar

Radar

借 Stripe 强大网络之力打击欺诈。

Radar 文档

用 Stripe Radar 保护您的业务，远离欺诈。