调至内容部分
创建账户
或
登录
Stripe 文档徽标
/
询问人工智能
创建账户
登录
开始
付款
销售收入
平台和交易市场
资金管理
开发人员工具
概览探索所有产品
开始构建
开始开发
项目示例
关于 API
使用大语言模型构建
在无代码的情况下使用 Stripe
设置 Stripe
创建账户
网页端管理平台
移动端管理平台
迁移到 Stripe
管理欺诈风险
了解欺诈
    概览
    欺诈类型
    银行卡测试
    识别欺诈
    验证检查
    最佳实践
Radar 欺诈保护
管理争议
验证身份
首页开始Understand fraud

保护自己免受银行卡测试攻击

了解这类欺诈活动及如何保护自己。

复制页面

银行卡测试是一种欺诈活动,即某些人通过不断尝试来确定盗来的卡是否可用于购物。欺诈者可能通过购买被盗的信用卡信息,然后尝试验证或用这些卡进行购物,以确定哪些卡仍然有效。银行卡测试的其他常用术语有“carding”(信用卡盗刷)、“account testing”(账户测试)、“enumeration”(枚举)以及“card checking”(信用卡查验)。

银行卡测试等欺诈活动是在线商务不可避免的一个部分。但是,银行卡测试会对整个支付生态带来负面影响,因此商家、信用卡组织和 Stripe 都有责任防止这种情况的发生。在 Stripe,我们不断改进我们的欺诈检测和缓解工具和系统,但您也必须对欺诈保持警惕。

银行卡测试是怎样一个过程

测卡分子会通过银行卡设置和支付来确定他们盗来的卡或枚举的信息是否有效。为了快速验证多个卡号,欺诈者会使用脚本一次性测试大量银行卡信息,并收集 3DS 验证或发卡行的响应来验证哪些卡信息有效。识别出有效卡后,他们可以在商家那里购物,或在暗网上转售已确认的卡。

  • 银行卡设置 — 这是诈骗者首选的一种方法,因为在持卡设置过程中的银行卡验证和授权信息通常不会显示在持卡人的对账单上。这降低了持卡人发现并举报欺诈活动的可能性。
  • 付款 — 测卡分子会创建小额付款,持卡人不太可能发现并举报欺诈。

银行卡测试后果

银行卡测试有许多负面后果,其中一些会随着银行卡测试的持续而随着时间变得更糟:

  • 争议 — 很多类型的银行卡测试会涉及到付款,其中一些支付会成功。客户注意到付款成功并将其报告为欺诈,这会导致早期欺诈预警甚至欺诈性争议,从而浪费您的时间和金钱。
  • 更高的拒付率 — 银行卡测试会将大量拒付与您的业务联系起来。高拒付率可能会损害您在发卡行及信用卡组织面前的商誉,从而使您的所有交易看起来都有一定风险。这可能导致合法付款的拒绝率增加,即使在银行卡测试停止后也是如此。
  • 额外费用— 银行卡测试活动可能会产生额外费用,例如自定义定价方案的授权费用以及争议费用。
  • 基础设施紧张— 银行卡测试通常会导致大量网络请求和操作。这种额外的流量可能会使您的基础设施不堪重负,并干扰合法活动。
  • 损害生态系统健康 — 银行卡测试会对整个金融系统带来负面影响,因此 Stripe 和我们的金融合作伙伴都希望帮您阻止这种行为。例如,大量导致早期欺诈预警或争议的银行卡测试可能会将您纳入银行卡监控计划。
  • 降低业务运营的数据质量 — 来自银行卡测试的收入在您的数据中貌似不错的新客户,因此您很难清楚地看到实际业务增长。

活动卡测试检查表

如果您的集成被测卡分子利用,那么建议您立即采取以下措施:

  • 识别 银行卡测试活动。
  • 退还欺诈性付款,以避免争议。
  • 使用 Stripe 推荐的集成或添加缓解措施来抑制银行卡测试。
  • 监测您的集成,确保缓解措施有效。

识别银行卡测试

您可以通过授权失败和付款次数的显著增加来识别大多数银行卡测试活动。大多数攻击在您的 Stripe 管理平台中都能明显看出来。需要注意的常见症状是:

  • **失败或被阻止的付款激增。**您可以在管理平台首页、交易列表视图中查看趋势,还可以在付款详情页面查看阻止原因。
  • 带 402 错误的请求激增。您可以在开发人员页面查看交易量峰值,在失败日志页面检查 402 个故障,或者侦听 webhook 和 API 响应,尤其是有 generic_decline 结果的情况。
  • 交易金额低的可疑付款激增,通常附有无意义的客户姓名和电子邮件地址。为避免争议,我们建议在这些可疑交易未通过现有防御措施时进行退款。
识别银行卡测试

付款因疑似银行卡测试被阻止

防止银行卡测试

测卡分子使用多种方法使其欺诈活动难以被阻止。因此,简单的防火墙规则或基于单个启发式方法(如 IP 地址)的过滤器通常不足以阻止银行卡测试。

测卡分子可能使用您的公钥,并用它在您的网站上重试大量付款。对于此类攻击,您有两种主要的缓解策略:

  • **使用推荐的 Stripe 集成 — **选择 Stripe 推荐的集成,利用我们已知的有效银行卡测试保护措施。
  • **控制实施 — ** 投资一套控制措施,阻止测卡分子攻击易受攻击的端点。

除了实施缓解策略外,您还要确保密钥安全,并且不要公开发布您的私钥。当您的凭据泄露或被盗时,测卡分子可以使用您的密钥创建付款并设置银行卡。

注意

不是开发人员?用插件还是平台?防止和减轻银行卡测试通常涉及到代码级别的更改,因此您需要向编写代码的开发人员或供应商出示该文档,并与他们一起来防止银行卡测试。

使用 Stripe 推荐的集成

如果您使用的是 Stripe 最新的 Payment Element 或 Checkout,我们会有许多自动化和手动控制来减轻银行卡测试,包括速率限制器、AI 模型、验证码触发器、持续审核等。当我们检测到您遭受银行卡测试攻击时,我们会动态选择干预措施来尽可能抑制攻击,同时仍允许合法用户在您的账户上进行交易,并将影响降至最低。您会看到这些付款被标记为 Blocked by Stripe。

然而,Stripe 控制措施的成功取决于您的集成以及您发送给我们的信号。我们利用许多信号来区分银行卡测试和合法的付款。虽然我们会自动计算其中一些信号,但许多信号取决于您的集成所提供的信息。通常,您的集成提供的数据越多,银行卡测试的预防效果就越好。

建议使用 Stripe 推荐的集成之一,以利用基于 CAPTCHAS 的自动保护。现代 CAPTCHAS 解决方案应用多种信号来增加高风险行为的阻力,而合法服务用户几乎看不到这些信号。要停用我们的 CAPTCHA 集成,请联系 Stripe 支持。

使用我们推荐的支付集成之一,可以让您最大限度地利用 Stripe 的银行卡测试预防措施。如果您不能使用推荐的集成,请包含尽可能多的数据或自行部署控制措施。虽然银行卡测试控制与 Radar 的欺诈性争议保护是分开的,但它们受益于 Radar 使用的相同信号。

在您的付款中包含以下信息可能会对 Stripe 的银行卡测试模型的效果产生重大影响。我们推荐的集成使您能够收集这些信息,而直接集成可能需要明确包含这些数据。

  • 高级欺诈检测 影响等级最高
  • IP 地址
  • 客户邮箱
  • 客户名称
  • 账单地址

控制实施

向目标端点添加限制有助于抑制和防止银行卡测试。实施的限制会使银行卡测试变得不切实际,同时对您的合法流量的影响很小甚至根本没有影响。

测卡分子瞄准的端点通常允许他们执行下列某项操作:

  • 保存银行卡。
  • 进行付款。

根据您的情况和业务需求的不同,向集成中添加的具体安全措施也会有所不同。下面我们介绍几种常见的方法。

实现 CAPTCHA

测卡分子经常使用 CAPTCHAS 可能阻止的自动化脚本。如果您没有使用支持 CAPTCHA 的推荐集成之一,那么这些脚本特别有效。现代 CAPTCHAS 解决方案根据您的需求,提供可见和不可见两种 CAPTCHAS 选项。如果您向集成中添加了 CAPTCHAS,但银行卡测试未停止,则检查以下内容:

  • 确保验证码对所有启用了银行卡验证请求或 Stripe 的付款请求进行验证。
  • 查看 CAPTCHA 文档,确保您已在服务器端实现了该功能。
  • 如果您使用的 CAPTCHA 解决方案提供分数,则调整阻止请求成功的阈值。
  • 尝试不同的验证码解决方案,例如从不可见验证码切换为可见验证码,或者完全使用不同的验证码解决方案。

限制对您的支付表单的访问

欺诈行为者越容易获取您的支付表单(例如,使用访客结账),他们就越容易执行银行卡测试攻击。您可以通过在测卡分子付款前要求登录或会话验证来减少他们与测卡分子的接触。对于某些类型的银行卡测试,某些针对跨站请求伪造 (CSFR) 的保护措施也非常有效,例如 CSRF 令牌。

添加速率限制

在某些情况下,您可以通过添加网络速率限制来减少银行卡测试(例如,在网店前端)。调整这些速率限制,以停止您正在经历的特定类型的银行卡测试。例如,如果测卡分子通过将卡绑定到新客户来验证卡,则限制 1 天内单个 IP 地址可以创建的新客户数量就是一种有效的阻止方法。

除了卡组织速率限制之外,您还可以向付款和购物车结账流程添加速率限制,以检测和防止异常行为,即使在登录或注册后也是如此。

检测和防止异常行为

使用管理平台、Webhook 或 Stripe Sigma 或 Data Pipeline 进行持续监控,以跟踪流量中的异常情况。您可以将卡片测试活动与典型合法流量进行比较,然后构建仅限制或阻止卡片测试活动的筛选器。例如,您可能对系统进行以下更改:

  • 限制可添加到账户的银行卡数量
  • 限制通过单个 IP 地址可创建的客户数量
  • 限制可以使用同一产品进行的购买次数
  • 限制可创建的同类型客户的数量
  • 用某些用户代理或其他参数过滤请求

为此,您可以利用“Radar 风控团队版”中的自定义规则。我们将在下一节中介绍这一点。

使用组合缓解措施

结合多种方法减少卡片测试以最大化对欺诈活动的影响,同时不对合法流量产生负面影响可能是有意义的。例如,您可以结合验证码和速率限制,使来自 IP 地址的首次付款尝试无限制成功,但同一 IP 地址在接下来几小时内发出的后续请求需要验证码验证才能成功。

谨慎重试

如果付款出现极端峰值而成功率低,那么过多的重试(催款)可能看起来像银行卡测试。催款和真实银行卡测试攻击可能会对您的业务产生类似的影响,包括发卡行加强风险立场。一定不要在银行卡测试攻击后继续重试在欺诈客户上设置的银行卡,因为这会重复最初的攻击。Stripe 的 Smart Retries 已经考虑到了这一点。

根据您的风险偏好定制保护措施

除了实施缓解措施之外,您可能还希望使用 Radar 进一步微调您的保护措施。它带有基于银行检查的内置规则,例如 CVC 检查。

如果您了解您的客户行为并希望详细自定义支付速度,则可以在 Radar 风控团队版中构建自定义规则。

您可以在 Radar 101 指南中找到相关示例。

另见

  • 高级欺诈检测
  • 优化您的 Radar 集成
  • 保证您的密钥安全
  • Radar 101 指南
此页面的内容有帮助吗?
是否
需要帮助?联系支持。
加入我们的早期使用计划。
查看我们的更改日志。
有问题?联系销售。
LLM? Read llms.txt.
Powered by Markdoc