测试 Stripe Radar
用以下信息测试您的欺诈预防策略。
使用下面的测试用信用卡卡号在测试模式下创建特定风险等级的付款。在 Stripe 管理平台 (in test mode)中,或通过用您的测试 API 密钥调用 创建收款 来创建测试性付款。
卡号 | 描述 |
---|
| 导致收款的风险等级为 highest ,但可能会根据您现有的规则来阻止(例如,如果 Block if :risk_level: = 'highest' 规则被禁用,则用此卡进行的付款不会被阻止)。 |
| 导致收款的风险等级为 highest ,始终被阻止,无论是什么规则。 |
| 导致收款的风险等级为 elevated 。 |
规则
在您添加或更新规则前,我们将搜索真实模式下与规则的标准匹配的付款。您可以检查该付款列表来验证标准的预期行为,我们还总结了这些搜索结果,帮助您估计其未来的影响。
对于您测试的每个规则,摘要中包含属于以下类别的付款的金额和笔数:
- 被提出争议和早期欺诈预警: 收到争议或早期欺诈预警 (EFW)的付款。
- 退款:被退还的款项。
- 失败和阻止:被 Radar 阻止、被 Stripe 阻止或被发卡行拒绝的付款。
- 合法:成功处理且未被当做欺诈或发放退款的付款。
此外,在您测试允许规则时,您还可以看到覆盖。这是指由于高欺诈风险或自定义阻止规则而被 Radar 阻止的付款,但现在将被您给出的规则允许。在管理平台中,您可以看到对这些汇总指标的进一步细分。例如,您可以看到哪些退款被归到欺诈一类。
检查下表中的问题示例,以帮助您决定是否可实施您的规则。
注意
很难找到一个完美的规则来只阻止欺诈性付款或只允许好的付款。因此,您的规则实施决定通常要基于一种适当的取舍。思考一下,与它可能错误阻止的任何有效付款相比,该规则是否会阻止足够多的欺诈性付款。具体如何取舍对您有利,取决于您的具体业务情况。有关更多信息,请参见我们的欺诈检测入门。
规则类型 | 在以下情况下执行此规则… |
---|
阻止 | - 它匹配的是有争议的付款、收到的早期欺诈预警或作为欺诈以可接受的合法业务付款金额为代价退款的付款。
- 它匹配的是退款,并且您正在尝试节省运营负担并防止滥用退款。
- 它匹配因发卡行拒付而失败的付款。有时,如果您发送大量失败的交易(例如某商家遇到大量银行卡测试),发卡行可能会降低您的授权率。
|
审核 | - 它匹配的是有争议的、收到早期欺诈预警或作为欺诈而退款的付款。它会提示您的团队密切评估潜在的欺诈性交易或其他可疑的支付活动。
|
请求 3DS 验证 | - 它匹配的是有争议的付款、收到的早期欺诈预警或作为欺诈以可接受的合法业务付款金额为代价退款的付款。注意:3DS 并不总能保证您的用户会收到验证要求。这意味着,虽然在欺诈者通过无阻 3DS 并实施欺诈而您获得转移责任的情况下,您仍然可能会收到早期欺诈预警(从而最终导致被 VFMP 识别)。
|
允许 | - 它匹配的是先前被阻止的付款的,对于这些被阻止的付款,您高度相信其对您的业务是安全的。允许规则的评估有点棘手,因为对于之前阻止的收款,如果被允许的话,没办法知道哪些会是真的欺诈。因此,使用这些规则,尤为重要的是审核匹配的历史付款列表,确保这些是您希望允许的付款。
- 它与很多覆盖不匹配。这表明您正在让高风险付款通过。
|