IAP 订阅服务的生命周期和最佳实践 - 哈喽比特

1206次阅读 | 发布于4年以前

概述

这个主题，主要从服务端角度，讲述怎样在 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 也要看一看，在下面的相关资料里。