内购
一. 内购的简介
-
何谓内购
- 在iOS的App中, 如果你要购买某件商品, 使用苹果的支付方式进行购买, 即为内购
- 苹果规定, 如果你在App中销售商品, 跟App功能相关, 那么你就必须得通过内购的方式购买
- 比如游戏中常见的关卡/游戏币购买
-
内购的缺点
- 从商家的角度来看, 苹果会从内购中抽成, 比例为3 : 7, 也就是说你卖10块钱的东西, 苹果会平白拿走你3块钱, 真流氓....
- 从用户的角度来看, 内购支付, 需要用户绑定银行卡, 操作流程比较繁琐, 比如本人, 第一次看到内购的步骤就不想用这个方法了
- 从商品的价格角度来看, 内购只能用苹果指定的价格售卖, 不能自定义, 再次重申苹果的流氓度
-
为什么要用内购
- 内购作为一种营销方式: free + 内购, 在一定意义上还是能起到不错的收益
- 如果你的App是采用直接收取App费用的方式, 那么估计你在国内是卖不出去了, 因为不符合国人的消费习惯
- 广告: 一般广告都会内嵌在App中, 他可以给开发者带来收益
- free+内购的模式, 可以先让用户体验你的App, 然后在让用户决定是否要掏钱, 比较亲民
- 但是, App中的某些业务功能, 苹果规定必须使用苹果内购, 如果你没使用, 苹果是不会上架你的App的(流氓!!!重要的事情说三遍)
- 不过相对的, 在AppStore中下载软件, 都是可以放心使用的, 这点还是要给苹果点个赞的
- 内购作为一种营销方式: free + 内购, 在一定意义上还是能起到不错的收益
二. 内购的流程模拟
- 当App创建出来时候, 你要告诉苹果你要出售哪些物品
- 服务器作为提供方法, 将商品提供给购买的用户
- 苹果公司要验证你的商品是否可以销售, 同意的话才能卖
- 当用户购买某个内购物品的时候, 会向App的服务器发送请求
- 当服务器收到用户的请求之后, 会给用户一个连接, 类似于开具一个售卖小票
- 用户此时要将在苹果方付账
- 当苹果方受理了用户的购买请求时, 就会给交费后的用户授权, 然后通知服务器给用户发放产品
三. 内购的简单测试
-
在App管理中心 ,创建一个App, 并且填写App的信息
- 创建一个可以内购的套装ID, 即一个明确的APP ID
- 在ITunes Connect的用户与智能中, 要创建一个沙箱技术测试员
-
创建一个需要销售的商品, 并且添加到App
- 重点: 添加内购商品时, 需要保证税务信息的完整性, 如果不完整, 产品信息不完全, 就无法申请内购
-
内购的产品类型
- 非消耗品
- 购买之后就一直存在, 不会消耗掉, 比如游戏中的关卡
- 非消耗物品购买之后, 拥有永久的使用权利, 并且能被用户再次下载, 且可以在其他设备上下载
- 消耗品
- 有使用次数的物品
- 一般被设定为某些可消耗的物品或是服务, 并且使用之后不能再次下载
- 消耗品不能再用户的设备之间跨设备使用, 他一般与用户的账号绑定的
- 其他类型
- 免费订阅
- 自动续费订阅
- 非自动续费订阅
- 这三种一般适用于iBooks中, 但是目前大陆市场还不支持iBooks的各种订阅.....
- 非消耗品
-
内购的代码实现
- 配置App的Bundle ID, 要与配置内购信息时的Bundle ID相同
- 代码实现
首先要导入StoreKit.framework框架
-
创建一个工具类, 并且创建一个类方法, 用于发送商品的请求
class func getData(resultBlock: (goodsIds: Set<String>)->()) { resultBlock(goodsIds: ["com.fh.neigou.wupin1", "com.fh.neigou.wupin2"]) }
-
从App服务器请求数据列表, 并且向苹果服务器请求可以销售的商品列表
// 1. 从服务器请求, 需要被销售的商品, 但是, 具体商品能不能被销售, 还需要到苹果服务器去验证才可以 DataTool.getData { (goodsIds) in // 2. 想苹果服务器发送一个请求, 来验证, 哪些商品可以被销售 // productIdentifiers: 验证的时候, 是靠商品的ID, 来进行验证 let request = SKProductsRequest(productIdentifiers: goodsIds) // 开始发送请求, 进行验证(接口都封装在方法内部) // 接收请求下来的结果 request.delegate = self request.start() }
-
在代理方法中, 获取并显示销售列表
// 当苹果服务器验证哪些商品可以被销售, 完成之后, 就会通过这个方法, 来告诉我们验证的结果 func productsRequest(request: SKProductsRequest, didReceiveResponse response: SKProductsResponse) { // 需要展示可以被销售的商品 print(response.products) products = response.products print(response.invalidProductIdentifiers) }
-
点击购买商品, 创建支付对象, 放入队列中, 并且设置交易队列的监听对象, 监听每一笔交易
override func tableView(tableView: UITableView, didSelectRowAtIndexPath indexPath: NSIndexPath) { // 购买点击的商品 // 1. 取出商品 let product = products[indexPath.row] // 2. 购买商品 // 2.1 根据商品开一个小票 let payment = SKPayment(product: product) // 2.2 拿着小票去付款 // 添加到一个支付队列里面 // 只要把一个支付对象, 放到支付队列里面, 就开始进入支付流程 SKPaymentQueue.defaultQueue().addPayment(payment) // 2.3 设置交易队列的监听对象, 监听里面存放的每一笔交易 SKPaymentQueue.defaultQueue().addTransactionObserver(self) }
-
调用支付的代理方法, 当一笔交易的状态发生改变时, 就会调用这个方法, 获取支付的状态
for transaction in transactions { switch transaction.transactionState { case .Deferred: print("延迟购买") case .Failed: print("支付失败") // 应该移除交易 queue.finishTransaction(transaction) case .Purchased: print("支付成功") // 应该移除交易 queue.finishTransaction(transaction) case .Purchasing: print("正在支付") case .Restored: print("恢复购买") // 应该移除交易 queue.finishTransaction(transaction) default: print("交易可能挂了...") } }
-
恢复购买, 对于用户已经购买过的商品, 可以直接发送请求, 并且给用户提供商品
SKPaymentQueue.defaultQueue().restoreCompletedTransactions()
-
内购的测试
- 创建测试者账号
- 在iTunes Connect中的用户和职能中创建
- 创建沙箱技术测试人员
- 要注意, 测试账号不能是注册的真实存在的App ID
- 最好使用真机进行测试, 并且账号为添加的测试者账号
- 创建测试者账号
-
查看内购的销售情况
- 登录iTunes Connect
- 进入销售趋势, 在里面可以看到最近购买的情况