iOS订阅开发相关
本章不讨论 iOS订阅开发，详细的自行参考大神的文章
iOS 自动订阅开发
从上面文章得知，苹果设计自动订阅的初衷是 ，订阅一个服务， 这个服务需要跟着 Apple ID走
但国内的应用关联的是App的User ID，而不是Apple ID，但文章只是简单的描述“App自身做处理，就是记住首次购买的transaction-id，并且绑定某个用户”。
那么同一个Apple ID, A UID已订阅， B UID 购买订阅，客户端需要做哪些处理，后端做哪些处理呢？
本章只讨论多账号订阅的归属问题，与前后端的处理
订阅receipt结构
receipt通过base64解码可得：
{
"signature" = "dfreree...."; //也是base64
"purchase-info" = "ewoJIm9x....."; //也是base64，这个里面存放详细时间，流水号等
"environment" = "Sandbox";
"pod" = "100";
"signing-status" = "0";
}
“purchase-info”可以再次base64解码可得：
{
"original-purchase-date-pst" = "2017-08-29 23:52:45 America/Los_Angeles";
"purchase-date-ms" = "1504144439749";
"unique-identifier" = "a063c2c321dd885642a5cddd9160e0ad8291d978";
"original-transaction-id" = "1000000328915948";
"expires-date" = "1504144739749";
"transaction-id" = "1000000329310742";
"original-purchase-date-ms" = "1504075965000";
"web-order-line-item-id" = "1000000036091900";
"bvrs" = "1";
"unique-vendor-identifier" = "B78549AC-58D4-4750-8E6F-F4CCE6138A5A";
"expires-date-formatted-pst" = "2017-08-30 18:58:59 America/Los_Angeles";
"item-id" = "1276511095";
"expires-date-formatted" = "2017-08-31 01:58:59 Etc/GMT";
"product-id" = "lcm.denachina.pickle.38.1month";
"purchase-date" = "2017-08-31 01:53:59 Etc/GMT";
"original-purchase-date" = "2017-08-30 06:52:45 Etc/GMT";
"bid" = "com.denachina.pickle";
"purchase-date-pst" = "2017-08-30 18:53:59 America/Los_Angeles";
"quantity" = "1";
}
其他参数都可以在官网上查看到，这里重点看”original-transaction-id“与”transaction-id“
- transaction-id 代表每次下单的与苹果唯一订单
- original-transaction-id 代表与苹果订阅类型唯一订单号的原生订单
original-transaction-id字面意思就是原始订单号的意思，可以理解为该Apple ID的某订阅唯一标示，无论取消订阅、续费、升降级original-transaction-id都不变，但transaction-id每次都改变。首次订阅transaction-id与original-transaction-id是一致的
苹果订阅升降级收费处理
现在假设 AppstoreConnect后台配置一个订阅
| product ID | 包月 | 包季 |
| —— | —— | —— |
| com.xx.autoVip | 10元 | 30元 |
同Apple ID情况下,未订阅的情况下
-
A UserID 订阅“包月”，订阅成功后，马上扣费10元
-
A UserID 再订阅 “包月”相同等级的，订阅失败，苹果自身会拦截，会出现“您已订阅此项目”的提示框，不扣费
p71.png
-
A UserID 订阅“包季”，则为升级，订阅成功，扣费30元, “包月”的按剩余部分进行退款，退给用户 小于10元 ，新的包季订阅从新订阅付款开始计算
p72.png
-
A UserID 再订阅“包月“，则为降级，订阅成功，不扣费，需要等“包季”过期后，才生效“包月”，此时才开始扣“包月”的费用
p73.png
苹果这样的设计应该是为了收益最大化
知道苹果收费策略后，接下来多账号的就好办了
多账号归属
original-transaction-id 绑定到UserID上就可以了
订阅配置同上，同Apple ID情况下
- A UserID 订阅“包月”, 换B UserID 再订阅“包月”，苹果自身会拦截，会出现“您已订阅此项目”的提示框
- A UserID 已订阅“包月”, 换B UserID 再订阅“包季”，则为升级，A UserID 订阅退款，A User服务终止，把original-transaction-id 换绑B UserID，完成升级
- 再换登陆A UserID 订阅“包月”，则为降级，此时需要B User包季结束后，再把original-transaction-id换绑A UserID，完成降级
运营策略
用户订阅进行升降级，对于项目是减少了订阅的，A用户换绑B用户，其实A的订阅是失去的，所以尽量减少让用户换绑操作，其实一些运营策略也可以减少换绑概率，从而提高订阅收入
- 升降级操作尽量不要在App内完成，尽量引导用户去苹果系统内部做升降级
- 用户订阅中的，不展示订阅产品内容，用户无法购买
- 新用户订阅
- 在支付之前是无法知道当前的Apple ID是否已经订阅过产品，因为original-transaction-id只有支付后才能知道，所以很难避免用户在App上做升降机处理。但是我们可以设置多个订阅来减少换绑
- 在AppstoreConnect设置的时候有个组的概念，Apple ID不可以存在相同组的订阅，简单的说包月、包季不能同时存在，要么包月、要么包季。让一个Apple ID存在多个可用的original-transaction-id，那么就可以绑定过个账号了
- 但可以存在多个不同组的订阅，如下表，可以同时存在普通包月、促销包月。
- 新用户订阅，则展示促销订阅套餐。订阅过的用户并过期的，展示正常价格订阅套餐。这种设计也是能满足国内国情。
- 但对于同一个用户，两个包月是不合理的，程序上一定要避免同一个用户购买不同订阅的存在
| product ID | 包月 | 包季 | 描述｜
| —— | —— | —— | —— |
| com.xx.autoVip | 10元 | 30元 | 正常 |
| com.xx.autoVipc | 6元 | 30元 | 促销 |
网友评论