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 再订阅 “包月”相同等级的,订阅失败,苹果自身会拦截,会出现“您已订阅此项目”的提示框,不扣费
-
A UserID 订阅“包季”,则为升级,订阅成功,扣费30元, “包月”的按剩余部分进行退款,退给用户 小于10元 ,新的包季订阅从新订阅付款开始计算
-
A UserID 再订阅“包月“,则为降级,订阅成功,不扣费,需要等“包季”过期后,才生效“包月”,此时才开始扣“包月”的费用
苹果这样的设计应该是为了收益最大化
知道苹果收费策略后,接下来多账号的就好办了
多账号归属
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元 | 促销 |