Apple 的 DeviceCheck 能记住退款滥用者背后的那部手机，即使对方换了新账户注册

封禁账户挡不住在同一部手机上重新注册的退款滥用者。Apple 的 DeviceCheck 和 Google Play 的设备记忆（device recall）正是为填补这一空白而存在。两者都允许你的服务器为一台实体设备附加几个由你定义含义的比特位，存储在商店的服务器上，因此当背后的人换了新邮箱回来时，标记依然存在。这两个工具都不会给你设备 ID，也都无法阻止退款。它们的作用是在注册或付费墙环节告诉你：这台设备以前让你吃过亏。

下面说明每个商店实际存储什么，决定你能否设置标记的时间陷阱，以及在你发现之前，一个反复滥用退款的人会让你付出多少代价。

为什么新账户能绕过所有账户级防御

大多数退款防御都以账户为键。Apple 的 appAccountToken 将交易与你数据库中的用户绑定。Google Play 的混淆账户 ID 在 Android 上起同样作用。两者都应在每笔购买时设置，但它们描述的是一个人的账户，而不是他手里的硬件。删除账户，用新邮箱注册，你对这个人的记录就从零开始。

商店不会替你填补这个空白。App Store 退款通知告诉你哪笔交易被退款。Google Play 作废购买记录告诉你购买令牌、订单 ID 和 voidedReason。它们都不包含设备标识符。一位约会应用开发者在 Apple Developer Forums 的帖子中描述了这种结果：诈骗资料不断购买高级会员，随后又被退款，而用开发者自己的方法封禁其设备并没有帮助。

新账户会重置商店自己的试用吗？

在同一个 Apple 账户上不会。Apple 的文档说明，推介促销优惠（包括免费试用）只提供给尚未在该产品或同一订阅群组内任何产品上享受过的客户。因此在你的应用内换个登录，并不能再获得一次 Apple 试用。换一个新的 Apple 账户则可以，你自己发放的任何东西也一样：注册额度、服务器出资的试用、推荐奖励。这些正是设备标记要保护的赠品。

Apple 的 DeviceCheck 实际存储什么

DeviceCheck 分为两部分。在应用中，DCDevice 类生成一个标识设备的临时令牌。在你的服务器上，你把该令牌连同一个用开发者账户密钥签名的 JSON Web Token 一起发送给 Apple，Apple 便允许你查询或更新该设备的两个比特位。查询响应返回 bit0、bit1 和 last_update_time，后者以年和月表示。Apple 自己给出的示例用途是：已经领取过促销优惠的设备，以及你判定存在欺诈的设备。

比特位由 Apple 保存，但含义由你定义。其文档说明，你负责记录这些比特位的含义并决定何时重置，并以设备被出售为例。两个比特位可表示四种状态，一个简单的方案是：一位表示重度使用后退款，另一位表示已领取过免费额度。

• 令牌只能使用一次。Apple 表示其有效期足以重试请求，但每次调用都应生成新令牌。
• 开发版本连接 api.development.devicecheck.apple.com。生产环境必须使用 api.devicecheck.apple.com，否则你的标记会写到错误的地方。
• Apple 将 DeviceCheck 描述为整体风险评估的一项输入，而非结论。请把已设置的比特位视为需要进一步核查的理由。

Google 的设备记忆在 Android 上补充了什么

Google 的版本位于 Play Integrity API 中，目前仍处于 beta 阶段，需通过意向表单申请。获批并在 Play Console 中开启后，每个完整性判定都会附带该设备的三个自定义比特位。你通过服务器调用 deviceRecall:write 端点写入这些比特位，使用的是你已验证过的完整性令牌。Google 表示，这些数据在重装应用和重置设备后依然保留，因为它们存储在 Google 的服务器上。

Google 的文档对用途说得格外直接。它列出了有严重滥用证据的设备、已兑换过高价值项目（如免费试用）的设备，以及被反复用于创建新账户以进行滥用的设备。对限制也同样直接：设备记忆只能用于保护应用安全以及打击滥用、欺诈和未经授权的访问，绝不能用于对个人用户进行指纹识别或追踪，也绝不能存储年龄、性别或位置等敏感特征。

时间问题：退款到达时令牌已经失效

两个工具在标记设备之前都需要来自设备本身的东西。Apple 需要一个全新的 DCDevice 令牌。Google 需要来自该设备、不超过 14 天的完整性令牌。而退款是通过商店通知到达你的服务器的，通知对设备一无所知。所以问题不在于是否标记设备，而在于退款到达时，你是否还有办法触达这台设备。

Google 的 48 小时退款落在 14 天窗口之内

Google Play 的自助退款只在购买后 48 小时内可用，远在完整性令牌可用于写入的 14 天之内。在购买时运行完整性检查，把已验证的令牌与订单 ID 一起保存，当该订单的作废购买记录到达时，你就可以立即写入比特位。拒付是更难的情况，因为银行争议可能在第 14 天之后很久才到。

Apple 的退款需要设备回来

Apple 的退款可能在购买数周后才到达，而已保存的 DeviceCheck 令牌并不适合重复使用。实际的做法是先标记账户，再标记设备。退款通知到达时，在你的数据库中标记该账户。下次该账户打开应用时，请求一个 DeviceCheck 令牌并设置比特位。退款后仍保留内容的滥用者通常确实会回来，因为使用内容本来就是目的。

• 购买时，通过 appAccountToken 或混淆账户 ID 将交易记录到你自己的账户下。
• 发生退款或作废时，在你的服务器上标记该账户。
• 被标记账户下次会话时，获取设备令牌并设置你的比特位。
• 每次注册时，在发放任何需要你花钱的东西之前先查询比特位。

反复滥用退款的人会让你付出多少代价

退款金额只是看得见的部分。其余的是这笔购买已经启动的一切。如果你的应用需要花钱来交付所售内容，那么每一轮购买、消费、退款都会让这笔钱白白花掉：生成图片的 GPU 时间、对模型或数据 API 的付费调用、客户保留的导出文件的存储，以及按销售额计算的创作者分成。新账户会重新开启这个循环，而你的账本会把它记为一个全新客户。

免费赠品同样会流失，甚至根本不需要退款。一台设备在十个账户上薅注册额度，消耗的算力是你为一次试用所预算的十倍。在 Google Play 上，2026年8月3日之后的订单发生拒付时，你还要承担扣除 Google 服务费后的购买价格以及银行手续费，因此每次都用新账户发起争议的人，每次都会让你承担完整的争议成本。

如何处理被标记的设备

标记只回答一个问题：这台设备是否应该再次免费获得某样东西？请保持应对适度，因为已设置的比特位是证据，而不是定论。手机会被转卖，家人会共用 iPad，Google 也正因如此明确建议你考虑忽略或重置旧数据。

• 对被标记的设备，跳过注册额度、服务器出资的试用或推荐奖励，改为提供付费方案。
• 不要为被标记的设备签名促销优惠。在 App Store 上，解锁促销优惠的签名由你的服务器生成，因此决定权在你。
• 在被标记的设备上交付昂贵的消耗型项目之前，先要求付款完成结算。
• 利用时间戳。上个月设置的标记比两年前设置的更有分量。
• 给用户联系客服的渠道。被误标记的二手手机买家应该得到答复，你也可以重置比特位。

能直接封禁设备吗？

你可以拒绝提供自己的免费附加项，这正是设备标记发挥价值的地方。硬性封锁风险更大。今天拿着这部手机的人未必是当初滥用的人，而且 Google 自己的条款将设备记忆限定于防止滥用，而不是追踪个人。限制会让你花钱的东西，同时保持付费路径畅通。

那 Keychain（钥匙串）或设备标识符呢？

开发者常问 Keychain 标记或硬件 ID 能否起到同样作用。应用存储在手机上的标记在设备重置后就会消失，而 Apple 不会为此向应用提供稳定的硬件标识符。DeviceCheck 和设备记忆是商店认可的解决方案，恰恰因为这些比特位存储在 Apple 和 Google 的服务器上，而不是手机上。

哪些仍由商店决定

设备标记改变的是你的应用接下来送出什么。它们不会影响眼前的这笔退款。只有两种退款流程允许你在商店作出决定前提交证据。Apple 发送 CONSUMPTION_REQUEST，要求在 12 小时内提供消费数据。Google Play 发起拒付审核，你需要在 24 小时内通过 orders.reviewrefund 回复。其他一切，从 Google Play 的 48 小时退款到客服退款，再到未确认购买的自动退款，都在没有你参与的情况下决定。银行一旦裁决，拒付即为最终结果。

RefundHalt 会在时限内用你的真实使用数据回复每一个 CONSUMPTION_REQUEST 和 Google Play 拒付审核，并将每笔退款追溯到发起退款的账户，这样你的服务器在下次检查时就知道该标记哪台设备。