友好欺诈是客户已经拿到所付商品的那种拒付，也是唯一一种你的证据仍能左右的争议

友好欺诈是没人提醒你的那种争议，因为发起它的人不是拿着被盗卡的罪犯。那是你真正的客户。他们用自己的卡购买了你的应用内购买项目，用完了所买的东西，然后告诉银行这笔扣款是个错误。钱退了回去，商品已经花掉，而在银行那一侧，这个案子看起来和真正的欺诈一模一样。对应用开发者而言，这件事之所以重要只有一个原因：它是唯一一种你自己的证据仍能作为裁决输入的争议类型，而两家商店都只给你几个小时来提供它。以下是友好欺诈的真实成本、它为何持续攀升，以及 Apple 和 Google 留给你的那根狭窄杠杆。

什么是友好欺诈，以及它为何并不总是欺诈

友好欺诈，也称作第一方欺诈或拒付欺诈，发生在真正的持卡人先完成购买，在收到商品或服务之后再向发卡银行申请拒付时。这个名字是故意反着叫的。对面那个人不是第三方攻击者，而是那位点了购买的同一个客户。

意图并不总是存在。其中一部分是蓄意滥用，一种既留下内容又把钱抠回来的做法。但也有大量是诚实的混淆：一位忘了合法购买的持卡人、一位没认出家人所做扣款的家长，或者是被包装成账单错误的单纯买家后悔。对你的账目来说，是哪一种都不重要。无论如何钱都走了。

它与真正欺诈有何不同

真正的欺诈是陌生人使用一张不属于自己的卡，而商店内置的反欺诈工具正是笔直冲着它去的：设备信号、频率检查、被盗卡模式。友好欺诈会径直穿过这一切，因为每一个信号都是合法的。真实的账户、真实的设备、真实的卡、真实的购买。唯一虚假的是事后向银行提出的那个主张，而这个主张在你的风控检查通过很久之后才到来。

友好欺诈已经有多大规模

友好欺诈不再是可以忽略的零头，而且所有趋势线都指向同一个方向。Juniper Research 预测，受消费者对争议扣款态度转变的推动，到 2031 年它将占全球所有拒付的 28 percent。Chargebacks911 的 2026 Chargeback Field Report 是一项对超过 250 家商户的调查，发现 83.4 percent 的商户表示友好欺诈在过去三年上升，74.4 percent 的商户称其为中度或严重的担忧。

成本正随着数量一起加剧。2026 年的行业数据显示，一旦把手续费、损失的商品和处理成本都算进去，每一美元被争议的金额其真实欺诈成本约为 $5.13，而反击争议的商户在他们所争的案件中只赢约 43.8 percent，付出努力后净收回约 10.7 percent。最后这两个数字的教训不是说反击没有意义。而是说事后再反击是一笔糟糕的赌注，真正的钱在于一开始就不让争议得逞。

为什么友好欺诈让应用开发者付出的代价超过价格本身

真正扎心的数字从来不只是购买价格。它是价格加上你为履行这笔购买已经花掉的一切，而对于数字产品，几乎所有这些花费都发生在争议到来之前。退回一个未拆封的盒子是打个平手。对一件已消耗的应用内购买项目发起的友好欺诈拒付，则是叠加在一笔你无法收回的成本之上的亏损。

你已经付掉的交付成本

从争议往回倒着追这笔钱。生成的输出烧掉了你要为之付费的 GPU 分钟。这个功能运行了按 token 或按请求向你计费的 API 调用。客户下载的文件仍存在你正付费保管的存储里。如果这笔购买出资支付了给创作者的报酬或奖池，那笔钱早已离开你的账户。友好欺诈撤销了销售，却把上述每一项成本原封不动地留下。客户留下了价值，你留下了账单。

在 Google Play 上，这笔争议如今直接向你收费

直到不久前，两家商店上的拒付大多还是商店自己要承担的损失。这在 Android 上变了。对于在 August 3 2026 当天或之后下单的 Google Play 订单，Google Play 与开发者分担拒付成本，实际意味着一笔输掉的争议会向你收取购买价格减去 Play 服务费，再加上银行或卡组织的拒付手续费。那笔手续费由卡组织而非 Google 设定，行业报道通常将其定在每笔争议 $15 到 $25，一笔固定收费，可能远超一件低价购买的价格。

在 App Store 上，Apple 承担银行那一侧，你损失的是收益

Apple 是记录商户，因此对一笔 App Store 购买的卡拒付是在持卡人的银行与 Apple 之间解决的，你从来看不到那个案子，也没有为它产生的银行手续费。你确实会损失的是钱。当一笔退款被批准时，金额会从你的收益里扣出，而对于 Apple 确实转给你的那些退款请求，你的证据是你能施加的唯一影响。银行手续费的风险是一个 Google Play 的故事；损失收益的故事则属于两家商店。

你的证据仍算数的那段狭窄窗口

恰好有两个时刻，商店会暂停并在裁决之前向开发者索要证据，而友好欺诈正是它们存在的原因。两者都很短，而且一旦你错过，它们都会在没有你参与的情况下关闭。

Apple 的 12 小时 CONSUMPTION_REQUEST

当一位客户就一件符合条件的应用内购买项目向 Apple 申请退款时，Apple 会向你的服务器发送一条 CONSUMPTION_REQUEST 通知，并等待最多 12 小时让你调用 Send Consumption Information。你返回结构化数据：该物品是否已交付、被消耗了多少，以及你的退款偏好。Apple 仍然做出裁决，但你的回答是一项有记录的输入，也是唯一一处能对 Apple 上的友好欺诈退款进行反击的地方。

Google Play 的 24 小时 orders.reviewrefund

在 Android 上，触发点是一条 PendingRefundReviewNotification。从它到达那一刻起，你有 24 小时调用 orders.reviewrefund 方法，附上退款偏好和使用证据，即订单的交付状态与该物品的消耗状态。Google 会把这些纳入它的裁决，并在证据支持的情况下代表你向银行反驳这笔拒付。对于给定的一条通知，Google 只记录你的第一次调用，所以要在回应之前而不是之后收集好证据。

你永远碰不到的那些友好欺诈争议

并非每一次退款事件都给你说话的机会，弄清楚哪些是在你头顶之上决定的，会帮你只把力气花在有回报的地方。

• 一笔完成的拒付由银行终裁。一旦发卡银行站到持卡人那一边，向 Apple 或 Google 的任何申诉都无法推翻它。你唯一的影响是在裁决之前提交的证据。
• Google Play 的 48 小时自助退款是 Google 按其自身政策自行批准的。不会征询你的意见，只有当它以作废购买的形式出现时你才会被通知。
• 两家商店由客服批准的退款都是终局的，没有面向开发者的申诉渠道。
• 一笔未确认的 Google Play 购买会在大约 72 小时自动退款。那是一个集成缺口，不是争议，修复办法是在服务器端确认购买，而不是去反驳什么。

如何在友好欺诈发生之前让它变得可争议

你无法阻止客户打电话给他们的银行。你可以远远提前决定，随之而来的争议是可以回答的，还是一场自动的败仗。让友好欺诈可赢的一切，都必须在通知到达之前就已经存在。

在交付和消耗发生的那一刻就记录下来

两家商店索要的证据，即该物品已交付并被使用，只有在事情发生时就记录下来才具有说服力。记录每一笔购买授予了什么，以及它是否在使用时被消耗，而不是在争议落地之后再去重建。一次 reviewrefund 调用或一次消耗回应，其强度不会超过背后那些遥测数据。

让答案自动化，而不是让一个人来做

把 CONSUMPTION_REQUEST 和 PendingRefundReviewNotification 接入一个能自行汇集证据并回应的处理程序。一个 12 小时和一个 24 小时的计时器不能依赖某个人注意到收件箱。你赢下的那些争议，是每一次都在窗口之内被自动回答的那些。

只用可争议的案件来评判你的防护

把你的退款分成有审核窗口的和没有的两类。友好欺诈退款请求和拒付审核，才是挽回率有意义的地方，因为那里有一个你的证据能撼动的裁决。商店发放的退款携带的是信息，而不是对你防御能力的判决。RefundHalt 正是围绕这一区分构建的：它用你记录下来的交付和使用证据自动回应消耗请求和 reviewrefund 调用，并把不可争议的退款单独记在一本账里，让你的数字保持诚实。