App 内购买的新功能

♪ 柔和乐器演奏的嘻哈音乐 ♪ ♪ Dani Chootong：大家好 欢迎收看 “App 内购买的新功能” 我是 Dani StoreKit 团队的工程师 今天将由我和同事 lan 一起 为大家介绍 今年在 App 内购买中 添加的新功能 去年 我们推出了 StoreKit 2 这是一组全新设计的 API 用于简化 App 内购买的步骤 StoreKit 2 使用现代语言功能 包括使用了 async/await 模式的 Swift 并发 在服务器端 我们用一组全新 App Store Server 端点 补充了这些新的 StoreKit 功能 这些服务器端点方便您在服务器上 检索交易信息 查看订阅状态 我们还发布了第 2 版 App Store Server Notifications 方便您在服务器上 跟踪订阅周期 以上 API 以及 新版 StoreKit 模型的 增强功能 将由我来为大家介绍 之后 将由 Ian 为大家介绍 一些超赞的服务器更新 包括 App Store Server API 增强功能 以及用于 App Store Server Notifications 的全新 API 首先 我将介绍用于 验证 App 购买的 全新 App Transaction API 其次 我将深入介绍 StoreKit 模型的 新增属性 即全新 SwiftUI 友好型 API 用于兑换订阅优惠代码 并要求用户评价 App 再次 我将为您 介绍 StoreKit Messages 该 API 用于向用户显示 App Store 的消息 最后 我将介绍 即将新增的增强功能 该功能从旧版 StoreKit API 迁移到新版时 能保留您的 applicationUsername 讲解过程中 我将用我常用的 App Food Truck 为大家演示 在 Food Truck 这款 App 中 我经营着一个虚拟甜甜圈餐车 走遍各个城市售卖甜甜圈 那我们现在就开始吧！ 先来看看 App Transaction App Transaction 是我们新推出的 API 用于验证 App 购买 App 交易相当于为设备上 运行的 App 购买签名信息 该 API 使用 JWS 签名 取代了原先 StoreKit API 中 App 收据的 App 详情 如交易验证一样 StoreKit 为您的 App 交易 执行自动验证 但如果您愿意 您也可 自行验证 验证 JWS 签名有据可查 您可参考公共文档 执行验证 StoreKit 在必要时可自动更新 App 交易 但在极少数情况下 用户 认为交易出现问题 也可手动刷新 您应在 App 中提供 UI 允许用户刷新 App 交易 该方法仅用于响应用户操作 因为刷新 App 交易 会提示用户进行身份验证 App Transaction 受欢迎的原因并非只有防止诈骗 如果您希望把 商业模式从付费 App 转换成 提供 App 内购买项目的免费 App 如果您好奇哪些客户 预购了您的 App 或想了解您 App 的购买时段 均可在 App Transaction 中实现 在 App 收据中 收据有效负载 结合了您的 App 购买数据 以及所有发起的 App 内购买 这在 StoreKit 中 分为两个独立组件 第一个组件是交易历史 StoreKit 的交易 API 可以让您在设备上 查看用户所有的 App 内购买 历史记录 该 API 可以查找 您所需要的确切信息 包括用户最新交易 未完成的交易和当前授权的交易 如您倾向于 在自己的服务器上执行运算 还可从 App Store Server API 中 获取用户的购买历史记录 Ian 稍后将对该功能的亮点 进行补充 第二个组件是 App Transaction 包含让您的 App 在设备上有效运行 所需的数据 使用 App Transaction 能轻松 验证您的 App 购买 稍后我将举例说明使用方法 但在此之前 我先来向您介绍一下 我常用的这款 App 的背景 在 Food Truck 上 我可以配送甜甜圈 查阅基础社交信息流 查看销售历史 将所有这些信息保存在数据库中 需要持续支付费用 那么为了便于支付 我要一次性购买 年度销售记录表 此外 我还想增强社交信息流推送 这样不仅能看到他人如何评价 我的餐车 我还能提供工具 和客户展开互动 这就涉及到订阅服务 可以按月度或年度订阅 Food Truck 起初是一款付费 App 我打算将其转变为 支持 App 内购买的免费 App 但我又不希望忽略 当前已经购买了 Food Truck 的用户 所以 我会使用 App Transaction 保证已购买 Food Truck 的用户 继续访问其支付的高级内容 这是 Food Truck 的时间线 在最初的版本中 Food Truck 是一款 售价 4.99 美元的付费 App 1.0 版本提供甜甜圈配送 基础社交动态和销售记录表 后来 在发布 8.0 版本时 我改变了商业模式 现在 Food Truck 虽然免费 但包含 各类解锁高级功能 的 App 内购买项目 年度销售记录表现在是一次性购买的 非消耗型订阅项目 现在还有 全新的获取高级 社交动态的订阅服务 为您提供高级体验工具 现在让我们来看看会受此影响的 两类不同的用户 Alice 发现了 Food Truck 2.5 版本的 App 决定在虚拟世界中分享 她对甜甜圈的热情 所以 她以 4.99 美元的 价格购买了这款 App 开启了甜甜圈售卖之旅 第二位用户 Bob 通过朋友知道了 Food Truck 并在 8.2 版的 App Store 中 免费下载了这款 App 在此情况下 在这款 App 免费前 购买了该 App 的 Alice 仍可以访问 其已经支付的所有高级内容 仍可以选择订阅购买 高级的社交动态信息流 但不可否认 年度销售记录表已经包含在 她的付费版 App 中了 而 Bob 则是免费下载了该 App 两位都要完成 App 内购买 才可使用其中的解锁功能和内容 那么 让我们看看如何 通过代码中的 App Transaction 实现这一目标 首先 我将调用 AppTransaction.shared 发起 App 交易 通过该操作得到 一个含有我的 App 交易的 VerificationResult 在结果中 AppTransaction 类型 包含 JWS 有效负载 接下来 我将打开结果 如果结果未经验证 那就要 提醒用户 其 App 购买 可能未经 App Store 验证 然后 我就可以 提示用户刷新 App 交易 与此同时 我将为用户 提供 App 短时体验机会 如果结果已经验证 那我将借此机会 检查用户是否购买了我的 App 购买了我的 App 的用户 有权获取其所支付的服务 为此 我将利用原始 App 版本的属性 该属性可让我了解用户首次下载 该 App 时的版本 8.0 版本是包含了 App 内购买项目选项的 免费版本 我将把用户下载的 原始 App 版本导入函数 检查用户是否在 8.0 版本发行前 就购买了我的 App 以此为依据 我就可以决定 如何为用户提供高级内容 对于像 Alice 这类 购买 App 的用户 我将向其提供购买时 有权获得的内容 为其解锁甜甜圈售卖的 年度销售记录表 我还想查看 两位在 App 内购买中的 其他行为记录 以便为他们提供相关内容 此外我同时也可以确定 某用户 (比如 Bob) 是在 我转变商业模式后 才下载了我的 App 这正好可以 检查用户当前授权的交易 如此我就可以 解锁其付费的功能和内容 只需几行代码 我就能验证我的 App 购买 检查用户是否下载了 该 App 的付费版本 并且不论用户 是否购买了我的 App 我都能立即提供高级内容 使用 App Transaction 您可轻松为用户 提供支持 无论其是老用户 还是刚刚下载 App 的新用户 现在我来为大家讲解 StoreKit 模型中的新增属性 首先是价格区域设置 价格区域设置 如今包含在 StoreKit 产品中 您在使用原先购买的 API 时 可能对此已有所了解 接下来 我将深入 介绍服务器的环境属性 现在 您可以知道交易或续订 发生时处于的服务器环境 然后 我会谈谈 最近订阅开始日期属性 它能帮助您根据用户的订阅模式 明智地决定如何为其提供服务 最后 我将介绍利用上述属性 在 Xcode 中使用 StoreKit Testing 时的 特别注意事项 上述属性在较旧的操作系统中 会返回标记值 对此我来 稍作一点解释 StoreKit API 的设计考虑了灵活性 所以我可以很自豪地说 以上新属性就算是在去年 未曾配备类似属性的操作系统上 也可以使用 要做到这一点 您只需要使用 Xcode 14 来构建 您的 App 您可在 先前的操作系统中 获取上述新增属性 之所以能如此 是因为 上述新增属性 被编译到您的 App 中 因此 用户在更新版本后 就能够使用这些增强功能 无需更新其操作系统 但是 在使用新增属性时 要牢记一件事 当您在旧版操作系统中的 Xcode 中使用 StoreKit 测试时 新增属性会返回标记值 这里说的标记值 指的是占位符值 不是您使用的实际值 我来解释一下原因 沙盒和生产环境 通过提取 App Store 服务器响应的值 来利用这些属性 不过 Xcode 中的 StoreKit 测试 是独立于 App Store 服务器 运行的本地测试环境 这意味着我们无法将这些属性的值 回传到先前的操作系统中 您可将测试设备 更新到新的操作系统中 从而轻松绕过此限制 随后即可在本地环境中 测试上述值 我们来讨论一下几种 利用新增属性的情况 首先是价格区域设置 StoreKit 产品已经 具备了显示价格属性 用以标记购买价格 但利用价格区域设置 您可将产品十进制价格中得出的 数字格式化 如果您有年度订阅功能 即可以此为契机 向用户展示每月的费用 在此示例中 您可以看到年度订阅服务 每月费用为 4.17 美元 或者您想向用户展示 订阅您的年度服务比订阅月度服务 节省了多少开支 利用以上信息 您的用户可以 在考虑您的购买选项时 做出明智的决定 我们继续来讨论环境属性 环境属性可以 在交易和续订信息中找到 该属性能让您了解交易或续订信息 源于哪个服务器环境 例如 Xcode、沙盒或生产环境 您的 App 会在用户购买后 将交易信息发送到您的服务器 以便记账和分析 当您的 App 生成交易时 交易可能来自任何服务器环境 和您一样 我也不想让 不相关的测试数据干扰分析 因此 了解环境可帮助您 过滤掉发送至服务器的 不必要的信息 最后 我们来看看 最近订阅开始日期 最近订阅开始日期可在 产品订阅信息中查看 指的是连续订阅 最近开始的日期 如果任何两个订阅期 之间没有超过 60 天 则视为连续订阅 请记住 该期间可能包含 用户未订阅您产品的时间 因此不可将其作为 用户已订阅天数的指标 最近订阅开始日期可帮助您 确定您和用户之间的粘度 对于忠实用户 您可为其提供奖励 鼓励其继续使用您的产品 或者 若您注意到用户 已取消订阅您的服务 您可以借此机会 激励用户再次使用您的产品 赢回流失的顾客 之前我提到过 我们要仔细查看 新增属性的标记值 请注意 这里说的标记值 指的是占位符值 用于指示缺失的实际值 新增属性的标记值很容易识别 当您处理价格区域设置时 标记值是带有 标识符 xx_XX 的区域设置 对环境属性而言 标记值是一个空字符串 最后 就最近订阅开始日期而言 此值为 Date.distantPast 所幸 标记值的出现 是可预测的—— 您只会在较老的操作系统中的 Xcode 中使用 StoreKit 测试时 遇到该值 您可通过更新测试设备解决该问题 现在您已经了解了 我们在 StoreKit 模型中 添加的增强功能 我最喜欢一点是 新增属性 可以一直向后兼容到 推出该模型的操作系统 这样您的用户只需更新 App 就可立即使用新增属性 当您对价格值执行算法时 价格区域设置可帮助您正确格式化 使其与 App Store 的 区域设置相匹配 对于交易和订阅信息 环境会准确告知您 具体来源 因此若您将 这些数据存储在服务器上 您就可以根据环境 对其采取相应措施 最近订阅开始日期可助您了解 用户忠诚度 因此您可为长期用户 定制具体优惠 或者您可以 为已退订的用户提供激励 若您想知道环境 以及最近订阅开始日期 可在 App Store Server API 和 App Store Server Notifications 中查看 这是 Ian 之后要讨论的内容 现在我来介绍一下 我们为兑换优惠代码和请求评价 提供的全新 SwiftUI API 优惠代码可帮助您 通过提供折扣或限时免费订阅 获取、巩固并赢回订阅者 在 App Store Connect 中 您可以创建唯一命名的 自定义代码 然后您可设置最大赎回限额 选择是否设置截止时间 我们来看 SwiftUI 在 您的 App 中呈现 优惠代码兑换表的方式 这是一个 SwiftUI 视图 带有可触发优惠代码兑换表的按钮 优惠代码兑换表 在 SwiftUI 中 有自己的视图修饰符 视图修饰符使用简单 只需绑定布尔值便可启动程序 一旦解除优惠代码表 您就会得到显示 该表是否成功呈现的结果 当用户为您的 App 兑换优惠代码时 最终交易结果 就被发送到事务监听器 因此 一定要在您的 App 启动后 设置一个事务监听器 使其在 App 运行时接收和更新事务 优惠代码视图修饰符 将从 iOS 16 起 接下来 我来介绍一下 对请求评价的更新 获取用户反馈尤为重要 评价可能是潜在新用户 下载 App 的决定性因素 其他用户或许也想通过评价来提供 反馈或建议 无论哪种情况 我们都希望为您提供有利工具 便于您向用户请求评分 让用户知道您在倾听他们的意见 方便您继续与其互动 我们再来看一下代码 这个简单的视图 演示了请求评价的 API 在 SwiftUI 中 有一个环境值 名为 requestReview 您可使用此值来获取 RequestReviewAction 的实例 当您准备好请求评分时 只需将实例作为函数调用 请求显示评价提示 您可选择恰当时机请求用户 对您的 App 进行评价 不过 您需了解 该提示 在 365 天内最多只会 向用户展示 3 次 您也不应请求用户 对同一版本的 App 进行多次评价 避免评价提示打扰用户 请求评价的良好时机应在用户 进行良性互动之后 例如在电子商务 App 上 完成购买 或在游戏中完成关卡 最后 用户可禁止在其设备上 发送请求 因此您不应 再次向用户发送评价请求 以上 API 一定会 让您的 SwiftUI App 使用便捷 接下来 我为大家介绍一下 适用 StoreKit 消息的新 API StoreKit 消息是在您的 App 上 显示的一张表格 用于向用户展示重要信息 信息由 App Store 出售 每一条消息的出现都有原因 包含在消息元数据中 当您的 App 在前台运行时 就能检索到 StoreKit 消息 举个例子 我们看一下 其中一条消息原因——同意涨价 当您提高订阅价格时 需要经过用户同意 App Store 就会通过 电子邮件、推送通知 和 App 内价格同意书的方式 通知受影响的订阅者 在此情况下 App Store 需要用户 在以更高的价格续订之前 同意您新制定的价格 因此 如果您决定 向用户收取更多订阅费用 且若用户尚未回应涨价 那么当其打开您的 App 时 就会出现涨价同意书 默认情况下 StoreKit 消息 会在用户前台运行 您的 App 时显示 要求用户就您的 App 进行某些操作 我们来回顾一下 以您的 App 为起点 当您的 App 进入前台时 StoreKit 会检查 有无待显示的消息 如果有 StoreKit 会在 App Store 中记录 App Store 会将相关信息 返回到 StoreKit 这时 StoreKit 会检查您的 App 是否 设置为接收消息 您可通过在 App 上 设置消息监听器来实现 这一点我很快就会讲到 如果您的 App 设置了消息监听器 StoreKit 会将 有关信息发送到您的 App 然后由您决定是否 让您的 App 显示消息 或者推迟显示 若您未设置消息监听器 StoreKit 通过在您的 App 上 显示消息表来立即显示消息 我来介绍如何在代码中执行此操作 但在这之前 我先解释一种情况 在这种情况下 控制 App Store 消息的呈现 非常有用 在 Food Truck 这款 App 中 我可以自定义 送往不同城市的甜甜圈 在此期间 若有消息发送到我的 App 上 那么消息表的突然出现 会扰乱用户 所以我要利用消息 API 控制消息出现的时间 来避免此类情况 现在来看代码 这是一个甜甜圈编辑器的简单视图 之前提到过 待处理消息 会在您每次 前台运行 App 时发送 所以 我想在 每个视图中设置一个消息监听器 来推迟消息的呈现 在位于编辑视图时 我将添加一个绑定数组来收集 传送至我 App 的所有消息 这个步骤很重要 因为若不设置消息监听器 StoreKit 将在 我前台运行 App 时 立即显示消息表 视图一出现 我就设置了消息监听器 为此 我将设置一个任务 该任务会在 消息类型上迭代一个静态属性 该属性是一个异步序列 而且我可以在消息进来时立刻接收 就我的用途而言 我将在待处理的 消息数组中保存消息 由于每次在前台运行 App 时 都会发送待处理消息 您的 App 会多次接收同一条消息 因此我可以 避免将重复的消息添加到数组中 然后 一旦该视图消失 父视图中就可显示消息 这是包含甜甜圈编辑器链接的 父视图 在这里 我收集了 需要在待处理消息数组中 显示的所有待处理消息 那么 如何显示以上待处理消息呢？ 现在有一个 displayStoreKitMessage 环境值 该值为您提供 DisplayMessageAction 的实例 您可以利用其显示特定消息 视图出现时 我将循环访问待处理消息 并调用 displayStoreKitMessage 传递我要显示的消息 StoreKit 负责呈现消息表 之前 我提到过相同的消息 可能会多次传送到您的 App 那是因为消息在呈现给用户后 才被标记为已读 因此 StoreKit 会确保 每条不同的消息 只呈现一次 这一点是 Messages API 的 快速实现 再次提醒 StoreKit 消息 会在您前台运行 App 时 发送给您 所以您需要 给每一个视图设置 消息侦听器 以便控制 消息显示的时间 您可确保消息在恰当的时机出现 保证用户的良好体验 或者您也可以为某些消息类型 自定义逻辑 在向用户发送涨价同意书前 您可能想利用涨价同意信息 告知用户 您提供的附加价值 最后 我们来看一下用户购买后 StoreKit 将 applicationUsername 保存为 appAccountToken 的方式 如果您的服务器上有用户帐户系统 您可能已经在使用 applicationUsername 属性了 applicationUsername 是您创建的字符串 用于将交易与您服务中的 用户帐户相关联 在 App 内购买的原始 API 中 您在向支付队列添加付款时 会设置 applicationUsername 值 尽管 applicationUsername 接受任何字符串 但我们建议您提供 UUID 的字符串表现形式 在提供 UUID 字符串后 StoreKit 会保留该值 您会在 队列更新的交易中看到它 如果您未向 applicationUsername 提供 UUID 字符串 StoreKit 可能不会保留该值 无法保证在您将支付交易添加到 队列和队列更新交易之间 该值将保持不变 您提供 UUID 字符串表现形式后 就能识别哪些用户帐户 开始并完成了一笔交易 在现代 StoreKit API 中 我们将此概念实现为 appAccountToken 的购买选项 并需要 UUID 格式 现在 当您在付款期间将 applicationUsername 设置为 UUID 字符串时 App Store 服务器就会将其 存储为 appAccountToken 所以您会看到其 UUID 出现在 App Store Server API 返回的签名交易信息 和 V2 App Store Server Notifications 中 并且其作为 UUID 在现代 StoreKit 交易 API 中 可与 appAccountToken 兼容 因此 您可确定在将代码库 更新到现代 StoreKit API 时 您用于 applicationUsername 的 UUID 在 StoreKit 交易中 保存为 appAccountToken 我们今天接触了很多概念 在讲解服务器更新之前 我们先来回顾一下 今年 StoreKit 的更新内容 我们讨论了用 App Transaction 验证您的 App 购买 在 SwiftUI 中 兑换优惠代码并请求评价 以及控制 StoreKit 的消息呈现 我们谈到价格区域设置、环境 以及最近订阅开始日期等新增属性 还讲述了将 applicationUsername 设置为 UUID 字符串以 将其保留 为 App 帐户令牌的重要性 我强烈推荐您观看接下来的讲解 “StoreKit 测试中的新功能” 如果您需要重新了解 StoreKit 2 API 请查看去年的 “Meet StoreKit 2”一期 接下来就交给 Ian 由他为您介绍 App Store 服务器的更新内容 Ian Zanger ：谢谢 Dani 大家好 我是 Ian App Store Server 团队的工程师 既然您已经了解了 使用 StoreKit 进行 App 内购买的最新消息 那么我就换个角度来谈谈服务器 首先 我来回顾一下 过去一年的最新进展 然后再介绍 App Store Server API 和 App Store Server Notifications V2 的 新增亮点 我们开始吧 去年收获颇丰 我们为您带来了一整套 搭载 App Store Server API 和 App Store Server Notifications V2 的全新端点 包括支持以上所有新功能的 完整的沙盒测试 我们分享了如何使用 Get Transaction History 端点 获取用户 App 内 购买的完整历史记录 或 Get All Subscription Statuses 端点 以便随时了解 用户订阅状态 上述两个端点都可便于切断 用户的 originalTransactionId 这样您只需存储这一简单的值 就可以访问数据宝库 我们还涉猎到 App Store Server Notifications V2 简化服务器上​​的事件处理 并补足 App Store Server API 的方式 利用版本 2 通知 App Store 服务器 会直接调用您的服务器 在有新版本时 通知您更新 App 内购买 简化后的通知类型和子类型 便于您理解具体情况 您可借此跟踪 App 内订阅 和其他事件相关的变动 利用所有这些数据源 我们想让数据尽可能便于解析 收据现在已成为历史 因为新增服务以签名的 JSON 格式 提供 App 内数据 您因此可以轻松解析 并相信其来自 App Store 服务器 去年对于 App Store 服务器来说是重要的一年 如果您致力于更新服务器代码 以便使用所有新增功能 那么这一年对您或许同样重要 请放心 努力将继续得到回报 因为我们为 App Store Server API 和 App Store Server Notifications V2 带来了强大的增强功能特性 这就是我们一年的历程 如果您在听完今年的更新后 想复习一下 请务必查看 WWDC21 演讲 “管理服务器上的 App 内购买”、 “认识 StoreKit 2” 以及“支持顾客和处理退款” 现在我们继续讲解为 WWDC22 的 App Store 服务器做的全新升级 首先 我来分享一些关于交易 和续订信息字段的更新 接下来我为您讲述 App Store Server API 中 新的增强功能 最后 我将分享即将用于 App Store Server Notifications V2 的亮点新功能 现在我们来深入探讨第一个话题 交易和续订信息中的新字段 此前 您从 Dani 那里 了解到 App 内购买中 交易和续订信息的 新字段 上述字段 即环境和 recentSubscriptionStartDate 也会出现在您从 App Store Server API 和 V2 App Store Server Notifications 中 收到的交易和续订信息的 有效载荷中 让我们重新审视一下 您希望从包含以上新字段的 App Store 服务器中收到的数据 首先是交易信息有效载荷 解码后我们可以在这里看到 在底部 您可以看到 我们的新字段：环境 您可以清晰地知道 交易是否发生 在生产或沙盒环境中 接下来是续订信息有效载荷 解码后仍可在这里看到 如您所见 环境字段也出现在这里 以供您参考 此外 recentSubscriptionStartDate 现在将出现在 每个续订信息有效载荷中 这是用户在最近的续订字段中 首次订阅购买的开始日期 它会忽略 60 天及以内的时间间隔 recentSubscriptionStartDate 是了解 用户忠诚度的简单方法 但如果您想了解更多细节 包括服务订阅间隙的时间和长度 您可调用 Get Transaction History 端点 并检查用户 续订购买的完整历史记录 若想进一步了解细节 使用 App Store Server Notifications V2 App Store 服务器就会自动 向您的服务器发送用户订阅更新 这些通知可让您最大限度了解 更新偏好变化、优惠代码兑换 计费失败等事件的时间 如您所见 recentSubscriptionStartDate 为确定用户忠诚度 完善了一系列选项 利用这些工具可定制优惠 奖励您最忠实的用户 现在让我们来看 Get Transaction History 端点中便利的增强功能 利用 Get Transaction History 端点 您可以在 App 上获取用户购买的 完整历史记录 端点响应是分页的 因此您可在合理的 区块中处理这些数据 每个响应都包含一个 修订令牌 您在下一个请求中 提供该令牌即可获取下一页 页面按修改日期排序 这就意味着每个后续页面都包含 最近修改的交易 我们看看其工作模式 您调用 Get Transaction History 端点 并提供 originalTransactionId App Store 服务器 将为该用户返回至多 20 个签名交易 还会返回一个更新的修订值 您将在下一页请求中 为该用户提供此值 您会看到 当响应中的 hasMore 字段 为真时 还有更多可用数据 假设在这种情况下 还有另一页可用数据 您向端点发出另一个请求 其中包含了第一个响应中的修订值 那您收到的下一页数据 其中就包括更新的修订值 hasMore 现在是错误的 因此您就知道了 最新的交易数据 此外 您注意到 响应中的最终交易 好像之前见过 这就是您在第一次请求时收到的 20 个签名交易中的一个 这意味着交易一定已被修改 所以它被放回了排序首位 现在您可以检查该交易的数据 看看发生了什么变化 这时 您会注意到 revocationDate 和 revocationReason 字段已被填充 这意味着交易被撤销 您可以撤消任何与购买相关的内容 来采取行动 最好的办法是将最终响应的修订值 与您用于识别用户的 originalTransactionId 一同存储 这样下一次您为该用户调用端点时 就可以提供该修订并了解 只取回自您上次请求后被修改的 新交易数据 如您所见 Get Transaction History 端点 为您提供了一种检索 一套全面 App 内购买数据的 简单方法 但有时它或许过于全面 某些用户购买历史较长 有好几年 对于这些用户 此端点可能会返回 数百种类型的购买数据 即使有页面 处理起来也较繁琐 这就是今年我们 要用各种新的排序和过滤选项 增强该端点的原因 现在您可以告知我们 您想要的确切初始数据 节省服务器处理时间 并减少所有可用页面 所需的网络调用次数 如果您想在第一页看到 最近修改的购买数据 可按修改日期降序排列 您还可以按几个 有用的字段进行过滤 例如产品类型、产品 ID 家庭共享状态等 要应用上述排序和过滤选项 只需将其作为查询参数附加到您对 Get Transaction History 端点的请求中 我们进一步来看看其工作方式 在这里您可以 看到新增的全部参数选项 可能看起来很熟悉 因为大多数都 来自交易信息有效负载 您可以混合匹配这些参数 以得到具体结果 例如 我们或许只想获取 一位用户自今年年初以来的 非消费性购买数据 并希望排除任何已撤销的购买 那么我们构建自定义请求 将 productType 设置为 NON_CONSUMABLE 并将 startDate 指定为今年年初 以毫秒为单位显示 最后 我们将 excludeRevoked 设置为 true 请求就构建完成了！ 由于我们没有选择排序顺序 响应将默认为 按升序修改日期排序 即便请求已十分具体 也可能有多个购买页面需要检索 对于后续请求 我们应该确保 除了先前响应的修订 包含完全相同的查询参数 为了更加灵活 其中有三个过滤器字段支持多个值 因此您可以过滤与所提供值 至少有一个相匹配的购买数据 该字段为 productType、productId 和 subscriptionGroupIdentifier 要为这些参数提供多个值 只需多次对其定义 接下来我们继续讨论 App Store Server Notification 更新 使用 App Store Server Notifications V2 您可将服务器提升至更高水平 V2 通知提供了 关于 App 内购买的详细内容 使其独树一帜 这尤其方便您跟踪 App 中提供的 自动更新订阅生命周期 您可以利用该内容巩固用户 赢回流失用户 解决用户支持请求等 了解了以上妙用 您可能想知道究竟如何开始 与其他新功能一样 最好以沙盒测试环境为起点 这就是为什么去年 我们要在 App Store Connect 中添加 设置单独服务器 URL 的功能 以便在沙盒中接收 App Store Server Notifications 注册您的服务器 URL 后 您需要确认您的服务器 正在接收来自 App Store 服务器的通知 您可以设置一个沙盒帐户 以便通过用户操作触发通知 例如 假设您使用该沙盒帐户 首次购买订阅服务 您会收到 SUBSCRIBED 类型 V2 通知 和 INITIAL_BUY 子类型 若没有收到通知怎么办？ 您或许会怀疑是否是服务器 或您为触发通知 而操作的步骤出现了问题 刚开始时 这种情况会产生 很多不确定性 我们希望简化设置 便于您 轻松验证 App Store Server Notifications 是否发送至您的服务器 因此在今年 我们推出新的 Request a Test Notification 端点 通过调用这个简单的端点 您可要求我们发送 TEST 类型的 V2 Notification 至 App Store Connect 中 为您的 App 注册的服务器 URL 新的 TEST 通知类型为 该端点专用 您可以在沙盒或生产环境中调用端点 为任一环境测试您保存的 URL 使用这个新端点 可以快速测试新的服务器 URL 和配置 我们来看看如何简化首次设置 如果您只是想触发第一个通知 那么无需设置沙盒帐户 或执行购买 只需在您要测试的环境中 调用新端点 即可收到一个确认您请求的 HTTP 200 响应 该响应包含一个新字段 testNotificationToken 识别您的服务器 收到的测试通知 我们稍后会再次提到这个新字段 片刻后 您的服务器 就会在 App Store Connect 保存的 URL 中收到 类型为 TEST 的 V2 通知 现在来看如何调用该端点 只需向 App Store 服务器上的这个新路径 发送一个简单的 POST 请求 您就会收到 HTTP 200 响应 并了解您的请求已被提交 响应将包含我提到的新字段 testNotificationToken 请留意这一点以备后用 很快您就会收到一份 签好名的 TEST 通知 这是该通知 解码后的样子 您会注意到它包含 V2 通知中 所有常见的顶级字段 包括新的 notificationType TEST 数据对象的内容 比正常通知稍短 由于这只是一个测试 未包含交易相关数据 因此我们省略了特定于交易的字段 最常见的就是 signedTransactionInfo 调用新的 Request a Test Notification 端点时 请记住 App Store Server Notifications 是异步发送的 您对端点的成功调用 将返回一个 HTTP 200 但实际的测试通知 稍后将单独到达 由于该端点是为 测试您的服务器配置 您或许好奇该测试若失败了该怎么办 换句话说 如果测试通知没有到达怎么办？ 为进一步提高您的测试能力 我们将发布 Get Test Notification Status 端点 您将其与 Request a Test Notification 端点结合使用 利用该端点 您可以检查先前请求的 TEST 通知状态 端点响应将告知您 App Store 服务器是否 能够访问您的服务器 并成功发送 TEST 通知 如果发送失败 它也会告诉您原因 这样您就可以更好地 对服务器配置进行故障排除 我们来看使用该端点的方法 向 App Store 服务器上的 此路径发送 GET 请求 在此路径中 包含了您从 Request a Test Notification 端点 收到的 testNotificationToken 这会告诉我们您想检查 哪个测试通知的状态 再来看响应 signedPayload 字段 包含了App Store 服务器 尝试向您的服务器发送的 TEST 通知有效负载 并且 firstSendAttemptResult 字段表明了 发送尝试的结果 这里 SUCCESS 表示发送成功 意味着 App Store 服务器 收到了您的服务器做出的 HTTP 200 响应 如果未发送成功 您将看到以下几个不同的错误值 这些值表示 App Store 服务器在尝试 通过测试通知 访问您的服务器时遇到的错误 有了这些信息 您可以解决服务器问题 根据需要请求新的测试通知 让您的服务器平稳运行 总得来说 以上测试通知端点 使用简单 在设置或重新配置服务器 以接收 V2 App Store 服务器通知时 可以为您省去很多麻烦 在上述端点的帮助下 您可以设置 您的服务器确保其顺利运行 但服务器并不完美 有时还会中断 那当您的服务器 出现故障 导致您错过 App Store Server Notifications 时 您如何恢复？ 目前的解决方案就是重试系统 当 App Store 服务器 无法访问您的服务器时 它会启动重试程序 最多重试发送五次相同通知 每次尝试间隔递增 重试仅发生在生产环境中 可帮助您最终从中断中恢复 但并非适合所有情况 例如 有些中断可能范围较大 如果您的服务器停机时间长到 错过了 App Store 服务器发送的最终重试尝试 那该通知将丢失 或者还有更常见的情况 您的服务器可能遇到了 一个非常简短的问题 而在此期间它只错过了少量通知 但错过哪怕一个通知 都意味着您的客户记录 至少有一个小时未更新 而您却不知道未更新的是哪些记录！ 显然 服务器中断压力很大 从中恢复是一项复杂的任务 所以我们才想尽可能简单地 恢复错过的 App Store Server Notifications 以便您的服务器尽快重回正轨 这也是今年我们推出新的 Get Notification History 端点的原因 有了该端点 您可以获取您的 App 生成的 V2 App Store Server Notifications 无论您的服务器是否成功收到通知 该通知都会出现在该端点的响应中 调用该端点时 您要指定获取通知的日期范围 通过 WWDC 我们已经开始记录这些数据 累积最近六个月的 滚动历史上线 您可以选择 按类型和子类型过滤您的请求 或通过提供 originalTransactionId 仅获取单个用户的通知 现有的重试系统仍然可用 因此您可以将其与该新端点结合使用 我们来看一下如何调用该端点 您向 App Store 服务器上的这个新路径 发送一个简单的 POST 请求 在请求正文中包含 startDate 和 endDate 响应将仅包含我们首次尝试 在此窗口中发送的通知 请记住 最早可用的通知 是在您提出请求前 六个月发送的通知 或者 您可指定一个 notificationType 和 notificationSubtype 若采用此方法 历史记录将被过滤为仅 匹配这两个值的通知 请记住 某些通知没有子类型 又或者 您可提供 某个用户的 originalTransactionId 仅获取该用户的通知历史记录 最后 您要提供 一个 paginationToken 作为每个后续请求的查询参数 以便获取下一页 确保您在后续请求中 使用相同的请求正文 仅更改此 paginationToken 现在让我们来看响应 notificationHistory 数组 最多包含 20 个通知 首先是最久远的通知 该数组中的每个条目代表一个通知 在其中您会找到 signedPayload 您可像往常一样 对其解码以查看交易数据 其中的数据与 App Store 服务器 在原始通知中发送的有效负载相同 您会看到我们 为该还端点响应带来了新的 firstSendAttemptResult 字段 使用此字段您可查找超时序列 以及其他错误 以更好了解您的服务器 错过历史通知的原因 若有更多页面需要检索 响应还包含一个 paginationToken 您应该在下一个请求中提供此信息 以获得下一页通知 只要 hasMore 字段为 true 您就有更多页面需要检索 以上就是该新端点的 所有介绍 今天我们的 App Store 服务器更新讲座就到此结束了 讲座中提及的服务器功能现在均可 在沙盒和生产中使用 我们希望您能利用以上新功能 让您的服务器达到最佳状态 有关针对 App 内购买使用服务器 的更多精彩内容 包括如何在支持旧版客户端的同时 使用最新功能 建议您观看 WWDC22 的另一场讲座 “探索 App 内购买集成和迁移” 两位：感谢您加入 WWDC22！ ♪