IAP订阅功能梳理
会员功能需要接入 IAP 订阅功能, SKU -> 连续包年(首月免费);连续包月(前3天免费);连续包季(首周免费)
前提: 系统已经有交易系统, 下面的描述只针对 连续订阅产品
需求
- 用户订阅后,获得会员资格, 且每次扣费会有对应的订单(包含免费试用阶段的订单)
苹果支付背景
苹果支付的核心是 收据(receipt)
- 连续订阅产品的话: 第一次产生收据是一直可用的 (can verify) 每次续订/恢复购买的记录都「保存」在收据里, 业务逻辑核心就是理解 receipt 里的字段
涉及到的人员
- 设计: 设计购买页面
- 产品: 产品交互/辅助开发 在 app_store 创建产品
- IOS 开发: 初始化购买
- 服务器开发: 验证客户端上传收据,并管理用户续费订单
开发流程简述
- 产品将 产品列表创建好
App product_id | 服务器后台 sku | 价格 | 优惠说明 | 标题 |
---|---|---|---|---|
product_year_xxx | xxxx | 100 | 首月免费 | 连续包年 |
product_quarter_xxx | xxx | 50 | 首周免费 | 连续包季 |
product_month_xxx | xxxx | 30 | 3天免费 | 连续包月 |
IOS 客户端 可以从苹果拿到 product_id 列表开始测试
- 目的: 产生 receipt 交给服务器设计表结构
- 走具体流程
服务器具体要做的事
- 产品列表接口: 提供可购买的 product_id, 以及当前用户的订阅状态; 如果已订阅那么禁止用户继续订阅
- 验证收据接口: 服务器收到 receipt 先在本地通过单元测试解析并结合文档(https://developer.apple.com/documentation/appstorereceipts)梳理
- 定时任务: 检测 payment_applepay 数据 按过期了一个月/将要过期的 订单每隔6h 轮询一次 业务逻辑同 (验证收据接口)
服务器表结构设计
- 验证动作表
- 记录每次验证 receipt 的 request_data 以及 response_data 方便测试和复盘
1 | /******************************************/ |
- 对应 receipt 的 in-app 列表 就是对应的每个 transcation_id
- 记录每次购买 、 续费、恢复购买数据
1 | /******************************************/ |
字段设计以及 Why
original_transaction_id
,product_id
,expires_date_ms
组合 unique_key 唯一索引对于连续订阅产品 orginal_transaction_id 只有一个, 区分每次订阅/续期的就是 expires_date_ms(每次续费时间会不一样) 和 product_id(更换产品比如从 连续包年->连续包月 )
payment_applepay 为什么需要 order_no
关联 order 才知道这单处理过 防止丢单
怎么判断需不需要创建订单?
解析in-app里的数据,
- 如果此时是插入数据 且 expires_date_ms > now 就表明用户续费了或者刚购买 需要创建订单
- 如果此时payment 数据已存在, 且 expires_date_ms > now 且 order_no 没赋值, 那么说明漏单了, 创建订单
- 如果 is_trial_period or is_in_intro_offer_period 就要注意创建试用订单 此时用户还没真正付钱所以权益之只分配是用权限 比如 首月免费 那就创建首月免费订单 , 等苹果扣费时, 验证苹果 receipt 时 会新增一个 transaction_id 表明付款了
测试流程
- 了解 in-app-purchase sandbox 背景 如下图
补充
- 苹果还有订阅 subscribe 接口, 订阅文档 当订阅发生改动时会向你的服务器发送通知. 这个为了订阅时效性可以选择接入。 我们这边只是写了接口 把订阅的数据存到database 没有做具体逻辑; 数据结构如下
1 | /******************************************/ |