有一个接口能返回某位客户在 App Store 的全部退款记录，本文说清楚它到底交还了什么

对于你的 App，Apple 会为每位客户账户上已批准的每一笔退款保留一份可查询的记录，一次调用即可返回。这个接口就是 Get Refund History，属于 App Store Server API，它会以签名交易列表的形式，交还该客户在 App Store 的完整退款记录。你传入一笔交易 id，就能拿回 Apple 退了哪些款，再拿它与你仍在开启的权限做对账。

为什么值得费这个劲。一笔你从未看见的退款，就是一笔你还在为之付费的退款。钱已经没了，但账户还活着，只要它活着，你每小时都在继续支出算力、模型 API 调用、存储，以及任何与该客户绑定的分成。你的退款通知本该在退款发生的那一刻就捕捉到它。Get Refund History 则是通知失灵时的兜底，在一次宕机之后、一次弄丢了 webhook 的部署之后，或者在一桩需要用一次调用看清全貌的客服工单里。

App Store 退款记录接口会返回什么

你对 App Store Server API 调用 GET /inApps/v2/refund/lookup/{transactionId}，用你调用其他所有接口时相同的 JWT 签名。路径中的交易 id 可以是该客户的任意一笔交易。Apple 把它当作身份标识，而不是过滤条件，会返回该客户在你整个 App 内已退款的购买：消耗型、非消耗型、自动续期与非续期订阅一并在内。此接口更旧的 V1 版本在单次响应中最多返回 50 笔退款，现已弃用。当前版本会翻页，因此面对历史很长的客户，你也无需处理一个巨大的负载。

响应就是三个字段

一笔已退款交易能告诉你什么

signedTransactions 中的每一项都是一个 JWS。用 Apple 的证书链验证它、解码它，你就得到一个普通的交易负载，其中填好了退款字段。下面这些是这里真正要紧的。

revision 令牌就是你不必反复重读整份列表的办法

使用这个接口最笨的方法，是每次都查一位客户并把每一页都走一遍。这能用，但对一位有五十笔退款的客户来说，那就是五十行你早已知道的记录，外加新增的那一行。revision 令牌的存在就是为了消除这种浪费。每个响应都带一个 revision。当 hasMore 为 true 时，你把它传回去以获取下一页。当你走到末尾时，就保留你看到的最后一个 revision。

这个接口不会做什么

在你据此动手之前，有一个预期要先放下。Get Refund History 是按客户维度，而非按 App 维度。你无法向它索要你 App 上周收到的每一笔退款。它只回答一个问题，即这个账户有哪些退款，而且你必须带着该账户的一笔交易 id 才能发问。开发者们不断撞上这堵墙，然后去找一个根本不存在的全 App 退款接口。

全 App 视图在别处。你的 App Store Server Notifications 流会在 Apple 批准每一笔退款的那一刻发出一条 REFUND 通知，而 Get Notification History 让你在一个日期范围内、按退款类型过滤地重放那条流。所以分工很清晰。通知及其历史给你全 App 的实时流。Get Refund History 按需给你一个账户的权威列表，这正是你在客服台或宕机之后想要的。

一笔漏掉的退款要花你多少钱

接口是管道。账单才是你铺这根管子的理由。那份列表里的每一笔退款都是已经退回的钱，而唯一还在你掌控里的变量，就是你还要为一个不再付费的账户继续支出多久。

你在继续付费，去服务一个已退款的账户

Apple 批准退款的那一刻，购买款项就没了。还在运转的是交付成本。对于一个真正为每位用户干活的 App，那就是算力、模型 API 调用、存储，以及任何与其用量绑定的创作者或合作方分成。一个你从未切断访问的已退款客户，就是一份你自掏腰包资助的订阅。以 Get Refund History 做对账，并根据你查到的结果撤销权限，就是在通知漏过去时把这个计费表关掉的办法。

退款原因为 1 是一份乔装的缺陷报告

如果你忽视 revocationReason，它会让你付两次代价。第一次代价是退款本身。第二次是同一原因带来的每一笔未来退款。当一款产品不断带着 revocationReason 1 回来，也就是你 App 中一个实际或感知到的问题，Apple 就是在把一份带标签的样本递给你，告诉你到底是什么让客户来要回他们的钱。按产品做趋势分析，你就能把这个漏洞补上，而不是一笔一笔地把它赔出去。

晚一点抓到，也强过压根没抓到

拒付在银行那边是终局，而且在另一家商店，如今还带着一笔由开发者承担的手续费。App Store 退款不是那样。它已经结清，但权益归你，你一旦知道就能撤销。所以即便是一笔你通过这个接口晚几天才发现的退款，也值得去发现。你要不回那笔钱，但你能止住它背后仍在跑着的支出。

这如何与通知、以及与 Google 契合

把这些部件当作一个系统来看。REFUND 通知是实时信号，随着 Apple 的裁定推送到你的服务器。Get Refund History 是针对单个客户、基于拉取的事实来源，是当推送失败、或当有人需要把完整账户摆在面前时你会发起的调用。在 Google Play 那边，形态是同一个思路、换了名字：一个 VoidedPurchaseNotification 实时推送，而 Voided Purchases API 是你拉取的那份列表。两家商店都给你一条流和一本账。错误在于只信那条流，因为流会丢。

用 RefundHalt 的方式把它接起来

一旦每个部件都就位，这个循环就很小。以一条 REFUND 通知作为触发。用 Get Refund History 做对账，好让一个丢掉的 webhook 永远不会留下一个还活着的已退款账户。解码每一笔交易，用 appAccountToken 或 transactionId 把它回连到你的用户，读 revocationReason，好让一笔缺陷退款被标记出来而不只是被归档，并撤销确切的那份权益，而不是整个账户。用 revision 令牌翻页，这样你读到的是新增退款，而不是旧的。

这一部分就是 RefundHalt 替你运行的。它监听退款通知，在需要权威列表时回落到 Get Refund History，验证每一笔签名交易，撤销那笔精确的购买，并保存 revision，让每一次遍历都只读发生了变化的部分。你能在数秒内切断访问，并得到一份干净的记录，说清谁被退了款、退的是什么、原因为何，而无需自己搭起轮询和 JWS 验证。