应用内计费.docx
- 文档编号:7083709
- 上传时间:2023-01-17
- 格式:DOCX
- 页数:21
- 大小:422.84KB
应用内计费.docx
《应用内计费.docx》由会员分享,可在线阅读,更多相关《应用内计费.docx(21页珍藏版)》请在冰豆网上搜索。
应用内计费
应用内计费简述
一、In-AppPurchase概览2
(一)StoreKit框架2
(二)产品3
(三)通过AppStore注册产品4
(四)交付方式5
二、取得产品信息10
(一)向AppStore发送请求10
(二)发送获得产品信息的请求11
三、购买商品12
(一)收集支付信息12
(二)恢复交易信息(Transactions)14
四、在程序中添加Store功能16
五、验证store的收据21
(一)验证AppStore返回的收据信息21
(二)验证收据的过程:
21
(二).AppStore的收据22
六、测试Store功能24
(一)Sandbox环境24
(二)在Sandbox环境中测试步骤24
(三)在Sandbox中验证收据24
七、自动更新的订阅服务26
(一)为你的商店添加自动更新型订阅服务26
(二)设计iOS客户端26
(三)验证自动更新型订阅服务的收据27
一、In-AppPurchase概览
(一)StoreKit框架
iOS3.0引入StoreKit框架(StoreKit.framework),此框架为iOS应用程序内购买内容或服务提供支持。
例如,开发者可以利用此框架允许用户解锁应用程序的额外功能。
或者假设您是一名游戏开发人员,则可使用此特性向玩家出售附加游戏级别。
在上述的两种情况中,StoreKit框架会处理交易过程中和财务相关的事件,包括处理用户通过iTunesStore账号发出的支付请求并且向应用程序提供交易相关信息。
StoreKit框架主要关注交易过程中和财务相关的事务,目的是为了确保交易安全准确。
应用程序需要处理交易事物的其他因素,包括购买界面和下载(或者解锁)恰当的内容。
通过这种任务划分方式,您就拥有购买内容的控制权,可以决定希望展示给用户的购买界面以及何时向用户展示这些界面,同时也可以决定和应用程序最匹配的交付机制。
StoreKit代表App和AppStore之间进行通信。
程序将从AppStore接收那些你想要收费的产品的信息,并将它们显示出来供用户购买。
当用户需要购买某件产品时,程序调用StoreKit来收集购买信息。
下图即为基本的storekit模型:
Figure1-1 In-AppStoremodel
StoreKit的API只是为程序添加In-AppPurchase功能的一小部分。
你需要决定如何去记录那些你想要提交的产品,如何在程序中将商店功能展现给用户,还要考虑如何提交用户购买的产品。
(二)产品
产品可以是任意一项你想要出售的特性。
产品在iTunesConnect中被组织,这和你添加一个新的App是一样的。
支持的产品种类共有四种:
1.内容型。
包括电子书,电子杂志,照片,插图,游戏关卡,游戏角色,和其他的数字内容。
2.扩展功能。
这些功能已经包含在App内部。
在未购买之前被锁定。
例如,你可以在一个游戏程序中包含若干个小游戏,用户可以分别来购买这些游戏。
3.服务。
允许程序对单次服务收费。
比如录音服务。
4.订阅。
支持对内容或服务的扩展访问。
例如,你的程序可以每周提供财务信息或游戏门户网站的信息。
应该设定一个合理的更新周期,以避免过于频繁的提示困扰用户。
要记住:
你将负责跟踪订阅的过期信息,并且管理续费。
AppStore不会替你监视订阅的周期,也不提供自动收费的机制。
In-AppPurchase为创建产品提供了一种通用的机制,如何操作将由你负责。
当你设计程序的时候,有以下几点需要注意:
1.你必须提供电子类产品和服务。
不要使用InAppPurchase去出售实物和实际服务。
2.不能提供代表中介货币的物品,因为让用户知晓他们购买的商品和服务是很重要的。
(三)通过AppStore注册产品
每个你想要出售的产品都必须先通过iTunesConnect在AppStore注册。
你需提供产品的名称,描述,价格和其他在程序中用到的元数据。
需为产品指定唯一的标识符。
当你的程序利用StoreKit和AppStore通信时,会使用产品标识来取回产品的信息。
如果用户购买某个商品时,程序可以用该标识来将产品标注为“已购买”。
AppStore将前面提到过的产品种类简化为以下4种:
1.消耗性商品。
该类商品在需要时被单次购买。
比如,单次服务。
2.非消耗性商品。
该类商品只需被某个用户购买一次,一旦被购买,和该用户iTunes账户关联的设备都可以使用此商品。
StoreKit为在多个设备上重新存储非消耗性商品提供了内置的支持。
3.自动更新型订阅服务。
提供内容的方式和非消耗性商品类似。
但是,还是有一些区别。
在iTunesConnect上创建自动更新型订阅服务的时候,需要选择订阅周期,这样,每次过期的时候,AppStore会自动更新订阅服务。
如果用户选择不更新订阅,则其订阅权限会被撤销。
你的程序要负责验证当前的订阅是否可用,并获取新的交易收据。
4.非自动更新型订阅服务。
这是创建周期性产品的一种老的方式。
可以考虑一下是否需要换成自动更新型订阅。
它们之间的主要不同在于:
1)订阅的条款并不在iTunesConnect中声明。
你的程序需要负责提供这些信息给用户。
通常,你需要将订阅条款加在产品描述中。
2)非自动更新型订阅可以被购买多次(和消费型商品类似),并且不能被AppStore自动更新。
你需要在app中自己实现更新机制。
具体说来,你的app要能知道哪些订阅过期了,并且提示用户去再次购买。
3)购买过订阅服务的用户还可能使用其他设备,你必须保证将订阅内容发送给这些设备。
非自动更新型订阅服务不会通过StoreKit被同步。
你必须自己来实现这个功能。
例如,大多数订阅服务使用server来提供,你的server需要实现标识用户和相关订阅服务的功能。
3.订阅类。
订阅类商品拥有以上两种类型的特性。
和消耗性商品一样,订阅类商品可以被多次购买;你可以在程序内部加入自己的订阅计划更新机制。
另外,订阅类商品必须提供给和某一用户关联的所有设备。
InAppPurchase期望订阅类商品可以通过外部服务器交付。
你必须为多个设备的订阅服务提供相应的支持。
关于注册产品的详细信息,可参考iTunesConnectDeveloperGuide文档。
(四)交付方式
交付机制在程序In-AppPurchase的设计和实现种有很重要的意义。
有两种基本的模型可以用来交付产品:
内置类型(Built-inmodel)和服务器类型(Servermodel)。
不管使用那种模型,你都需要维护产品列表,并保证当用户购买后,成功的交付产品。
1.内置产品类型
使用这种模型。
需要交付的产品已经在程序内部。
这种方式通常用在一些被锁定的功能上。
也可以用来交付在程序束(AppBundle)中的内容。
该方式的一个重要的优点是你可以及时的给客户交付产品,大多数的内置产品应为非消耗性商品。
注意:
In-AppPurchase不提供购买补丁的功能。
如果需要更改app的bundle,你必须向AppStore提交新的app版本。
为了标识产品,程序要在bundle中存储产品的标识符。
内置模式下,Apple建议使用属性列表(plist)来纪录产品的标识符。
内容类应用可以使用折衷方式很方便的添加新的内容,而不改动程序本身。
当成功购买产品后,程序应将锁定的功能解锁,提供给用户。
解锁的最简单方式是修改程序偏好设置(ApplicationPreferences)。
当用户备份手机数据的时候,程序偏好设置也会随之备份。
程序可能需要建议用户在购买产品后备份手机以免丢失购买的内容。
图1-2显示了交付内置型产品的流程。
1.程序通过bundle存储的list文件得到产品标识符的列表。
2.程序向AppStore发送请求,得到产品的信息。
3.AppStore返回产品信息。
4.程序把返回的产品信息显示给用户(App的store界面)
5.用户选择某个产品
6.程序向AppStore发送支付请求
7.AppStore处理支付请求并返回交易完成信息。
8.App获取信息并提供内容给用户。
2.服务器类型
使用这种方式,要提供另外的服务器将产品发送给程序。
服务器交付适用于订阅、内容类商品和服务,因为商品可以作为数据发送,而不需改动程序束。
例如,一个游戏提供的新的内容(关卡等)。
StoreKit不会对服务器端的设计和交互做出定义,这方面工作需要你来完成。
而且,StoreKit不提供验证用户身份的机制,你需要来设计。
如果你的程序需要以上功能,例如,纪录特定用户的订阅计划,你需要自己来设计和实现。
图1-3展示了服务器类型的购买过程。
1.程序向服务器发送请求,获得一份产品列表。
2.服务器返回包含产品标识符的列表。
3.程序向AppStore发送请求,得到产品的信息。
4.AppStore返回产品信息。
5.程序把返回的产品信息显示给用户(App的store界面)
6.用户选择某个产品
7.程序向AppStore发送支付请求
8.AppStore处理支付请求并返回交易完成信息。
9.程序从信息中获得数据,并发送至服务器。
10.服务器纪录数据,并进行审查。
11.服务器将数据发给AppStore来验证该交易的有效性。
12.AppStore对收到的数据进行解析,返回该数据和说明其是否有效的标识。
13.服务器读取返回的数据,确定用户购买的内容。
14.服务器将购买的内容传递给程序。
Apple建议在服务器端存储产品标识,而不要将其存储在plist中。
这样就可以在不升级程序的前提下添加新的产品。
在服务器模式下,你的程序将获得交易(transaction)相关的信息,并将它发送给服务器。
服务器可以验证收到的数据,并将其解码以确定需要交付的内容。
这个流程将在“验证store收据”一节讨论。
对于服务器模式,我们有安全性和可靠性方面的顾虑。
你应该测试整个环境来避免威胁。
《SecureCodingGuide》文档中有相关的提示说明。
虽然非消耗性商品可以用内置模式来恢复,订阅类商品必须通过服务器来恢复。
你要负责纪录订阅信息、恢复数据。
消耗类商品也可以通过服务器方式来纪录。
例如,由服务器提供的一项服务,你可能需要用户在多个设备上重新获得结果。
二、取得产品信息
要在程序内部显示“商店”,需要从AppStore得到信息来购建界面。
本章详细讲解如何从AppStore获取产品信息。
(一)向AppStore发送请求
StoreKit提供了从AppStore上请求数据的通用机制。
程序可以创建并初始化一个request对象,为其附加delegate,然后启动请求过程。
请求将被发送到AppStore,在那里被处理。
处理完成时,request对象的delegate方法将被异步调用,以获得请求的结果。
图2-1显示了请求的数据模型。
如果程序在请求期间退出,则需要重新发送请求。
下面讲解请求过程中用到的类:
SKRequest:
SKRequest为request的抽象根类。
SKRequestDelegate:
SKRequestDelegate是一个protocol,实现用以处理请求结果的方法,比如请求成功,或请求失败。
(二)发送获得产品信息的请求
程序使用productsrequest来获得产品的信息。
要完成这一过程,程序需创建一个request对象,其中会包含一个产品标识的列表。
之前提到过,你的程序既可以内置产品列表,又可以通过外部服务器来获得。
当发送请求时,产品标识会传送到AppStore,AppStore将会返回本地化信息(这些信息事先已经在iTunesConnect中设置好了),你将使用这些信息来购建内置商店的界面(显示商品名,描述,等等)。
图2-2显示了请求的过程。
●SKProductsRequest:
用来请求商品的信息。
创建时,我们将需要显示的商品列表加入该对象。
●SKProductsRequestDelegate:
该protocol定义了处理AppStore响应的方法。
●SKProductsResponse:
SKProductsResponse对象为AppStore返回的响应信息。
里面包含两个列表:
一是经过验证有效的商品,@property(nonatomic,readonly)NSArray*products
另外一个是无法被识别的商品信息:
@property(nonatomic,readonly)NSArray*invalidProductIdentifiers
有几种原因将造成商品标识无法被识别,如拼写错误,被标记为不可出售(unavailableforsale),或是对商品信息的改变没有传送到AppStore的服务器。
●SKProduct:
SKProduct对象包含了在AppStore上注册的商品的本地化信息。
三、购买商品
当用户准备购买商品时,程序向AppStore请求支付信息,然后AppStore将会创建持久化的交易信息,并继续处理支付流程,即使用户重启程序,这个过程亦是如此。
AppStore同步待定交易的列表到程序中,并在交易状态发生改变时向程序发送更新的数据。
(一)收集支付信息
要收集支付信息,你的程序可以创建一个payment的对象,将它放到支付队列中,如图3-1所示。
1.一个SKPayment的对象,包含了"Sword"的商品标识,并且制定购买数量为1。
2.使用addPayment:
方法将SKPayment的对象添加到SKPaymentQueue里。
3.SKPaymentmentQueue包含的所有请求商品,
4.使用SKPaymentTransactionObserver的paymentQueue:
updatedTransactions:
方法来检测所有完成的购买,并发送购买的商品。
5.最后,使用finishTransaction:
方法完成交易。
当payment的对象被添加到支付队列中的时候,会创建一个持久保存的transaction对象来存放它。
当支付被处理后,transaction被更新。
程序中将实现一个观察者(observer)对象来获取transaction更新的消息。
观察者应该为用户提供购买的商品,然后将transaction从队列中移除。
下面介绍在购买过程中用到的几个类:
SKPayment
要收集支付信息,先要了解一下支付对象。
支付对象包含了商品的标识(identifier)和要购买商品的数量(quantity)(数量可选)。
你可以把同一个支付对象重复放入支付队列,每一次这样的动作都相当于一次独立的支付请求。
用户可以在Settings程序中禁用购买的功能。
因此在请求支付之前,程序应该首先检查支付是否可以被处理。
这可以通过调用SKPaymentQueue的canMakePayments方法来检查。
SKPaymentQueue
支付队列用以和AppStore之间进行通信。
当新的支付对象被添加到队列中的时候,StoreKit向AppStore发送请求。
StoreKit将会弹出对话框询问用户是否确定购买。
完成的交易将会返回给程序的observer对象。
SKPaymentTransaction
transaction对象在每次添加新的payment到队列中的时候被创建。
transaction对象包含了一些属性,可以让程序确定当前的交易状态。
程序可以从支付队列那里得到一份审核中的交易列表,但更常用的做法还是等待支付队列告知交易状态的更新。
SKPaymentTransactionObserver
在程序中实现SKPaymentTransactionObserver的协议,然后把它作为SKPaymentQueue对象的观察者。
该观察者的主要职责是:
检查完成的交易,交付购买的内容,和把完成后的交易对象从队列中移除。
在程序一启动,就应该为支付队列指定对应的观察者对象,而不是等到用户想要购买商品的时候。
Transaction对象在程序退出时不会丢失。
程序重启时,StoreKit继续执行未完成的交易。
在程序初始化的时候添加观察者对象,可以保证所有的交易都被程序接收(也就时说,如果有未完成的transaction,如果程序重启,就重新开始了,如果稍候再添加观察者,就可能会漏掉部分交易的信息)。
(二)恢复交易信息(Transactions)
当transaction被处理并从队列移除之后,正常情况下,程序就再也看不到它们了。
如果你的程序提供的是非消耗性的或是订阅类的商品,就必须提供restore的功能,使用户可以在其他设备上重新存储购买信息。
StoreKit提供内建的功能来重新存储非消耗商品的交易信息。
调用SKPaymentQueue的restoreCompletedTransactions的方法来重新存储。
对于那些之前已经完成交易的非消耗性商品,AppleStore生成新的,用于恢复的交易信息。
它包含了原始的交易信息。
你的程序可以拿到这个信息,然后继续为购买的功能解锁。
当之前所有的交易都被恢复时,就会调用观察者对象的paymentQueueRestoreCompletedTransactionsFinished方法。
如果用户试图购买已经买过的非消耗性商品,程序会收到一个常规的交易信息,而不是恢复的交易信息。
但是用户不会被再次收费。
程序应把这类交易和原始的交易同等对待。
订阅类服务和消耗类商品不会被StoreKit自动恢复。
要恢复这些商品,你必须在用户购买这些商品时,在你自己的服务器上记录这些交易信息,并且为用户的设备提供恢复交易信息的机制。
四、在程序中添加Store功能
本章为添加购买功能的指导详细流程:
准备工作当然是添加StoreKit.framework了。
然后是具体的步骤:
1.决定在程序内出售的商品的类型。
之前提到过,程序内可以出售的新feature类型是有限制的。
StoreKit不允许我们下载新的代码。
你的商品要么可以通过当前的代码工作(bundle类型),要么可以通过服务器下载(当然,这里下载的为数据文件,代码是不可以的)。
如果要修改源代码,就只能老实的升级了。
2.通过iTunesConnect注册商品
每次添加新商品的时候都需要执行这一步骤。
每个商品都需要一个唯一的商品标识。
AppStore通过这个标识来查找商品信息并处理支付流程。
注册商品标识的方法和注册程序的方法类似。
要了解如何创建和注册商品信息,请参考“iTunesConnectDeveloperGuide”文档。
3.检测是否可以进行支付
用户可以禁用在程序内部支付的功能。
在发送支付请求之前,程序应该检查该功能是否被开启。
程序可在显示商店界面之前就检查该设置(没启用就不显示商店界面了),也可以在用户发送支付请求前再检查,这样用户就可以看到可购买的商品列表了。
例子:
if([SKPaymentQueuecanMakePayments]){
//Displayastoretotheuser.
}else{
//Warntheuserthatpurchasesaredisabled.
}
4.获得商品的信息
程序创建SKProductsRequest对象,用想要出售的商品的标识来初始化,然后附加上对应的委托对象。
该请求的响应包含了可用商品的本地化信息。
//这里发送请求
-(void)requestProductData
{
SKProductsRequest*request=[[SKProductsRequestalloc]initWithProductIdentifiers:
[NSSetsetWithObject:
kMyFeatureIdentifier]];
request.delegate=self;
[requeststart];
}
//这个是响应的delegate方法
-(void)productsRequest:
(SKProductsRequest*)requestdidReceiveResponse:
(SKProductsResponse*)response
{
NSArray*myProduct=response.products;
//生成商店的UI
[requestautorelease];
}
5.添加一个展示商品的界面
StoreKit不提供界面的类。
这个界面需要我们自己来设计并实现。
6.为支付队列(paymentqueue)注册一个观察者对象
你的程序需要初始化一个transactionobserver对象并把它指定为paymentqueue的观察者。
MyStoreObserver*observer=[[MyStoreObserveralloc]init];
[[SKPaymentQueuedefaultQueue]addTransactionObserver:
observer];
应该在程序启动的时候就添加好观察者,原因前面说过,重启后程序会继续上次未完的交易,这时就添加观察者对象就不会漏掉之前的交易信息。
7.在MyStoreObserver类中执行paymentQueue:
updatedTransactions:
方法。
这个方法会在有新的交易被创建,或者交易被更新的时候被调用。
-(void)paymentQueue:
(SKPaymentQueue*)queueupdatedTransactions:
(NSArray*)transactions
{
for(SKPaymentTransaction*transactionintransactions)
{
switch(transaction.transactionState)
{
caseSKPaymentTransactionStatePurchased:
[selfcompleteTransaction:
transaction];
break;
caseSKPaymentTransactionStateFailed:
[selffailedTransaction:
transaction];
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 应用 计费
![提示](https://static.bdocx.com/images/bang_tan.gif)