【WWDC20】10671 - IAP 订阅服务的生命周期和最佳实践

作者: 天豆，iOS 开发者，目前就职于字节跳动

WWDC20 10671 - Architecting for subscriptions: https://developer.apple.com/videos/play/wwdc2020/10671/

概述

这个主题，主要从服务端角度，讲述怎样在 Apple 平台构建和维护订阅服务。Apple 提供的IAP 商品包括四个种类：消耗型商品、非消耗型商品、订阅商品和自动订阅商品。我们一般说到订阅，主要指后两种商品。但是这篇主题，主要集中在阐述如何开发自动订阅服务。 这个主题内容主要涉及以下几个方面：

• 订阅者的经历
• 定义订阅权益
• 定义授权逻辑
• 开发相应的服务端代码

其中后两个方面我放在一起做了介绍。

订阅者会经历什么

在过去，通过 productId 和 expiration date 两个字段即可确定用户是否已订阅。在Apple 引入帐单重试和宽限期机制后，这个过程会变得更加复杂。 假设我们有一个按月订阅的商品，用户在 5 月 1 日订阅了这个商品。Apple 会发送一个到服务端的通知，告诉开发者，用户刚完成了一个首次订阅。如果用户没有其它行为，那么每个月的第一天，订阅服务都会更新，自动完成扣费和续期的流程。

那么如果用户取消了自动订阅，会发生什么呢？假设用户在 6 月 17 日取消自动订阅，Apple 同样会发送一个到服务端的通知，告诉开发者自动订阅已取消，并在回执的 Expires_date 和 Expiration_intent 两个字段中更新自动订阅失效的信息。

如果苹果自动扣款失败，又会发生什么呢？比如上例中，Apple 在 6 月 1 日自动扣款失败，用户随后在 6 月 15 日，更新了自己的支付设置，并重新订阅成功，Apple 会给开发者发送一个服务端通知，让开发者可以感知到这一点，但是，此时自动订阅商品的本期生效时间段会更新到7 月 15 日，而不是之前的 7 月 1 日。

但是如果打开了宽限期开关（grace period），这个过程又会不太一样。在自动扣款失败的16天内，用户重新订阅成功，那么，下一次自动扣款还是会维持原状，而不是从订阅成功开始重新计算。在上面的例子中，就是从 7 月 1 日开始进入下一个订阅周期。

每个用户在订阅周期的行为可能会不一样，Apple 返回的回执会直观反映用户的行为，因此，弄清楚回执中每一个字段的含义非常重要，只有理解这些，才能明白用户做了什么。 每一次订阅自动更新的行为会反映为回执中的一条记录。通过组合记录中各字段的值，我们可以推测出用户订阅的状态，并给用户提供相应的服务。 用户可能的状态非常多，如下图所示。如果用户 Expires_date 是一个未来的值，auto-renew 的值为 1，则代表用户处于自动订阅激活状态。除了这些 state 外，还会有相应的 sub state ，反映用户的订阅类型，比如：正常订阅、试用等。

复杂的订阅状态

前面提到订阅状态非常多，那么针对这些订阅状态，我们可以做些什么呢？这里举了五个例子。 示例一：如果用户已经订阅了商品，但是取消了自动订阅，我们可以提示用户去续费。 示例二：用户订阅的商品自动扣款失败，商品已过期，但仍处于账单扣款重试阶段，可以提示用户支付出了一些问题，并把用户引导至App Store的相应页面 示例三：用户订阅的商品自动扣款失败，但处于grace period，可以通过倒计时提示用户商品即将失效，并引导用户去App Store解决支付问题 示例四：用户订阅的商品过期，且不再续费，可以通过发送推送尝试挽回用户 示例五：用户经历多次自动续费周期，可以提示用户去订阅更高级的服务

怎样定义订阅权益

订阅服务不止是简单的解锁内容，至少可以涵盖以下四个方面的内容：

• Access：用户是否可以解锁内容
• Products：服务可以区分层次，让用户决定自己的服务档次，并可以升级或者降级服务档次
• Offers：试用或者折扣
• Messaging：通过消息告诉用户服务即将失效，或者引导用户去解决付款问题

服务端处理流程（Entitlement Engine）

这一部分，Apple 非常贴心的提供了示例代码：Determining Service Entitlement on the Server

1. 准备数据（Prepare data）

这里的输入是回执信息，这一步主要是验证回执的有效性，并从 Apple 服务器拉取回执的最新信息。同时，你也可以提供一些回执里没有的信息，比如：你提供的服务是跨 app 或者跨平台，你可以在这里传入其它地方的订阅信息。

2. 合成数据（Synthesize）

这一步主要是提取上一步传入的数据，确定用户订阅行为的相关信息，比如用户订阅了哪个商品，现在处于订阅的哪种状态等。

3. 队列/分组（Cohort）

这一步是根据订阅状态，对用户进行分组处理。对于每个 state，标识一个整数，一般用大于0的数字表示用户处于订阅状态，小于等于0的数字表示用户不在订阅状态；对于 sub state，标识一个小数。这样，用户的状态就可以用一个数字来表示。比如 4.1，表示用户是试用状态，且关闭了自动续订。这里使用数字来表示状态，是为了方便把用户的状态归类到不同的队列中处理。

4. 权益（entitle）

将权益信息，作为数据赋值给对应队列中的用户。也可以针对不同队列，应用不同的业务逻辑，这里主要是针对前面“复杂的订阅状态”介绍的，不同状态下，给用户不同形式的引导。

5. 更新（Respond/Update）

这一步主要是更新数据库，并将相应信息安全的传递给用户设备。

服务端的处理逻辑应该具备以下集中特性：

• 满足权益服务的必要功能
• 高可用
• 精确
• 正确处理失败
• 易拓展

整个支付架构设计如下图： 在这个架构设计里，Entitlement Engine 处于服务端，可以快速的修复问题、升级。客户端需要把回执发送给服务端。这一部分还讲了一些出错情况的处理，比较简单，就不再详述，感兴趣可以去看原视频。

总结

做过一段时间的 IAP 客户端开发。不得不说，IAP 是一个看似简单，实际复杂的流程，自动订阅可以说是其中最复杂的一部分，其中的坑非常多。这个主题详细的讲解了服务端开发，所需要做的处理。并且举了很多的例子，还给出了示例代码，对于避过一些坑，非常有帮助。但是，还有一些复杂的逻辑没有涵盖在这次的内容里：如升级、降级、跨级的处理。想要做好 IAP 的处理流程，建议往期的 session 也要看一看，在下面的相关资料里。

限时福利

这篇文章的内容来自于 《WWDC20 内参》。在这里给大家推荐一下这个专栏。

「WWDC 内参」系列是由老司机周报、知识小集合以及 SwiftGG 几个技术组织发起的。已经做了几年了，口碑一直不错。主要是针对每年的 WWDC 的内容，做一次精选，并号召一群一线互联网的 iOS 开发者，结合自己的实际开发经验、苹果文档和视频内容做二次创作。

今年一共有 213 个 Session 的内容。《WWDC20 内参》挑选了其中的 135 个 Session，短短两周，已经创作了 83 篇文章。目前正在限时优惠销售，只需要 9.9 元，十分优惠。

看了文章还不过瘾的朋友，抓紧订阅 《WWDC20 内参》 https://xiaozhuanlan.com/wwdc20 继续阅读把~

关注我们

我们开通了公众号「老司机技术周报」，每期发布时公众号（LSJCoiding）会推送消息，欢迎关注。