退单和退款的区别在于由谁决定，而只有一种是不可挽回的

有两个词经常被当作同义词来用。反正顾客都会拿回钱，谁还在乎到底是哪一种。可对于通过 App Store 或 Google Play 销售的应用开发者来说，退单和退款的区别决定了这个结果由谁掌控、你本可以做出什么改变，以及从本月起，这次款项撤销会从你账户里拿走多少。

简短版本是这样。退款是商店把钱退回去，由商店决定。退单是顾客的银行把钱拉回去，由银行决定，没有申诉余地。在这两种情况里，你所处的位置截然不同。下面来看它们在 Apple 和 Google 上分别是什么样子，商店真正会向你索要东西的两个时刻，以及两者之间的差距如今要花你多少钱。

退单和退款的区别在于由谁决定

剥去支付术语，有一个问题把两者区分开来：由谁做最终决定。退款是在商店自己的系统内部做出的决定。退单是在顾客的银行做出的决定，比任何商店设置能触及的范围还要往外一层。仅凭这一点，就决定了其余的一切，从你能否申辩到它要花你多少钱。

谁发起，谁决定

退款可以有两种发起方式。顾客向商店索要退款，或者你自己发起退款。无论哪种，商店，也就是 Apple 或 Google Play，都会批准并把钱退回去。退单只有一种发起方式。顾客完全绕过商店，直接向自己的银行或卡组织对这笔扣款提出争议，银行便从商店的支付系统里把钱扒回去。商店没有选择它，你也没有。

卖家是商店，不是你

这一点常让从传统电商转行过来的开发者栽跟头。当你通过 App Store 或 Google Play 销售时，你不是记录在案的商户。Apple 和 Google 才是。顾客的信用卡账单上写的是 Apple 或 Google，而不是你公司的名字。所以当那位顾客对扣款提出争议时，退单会先落到商店的支付系统上。跟银行通电话的不是你。你只能通过商店得知，前提是商店愿意告诉你。

两者对照

退款在 App Store 和 Google Play 上是什么样子

大多数退款不是一场让你能参与的对话。商店接下请求，对照自己的规则核查，然后把钱退回去。你事后才被告知，前提是你接好了传递这个消息的通知。

Apple 先决定，再告诉你的服务器

Apple 顾客在 reportaproblem.apple.com 上请求退款，Apple 有自购买起最长 90 days 的时间来受理这项请求以供审核。Apple 会自行审核每个案例并做出决定。当它批准退款时，你的服务器会通过 App Store Server Notifications V2 收到一条 REFUND 通知，该交易此时会带上一个 revocationDate。当它拒绝请求时，你会收到 REFUND_DECLINED。如果 Apple 之后撤销了一笔已经批准的退款，你会收到 REFUND_REVERSED，这笔销售又回来了。在这些情况里，你都没有投票权。你只是做出反应。

Google Play 退掉大多数购买时不会问你

Google Play 允许顾客在购买后 48 hours 内直接从账户自助退款，全程完全没有开发者参与。超过 48 hours 后，顾客会被引导到你这里，你可以按自己的政策批准或拒绝。客服可以发起退款，而一笔未确认的购买会在大约 72 hours 后被自动退款。所有这些都在 Google 那一侧运行。你通过一条已作废购买通知或 Voided Purchases API 看到结果，你的任务是撤销访问权限，而不是批准退款。

商店真正会向你索要东西的两个流程

在两家商店里，恰好有两个时刻，商店会停下来，在做决定之前向开发者索要证据。当顾客请求退款时，Apple 会发出一条 CONSUMPTION_REQUEST，给你 12 hours 通过 Send Consumption Information 附上使用数据来回应。Google Play 会发出一次退单审核，给你 24 hours 通过 orders.reviewrefund API 来回应。其余一切都在没有你的情况下决定。这两个窗口是你的输入唯一能改变结果的地方，正因如此它们值得自动化，其余的则值得监控。

退单是什么样子，以及它为什么不可挽回

退单不是多几个步骤的退款。它是一套不同的机制，决策者也不同，而这改变了你能对它做些什么。

是银行把钱拉回去，不是顾客

在退单里，顾客告诉自己的银行这笔扣款有问题，可能是欺诈、无法识别，或从未交付。银行默认站在自己的持卡人一边，撤销这笔交易，通过卡组织把钱拉回去。商店没有批准它。在任何人问起产品是否已交付之前，钱已经没了。这就是为什么退单又慢又重，而退款又快又干净：它要走卡组织的争议流程，那需要数周或数月，而不是几分钟。

银行的决定是最终的

你没法像撤销退款那样推翻一次退单。银行一旦裁定，那个裁定就成立了。你唯一能施加影响的地方，是在它被决定之前。在 Google Play 上，银行发起的争议可能会开启一次审核，Google Play 会给你的服务器发一条通知，附带一个 24 小时的倒计时。通过 orders.reviewrefund 附上退款倾向和真实的消费证据来回应，Google Play 就会把你的输入纳入它替你申辩退单的方式里。错过这个窗口，争议就会在唯一知道产品如何被使用的一方缺席的情况下了结。

每一种到底要花你多少钱

很长一段时间里，诚实的答案是：退单和退款对应用开发者的成本大致相同，就是这笔销售，加上你为交付它已经花掉的一切。本月起，这对 Google Play 开发者来说不再成立了。

退款从来都不是唯一的数字

无论这次撤销是退款还是退单，那笔付款从来都不是你唯一的成本。一段生成的视频、一批模型 API 调用、一笔创作者分成、你预置的存储，所有这些钱在你交付订单的那一刻就离开了你的账户，而当扣款被撤销时，它们一分都不会回来。销售是看得见的数字。算力、API 调用、存储和分成，才是那些已经落袋的数字。要以已交付的价值来为这次撤销申辩，绝不要以顾客等了多久来申辩，因为流逝的时间不是成本，Apple 和 Google 也不把它当成本。

从 2026年8月3日 起，退单会多出一笔银行手续费

这就是两者不再花费相同的地方。到目前为止，Google Play 一直吸收退单的下游成本。对于在 2026年8月3日 之后下的订单，Google Play 会把这笔成本转给开发者。争议败诉时，你要退回扣除 Play 服务费后的购买款，除此之外，你还要支付金融机构收取的退单手续费。Google Play 仍然继续承担服务费那一部分。退款不带这笔银行手续费。所以一笔以退单收场的扣款，如今花你的钱严格多于同样一笔被退款的扣款，多出来的就是银行的手续费。

这一变化背后的规模

Google Play 表示，它在 2025 年拦截了 US$3.4B 的欺诈与滥用，并且在整个 2026 年仍在增加欺诈检测。把退单成本转到开发者身上是这股推力的一部分。它给了你一个直接的理由，把证据喂进审核流程，好让系统去申辩更多不正当的争议。你的证据才让申辩成为可能，而一份空白的回应，就是投票让一次善意欺诈式的退单，在你的钱上成立。

如何让退款不变成退单

最便宜的退单，是那笔从未发生的退单，因为这笔订单先被退了款，或者被一份早已备好的证据申辩掉了。这一切都不需要有人在恰当的时刻醒着盯着。它需要的是在争议发生之前就把管道铺好。

抢在银行之前自己把坏订单退掉

如果一笔订单明摆着要被提出争议，自己把它退掉比输掉退单更便宜。你自己发起的退款不带银行的退单手续费。在 Google Play 上，你只需一次 orders.refund 调用，就能退掉任何不到三年的订单，撤不撤销访问权限都行。抢在顾客找上银行之前做到这一点，你就把一笔银行手续费加一笔损失的销售，变成了仅仅一笔损失的销售。

自动回应这两个证据窗口

Apple 的 12 小时窗口和 Google Play 的 24 小时窗口，对机器来说很从容，对必须一直盯着的人来说却很折磨。回应应当是自动的：通知进来，查出账户，组装好消费数据，一次调用出去，中间没有人。这正是 RefundHalt 替你运行的部分。我们侦听 CONSUMPTION_REQUEST 和 Google Play 的退单审核，把订单匹配到我们本就在追踪的使用情况，并在窗口内附上退款倾向和真实的消费证据来回应。

提前附上身份标识并记录消费

在争议发生时你需要的证据，必须在争议之前就已存在。给每一笔购买设置一个账户标识符，让一条通知能直接映射到某个用户，在 Apple 上是一个 appAccountToken UUID，在 Google Play 上是一个不超过 64 characters 的哈希 setObfuscatedAccountId，绝不要用明文个人数据。记录下每一笔付费订单交付了什么、何时交付、交付给谁，以一种你能随时转换成消费百分比的形式。做到这些，那个狭窄的窗口就足够了，因为当令牌到来时，案子早已备好。