一、In App Purchase概览
Store Kit代表App和App Store之间进行通信。程序将从App Store接收那些你想要提供的产品的信息,并将它们显示出来供用户购买。当用户需要购买某件产品时,程序调用StoreKit来收集购买信息。下图即为基本的store kit 模型:Store Kit的API只是为程序添加In App Purchase功能的一小部分。你需要决定如何去记录那些你想要提交的产品,如何在程序中将商店功能展现给用户,还要考虑如何将用户购买的产品提交。本章的剩余部分会展示整个流程。Products产品可以是任意一项你想要出售的特性。产品在iTunes Connect中被组织,这和你添加一个新的App是一样的。支持的产品种类共有四种:1. 内容型。包括电子书,电子杂志,照片,插图,游戏关卡,游戏角色,和其他的数字内容。2. 扩展功能。这些功能已经包含在App内部。在未购买之前被锁定。例如,你可以在一个游戏程序中包含若干个小游戏,用户可以分别来购买这些游戏。3. 服务。允许程序对单次服务收费。比如录音服务。4. 订阅。支持对内容或服务的扩展访问。例如,你的程序可以每周提供财务信息或游戏门户网站的信息。应该设定一个合理的更新周期,以避免过于频繁的提示困扰用户。要记住:你将负责跟踪订阅的过期信息,并且管理续费。App Store不会替你监视订阅的周期,也不提供自动收费的机制。In App Purchase为创建产品提供了一种通用的机制,如何操作将由你负责。当你设计程序的时候,有以下几点需要注意:1. 你必须提供电子类产品和服务。不要使用In App Purchase 去出售实物和实际服务。2. 不能提供代表中介货币的物品,因为让用户知晓他们购买的商品和服务是很重要的。 通过App Store注册产品 每个你想要出售的产品都必须先通过iTunes Connect在App Store注册。你需提供产品的名称,描述,价格和其他在程序中用到的元数据。 需为产品指定唯一的标识符。当你的程序利用Store Kit和App Store通信时,会使用产品标识来取回产品的信息。如果用户购买某个商品时,程序可以用该标识来将产品标注为“已购买”。 App Store将前面提到过的产品种类简化为以下三种: 1. 消耗性商品。 该类商品在需要时被单次购买。比如,单次服务。 2. 非消耗性商品。 该类商品只需被某个用户购买一次,一旦被购买,和该用户iTunes 账户关联的设备都可以使用此商品。Store Kit为在多个设备上重新存储非消耗性商品提供了内置的支持。 3. 自动更新型订阅服务。提供内容的方式和非消耗性商品类似。但是,还是有一些区别。在iTunes Connect上创建自动更新型订阅服务的时候,需要选择订阅周期,这样,每次过期的时候,App Store会自动更新订阅服务。如果用户选择不更新订阅,则其订阅权限会被撤销。你的程序要负责验证当前的订阅是否可用,并获取新的交易收据。 4. 非自动更新型订阅服务。这是创建周期性产品的一种老的方式。可以考虑一下是否需要换成自动更新型订阅。它们之间的主要不同在于: 1) 订阅的条款并不在iTunes Connect中声明。你的程序需要负责提供这些信息给用户。通常,你需要将订阅条款加在产品描述中。 2)非自动更新型订阅可以被购买多次(和消费型商品类似),并且不能被App Store自动更新。你需要在app中自己实现更新机制。具体说来,你的app要能知道哪些订阅过期了,并且提示用户去再次购买。 3)购买过订阅服务的用户还可能使用其他设备,你必须保证将订阅内容发送给这些设备。非自动更新型订阅服务不会通过Store Kit被同步。你必须自己来实现这个功能。例如,大多数订阅服务使用server来提供,你的server需要实现标识用户和相关订阅服务的功能。 3. 订阅类。订阅类商品拥有以上两种类型的特性。和消耗性商品一样,订阅类商品可以被多次购买; 你可以在程序内部加入自己的订阅计划更新机制。 另外,订阅类商品必须提供给和某一用户关联的所有设备。In App Purchase期望订阅类商品可以通过外部服务器交付。你必须为多个设备的订阅服务提供相应的支持。 关于注册产品的详细信息,请参考iTunes Connect Developer Guide文档。 交付方式 交付机制在程序In App Purchase的设计和实现种有很重要的意义。有两种基本的模型可以用来交付产品:内置类型(Built-in model)和服务器类型(Server model)。 不管使用那种模型,你都需要维护产品列表,并保证当用户购买后,成功的交付产品。 1. 内置产品类型 使用这种模型。 需要交付的产品已经在程序内部。 这种方式通常用在一些被锁定的功能上。 也可以用来交付在程序束(App Bundle)中的内容。 该方式的一个重要的优点是你可以及时的给客户交付产品,大多数的内置产品应为非消耗性商品。 注意:In App Purchase不提供购买补丁的功能。 如果需要更改app的bundle,你必须向App Store提交新的app版本。 为了标识产品,程序要在bundle中存储产品的标识符。内置模式下,Apple建议使用plist来纪录产品的标识符。 内容类应用可以使用折衷方式很方便的添加新的内容,而不改动程序本身。(原话为: Content-driven applications can use this to add new content without modifying the source for your application,不是很懂,感觉应该是说类似是用plist来管理产品列表,因此就不需要在添加新产品的时候改动程序了。再议。。。) 当成功购买产品后,程序应将锁定的功能解锁,提供给用户。 解锁的最简单方式是修改程序偏好设置(Application Preferences)。 当用户备份手机数据的时候,程序偏好设置也会随之备份。 程序可能需要建议用户在购买产品后备份手机以免丢失购买的内容。 图1-2显示了交付内置型产品的流程。 1. 程序通过bundle存储的plist文件得到产品标识符的列表。 2. 程序向App Store发送请求,得到产品的信息。 3. App Store返回产品信息。 4. 程序把返回的产品信息显示给用户(App的store界面) 5. 用户选择某个产品 6. 程序向App Store发送支付请求 7. App Store处理支付请求并返回交易完成信息。 8. App获取信息并提供内容给用户。 下班再继续吧。
[ 此帖被leon在2011-12-13 15:36重新编辑 ]
图片:built-in.png
2. 服务器类型 使用这种方式,要提供另外的服务器将产品发送给程序。 服务器交付适用于订阅、内容类商品和服务,因为商品可以作为数据发送,而不需改动程序束。 例如,一个游戏提供的新的内容(关卡等)。 Store Kit不会对服务器端的设计和交互做出定义,这方面工作需要你来完成。 而且,Store Kit不提供验证用户身份的机制,你需要来设计。 如果你的程序需要以上功能,例如,纪录特定用户的订阅计划, 你需要自己来设计和实现。 图1-3 展示了服务器类型的购买过程。 1. 程序向服务器发送请求,获得一份产品列表。2. 服务器返回包含产品标识符的列表。3. 程序向App Store发送请求,得到产品的信息。4. App Store返回产品信息。5. 程序把返回的产品信息显示给用户(App的store界面)6. 用户选择某个产品7. 程序向App Store发送支付请求8. App Store处理支付请求并返回交易完成信息。9. 程序从信息中获得数据,并发送至服务器。10. 服务器纪录数据,并进行审查。11. 服务器将数据发给App Store来验证该交易的有效性。12. App Store对收到的数据进行解析,返回该数据和说明其是否有效的标识。13. 服务器读取返回的数据,确定用户购买的内容。14. 服务器将购买的内容传递给程序。Apple建议在服务器端存储产品标识,而不要将其存储在plist中。 这样就可以在不升级程序的前提下添加新的产品。在服务器模式下, 你的程序将获得交易(transaction)相关的信息,并将它发送给服务器。服务器可以验证收到的数据,并将其解码以确定需要交付的内容。 这个流程将在“验证store收据”一节讨论。对于服务器模式,我们有安全性和可靠性方面的顾虑。 你应该测试整个环境来避免威胁。《Secure Coding Guide》文档中有相关的提示说明。虽然非消耗性商品可以用内置模式来恢复,订阅类商品必须通过服务器来恢复。你要负责纪录订阅信息、恢复数据。 消耗类商品也可以通过服务器方式来纪录。例如,由服务器提供的一项服务, 你可能需要用户在多个设备上重新获得结果。
取得产品信息要在程序内部显示“商店”,需要从App Store得到信息来购建界面。 本章详细讲解如何从App Store获取产品信息。向App Store发送请求Store Kit提供了从App Store上请求数据的通用机制。 程序可以创建并初始化一个request对象, 为其附加delegate, 然后启动请求过程。请求将被发送到App Store,在那里被处理。 处理完成时, request对象的delegate方法将被异步调用,以获得请求的结果。 图2-1显示了请求的数据模型。 如果程序在请求期间退出,则需要重新发送请求。下面讲解请求过程中用到的类:SKRequestSKRequest为request的抽象根类。SKRequestDelegateSKRequestDelegate是一个protocol, 实现用以处理请求结果的方法,比如请求成功,或请求失败。发送获得产品信息的请求程序使用products request来获得产品的信息。 要完成这一过程,程序需创建一个request对象,其中会包含一个产品标识的列表。之前提到过,你的程序既可以内置产品列表,又可以通过外部服务器来获得。当发送请求时,产品标识会传送到App Store,App Store将会返回本地化信息(这些信息事先已经在iTunes Connect中设置好了),你将使用这些信息来购建内置商店的界面(显示商品名,描述,等等)。 图2-2显示了请求的过程。 SKProductsRequest用来请求商品的信息。 创建时,我们将需要显示的商品列表加入该对象。SKProductsRequestDelegate该protocol定义了处理App Store响应的方法。 SKProductsResponseSKProductsResponse对象为App Store返回的响应信息。里面包含两个列表(当然是NSArray了):一是经过验证有效的商品,@property(nonatomic, readonly) NSArray *products另外一个是无法被识别的商品信息:@property(nonatomic, readonly) NSArray * invalidProductIdentifiers有几种原因将造成商品标识无法被识别,如拼写错误(当然),被标记为不可出售(unavailable for sale),或是对商品信息的改变没有传送到所有App Store的服务器。(这个原因不是很清楚,再议)。SKProductSKProduct对象包含了在App Store上注册的商品的本地化信息。
购买商品当用户准备购买商品时,程序向App Store请求支付信息,然后App Store将会创建持久化的交易信息,并继续处理支付流程,即使用户重启程序,这个过程亦是如此。App Store同步待定交易的列表到程序中,并在交易状态发生改变时向程序发送更新的数据。收集支付信息要收集支付信息, 你的程序可以创建一个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支付队列用以和App Store之间进行通信。 当新的支付对象被添加到队列中的时候, Store Kit向App Store发送请求。 Store Kit将会弹出对话框询问用户是否确定购买。 完成的交易将会返回给程序的observer对象。SKPaymentTransactiontransaction对象在每次添加新的payment到队列中的时候被创建。 transaction对象包含了一些属性,可以让程序确定当前的交易状态。程序可以从支付队列那里得到一份审核中的交易列表,但更常用的做法还是等待支付队列告知交易状态的更新。SKPaymentTransactionObserver在程序中实现SKPaymentTransactionObserver的协议,然后把它作为SKPaymentQueue对象的观察者。该观察者的主要职责是:检查完成的交易,交付购买的内容,和把完成后的交易对象从队列中移除。在程序一启动,就应该为支付队列指定对应的观察者对象,而不是等到用户想要购买商品的时候。 Transaction对象在程序退出时不会丢失。程序重启时, Store Kit继续执行未完成的交易。 在程序初始化的时候添加观察者对象,可以保证所有的交易都被程序接收(也就时说,如果有未完成的transaction,如果程序重启,就重新开始了,如果稍候再添加观察者,就可能会漏掉部分交易的信息)。恢复交易信息(Transactions)当transaction被处理并从队列移除之后,正常情况下,程序就再也看不到它们了。 如果你的程序提供的是非消耗性的或是订阅类的商品,就必须提供restore的功能,使用户可以在其他设备上重新存储购买信息。Store Kit提供内建的功能来重新存储非消耗商品的交易信息。 调用SKPaymentQueue的restoreCompletedTransactions的方法来重新存储。对于那些之前已经完成交易的非消耗性商品,Apple Store生成新的,用于恢复的交易信息。 它包含了原始的交易信息。你的程序可以拿到这个信息,然后继续为购买的功能解锁。 当之前所有的交易都被恢复时, 就会调用观察者对象的paymentQueueRestoreCompletedTransactionsFinished方法。如果用户试图购买已经买过的非消耗性商品,程序会收到一个常规的交易信息,而不是恢复的交易信息。但是用户不会被再次收费。程序 应把这类交易和原始的交易同等对待。订阅类服务和消耗类商品不会被Store Kit自动恢复。 要恢复这些商品,你必须在用户购买这些商品时,在你自己的服务器上记录这些交易信息, 并且为用户的设备提供恢复交易信息的机制。
在程序中添加Store功能 本章为添加购买功能的指导 详细流程: 准备工作当然是添加StoreKit.framework了。 然后是具体的步骤: 1. 决定在程序内出售的商品的类型。 之前提到过,程序内可以出售的新feature类型是有限制的。 Store Kit不允许我们下载新的代码。 你的商品要么可以通过当前的代码工作(bundle类型),要么可以通过服务器下载(当然,这里下载的为数据文件,代码是不可以的)。 如果要修改源代码,就只能老实的升级了。 2. 通过iTunes Connect注册商品 每次添加新商品的时候都需要执行这一步骤。 每个商品都需要一个唯一的商品标识。 App Store通过这个标识来查找商品信息并处理支付流程。 注册商品标识的方法和注册程序的方法类似。 要了解如何创建和注册商品信息,请参考“iTunes Connect Developer Guide”文档。 3. 检测是否可以进行支付 用户可以禁用在程序内部支付的功能。在发送支付请求之前,程序应该检查该功能是否被开启。程序可在显示商店界面之前就检查该设置(没启用就不显示商店界面了),也可以在用户发送支付请求前再检查,这样用户就可以看到可购买的商品列表了。 例子: if([SKPaymentQueue canMakePayments]) { ...//Display a store to the user } else { ...//Warn the user that purchases are disabled. } 4. 获得商品的信息 程序创建SKProductsRequest对象,用想要出售的商品的标识来初始化, 然后附加上对应的委托对象。 该请求的响应包含了可用商品的本地化信息。 //这里发送请求 - (void)requestProductData { SKProductsRequest *request = [[SKProductsRequest alloc]initWithProductIdentifiers: [NSSet setWithObject: kMyFeatureIdentifier]]; request.delegate = self; [request start]; } //这个是响应的delegate方法 - (void)productsRequest: (SKProductsRequest *)request didReceiveResponse: (SKProductsResponse *)response { NSArray *myProduct = response.products; //生成商店的UI [request autorelease]; } 5. 添加一个展示商品的界面 Store Kit不提供界面的类。 这个界面需要我们自己来设计并实现。 6. 为支付队列(payment queue)注册一个观察者对象 你的程序需要初始化一个transaction observer对象并把它指定为payment queue的观察者。 上代码: MyStoreObserver *observer = [[MyStoreObserver alloc]init]; [[SKPaymentQueue defaultQueue]addTransactionObserver: observer]; 应该在程序启动的时候就添加好观察者,原因前面说过,重启后程序会继续上次未完的交易,这时就添加观察者对象就不会漏掉之前的交易信息。 7. 在MyStoreObserver类中执行paymentQueue: updatedTransactions: 方法。 这个方法会在有新的交易被创建,或者交易被更新的时候被调用。 - (void)paymentQueue: (SKPaymentQueue *)queue updatedTransactions: (NSArray *)transactions { for(SKPaymentTransaction * transaction in transactions) { switch(transaction.transactionState) { case SKPaymentTransactionStatePurchased: [self completeTransaction: transaction]; break; case SKPaymentTransactionStateFailed: [self failedTransaction: transaction]; break; case SKPaymentTransactionStateRestored: [self restoreTransaction: transaction]; default: break; } } } 上面的函数针对不同的交易返回状态,调用对应的处理函数。 8. 观察者对象在用户成功购买一件商品时,提供相应的内容,以下是在交易成功后调用的方法 - (void) completeTransaction: (SKPaymentTransaction *)transaction { //你的程序需要实现这两个方法 [self recordTransaction: transaction]; [self provideContent: transaction.payment.productIdentifier]; //将完成后的交易信息移出队列 [[SKPaymentQueue defaultQueue]finishTransaction: transaction]; } 交易成功的信息包含transactionIdentifier和transactionReceipt的属性。其中,transactionReceipt记录了支付的详细信息,这个信息可以帮助你跟踪、审查交易,如果你的程序是用服务器来交付内容,transactionReceipt可以被传送到服务器,然后通过App Store验证交易。(之前提到的server模式,可以参考以前的图) 9. 如果交易是恢复过来的(restore),我们用这个方法来处理: - (void) restoreTransaction: (SKPaymentTransaction *)transaction { [self recordTransaction: transaction]; [self provideContent: transaction.payment.productIdentifier]; [[SKPaymentQueue defaultQueue] finishTransaction: transaction]; } 这个过程完成购买的过程类似。 恢复的购买内容提供一个新的交易信息,这个信息包含了新的transaction的标识和receipt数据。 如果需要的话,你可以把这些信息单独保存下来,供追溯审查之用。但更多的情况下,在交易完成时,你可能需要覆盖原始的transaction数据,并使用其中的商品标识。 10. 交易过程失败的话,我们调用如下的方法: - (void)failedTransaction: (SKPaymentTransaction *)transaction { if(transaction.error.code != SKErrorPaymentCancelled) { //在这类显示除用户取消之外的错误信息 } [[SKPaymentQueue defaultQueue] finishTransaction: transaction]; } 通常情况下,交易失败的原因是取消购买商品的流程。 程序可以从error中读出交易失败的详细信息。 显示错误信息不是必须的,但在上面的处理方法中,需要将失败的交易从支付队列中移除。 一般来说,我们用一个对话框来显示错误信息,这时就应避免将用户取消购买这个error显示出来。 11. 组织好程序内“商店”的UI。当用户选择一件商品时, 创建一个支付对象,并放到队列中。 SKPayment *payment = [SKPayment paymentWithProductIdentifier: kMyFeatureIdentifier]; [[SKPaymentQueue defaultQueue] addPayment: payment]; 如果你的商店支持选择同一件商品的数量,你可以设置支付对象的quantity属性 SKMutablePayment *payment = [SKMutablePayment paymentWithProductIdentifier: kMyFeatureIdentifier]; payment.quantity = 3; [[SKPaymentQueue defaultQueue] addPayment: payment]; 下一步: 本章中所示代码可用于内置型商品模式(Built-in)。 如果你的程序要使用服务器来发布商品,你需要负责设计和执行iPhone程序和你的服务器之间的通信。服务器应该验证数据并为程序提供内容。 验证store的收据 使用服务器来交付内容,我们还需要做些额外的工作来验证从Store Kit发送的收据信息。 重要信息:来自Store的收据信息的格式是专用的。 你的程序不应直接解析这类数据。可使用如下的机制来取出其中的信息。 验证App Store返回的收据信息 当交易完成时,Store Kit告知payment observer这个消息,并返回完成的transaction。 SKPaymentTransaction的transactionReceipt属性就包含了一个经过签名的收据信息,其中记录了交易的关键信息。你的服务器要负责提交收据信息来确定其有效性,并保证它未经过篡改。 这个过程中,信息被以JSON数据格式发送给App Store,App Store也以JSON的格式返回数据。 (大家可以先了解一下JSON的格式) 验证收据的过程: 1. 从transaction的transactionReceipt属性中得到收据的数据,并以base64方式编码。 2. 创建JSON对象,字典格式,单键值对,键名为"receipt-data", 值为上一步编码后的数据。效果为: { "receipt-data" : "(编码后的数据)" } 3. 发送HTTP POST的请求,将数据发送到App Store,其地址为: 4. App Store的返回值也是一个JSON格式的对象,包含两个键值对, status和receipt: { "status" : 0, "receipt" : { … } } 如果status的值为0, 就说明该receipt为有效的。 否则就是无效的。 App Store的收据 发送给App Store的收据数据是通过对transaction中对应的信息编码而创建的。 当App Store验证收据时, 将从其中解码出数据,并以"receipt"的键返回。 返回的响应信息是JSON格式,被包含在SKPaymentTransaction的对象中(transactionReceipt属性)。Server可通过这些值来了解交易的详细信息。 Apple建议只发送receipt数据到服务器并使用receipt数据验证和获得交易详情。 因为App Store可验证收据信息,返回信息,保证信息不被篡改,这种方式比同时提交receipt和transaction的数据要安全。(这段得再看看) 表5-1为交易信息的所有键,很多的键都对应SKPaymentTransaction的属性。 备注:一些键取决于你的程序是链接到App Store还是测试用的Sandbox环境。更多关于sandbox的信息,请查看"Testing a Store"一章。 Table 5-1 购买信息的键: 键名 描述 quantity 购买商品的数量。对应SKPayment对象中的quantity属性 product_id 商品的标识,对应SKPayment对象的productIdentifier属性。 transaction_id 交易的标识,对应SKPaymentTransaction的transactionIdentifier属性 purchase_date 交易的日期,对应SKPaymentTransaction的transactionDate属性 original_-transaction_id 对于恢复的transaction对象,该键对应了原始的transaction标识 original_purchase_-date 对于恢复的transaction对象,该键对应了原始的交易日期 app_item_id App Store用来标识程序的字符串。一个服务器可能需要支持多个server的支付功能,可以用这个标识来区分程序。链接sandbox用来测试的程序的不到这个值,因此该键不存在。 version_external_-identifier 用来标识程序修订数。该键在sandbox环境下不存在 bid iPhone程序的bundle标识 bvrs iPhone程序的版本号 测试Store功能 开发过程中,我们需要测试支付功能以保证其工作正常。然而,我们不希望在测试时对用户收费。 Apple提供了sandbox的环境供我们测试。 备注:Store Kit在模拟器上无法运行。 当在模拟器上运行Store Kit的时候,访问payment queue的动作会打出一条警告的log。测试store功能必须在真机上进行。 Sandbox环境 使用Sandbox环境的话,Store Kit并没有链接到真实的App Store,而是链接到专门的Sandbox环境。 SandBox的内容和App Store一致,只是它不执行真实的支付动作。 它会返回交易成功的信息。 Sandbox使用专门的iTunes Connect测试 账户。不能使用正式的iTunes Connect账户来测试。 要测试程序,需要创建一个专门的测试账户。你至少需要为程序的每个区域创建至少一个测试账户。详细信息,请查看iTunes Connect Developer Guide文档。 在Sandbox环境中测试 步骤: 1. 在测试的iPhone上退出iTunes账户 Settings中可能会记录之前登录的账户,进入并退出。 重要信息:不能在Settings 程序中通过测试账户登录。 2. 运行程序 当你在程序的store中购买商品后,Store kit提示你去验证交易。用测试账户登录,并批准支付。 这样虚拟的交易就完成了。 在Sandbox中验证收据 验证的URL不同了: NSURL *sandboxStoreURL = [[NSURL alloc]initWithString: @"https://sandbox.itunes.apple.com/verifyReceipt"]; 自动更新的订阅服务 In-App Purchase提供了自动更新型订阅服务的标准方式。自动更新型订阅有如下新的显著特征: 1. 当你在iTunes Connect中配置自动更新型订阅服务时,需要同时指定更新周期和其他的促销选项。 2. 自动更新型订阅服务会被自动恢复(使用Store Kit中恢复非消费型商品一样的函数)。原始的交易信息会和更新的交易信息一起发送给你的程序。详情请查看“Restoring Transactions”一节。 3. 当你的服务器向App Store验证收据(receipt),订阅服务被激活并更新时,App store会向你的app返回更新后的收据信息。 为你的商店添加自动更新型订阅服务 按以下步骤来实现自动更新型订阅服务: 1. 连接iTunes Connect网站,并创建一个共享密钥。共享密钥是一个密码,你的服务器在验证自动更新型订阅服务的时候必须提供这个密码。共享密钥为App Store的交易增加了一层保护。(详情,请参考iTunes Connect Developer Guide文档) 2. 在iTunes Connect中创建并配置新的自动更新型订阅服务商品。 3. 修改服务器端关于验证收据部分的代码,添加共享密钥到验证信息用的JSON数据中。服务器的验证代码需要可以解析App store的返回数据以判断订阅是否过期。如果订阅服务已经被用户更新,最新的收据也会返回给你的server。 设计iOS客户端 大多数情况下,iOS客户端程序应做出最小新改来支持自动更新型订阅服务。事实上,客户端程序需要做的更简单,你可以使用非消费型(non-consumable)商品的流程来做自动更新型订阅服务的事情。你的程序在不同时期会收到单独的交易信息来告知订阅已被更新。程序应该单独验证每一条收据。 验证自动更新型订阅服务的收据 验证自动更形型订阅服务的收据和之前讲到的“验证收据”的方式一致。你的程序创建一个JSON对象并把它发送给App Store。自动更新型订阅服务的JSON对象必须包含另外的参数——就是你在iTunes Connect中创建的共享密钥。 { "receipt-data" : "(actual receipt bytes here)" "password" : "(shared secret bytes here)" } 返回内容包含了状态信息,用来标识收据是否验证有效。 { "status" : 0, "receipt" : { ... } "latest_receipt" : "(base-64 encoded receipt)" "latest_receipt_info" : { ... } } 如果用户的收据是有效的,订阅被激活,则status的值为0。receipt对应的值为解码后的收据信息。如果你的服务器收到了非零值的状态码,对照表7-1查看: 表7-1 自动更新型订阅服务返回状态码 状态码 描述 21000 App Store无法读取你提供的JSON数据 21002 收据数据不符合格式 21003 收据无法被验*****br />21004 你提供的共享密钥和账户的共享密钥不一致 21005 收据服务器当前不可用 21006 收据是有效的,但订阅服务已经过期。当收到这个信息时,解码后的收据信息也包含在返回内容中 21007 收据信息是测试用(sandbox),但却被发送到产品环境中验*****br />21008 收据信息是产品环境中使用,但却被发送到测试环境中验*****br />注意:在这里的非零状态码只是针对自动更新型订阅服务,不能将这些状态码用在测试其他类型产品的返回值中。 JSON数据中的receipt栏位包含了解析过的收据信息。自动更新型订阅服务包含了一些新加的信息。请参考表7-2: 表7-2 自动更新型订阅服务的信息: 键名 描述 expires_date 订阅的过期时间,显示方式是从Jan 1, 1970, 00:00:00 GMT计算到过期时间的毫秒数。这个键不包含在恢复的交易信息中。 original_transaction_id 初次购买的交易标识。所有订阅的更新和恢复交易都共享这个标识 original_purchase_date 初次购买(订阅)的日期。 purchase_date 交易的日期。对于更新订阅的交易来说,这个日期表示更新日期。如果从App Store解析的数据是最新的订阅收据,这个值表示最近更新订阅的日期。 除了receipt-Data信息外,返回内容还可能包含另外两个信息。如果用户的订阅服务被激活并更新。则latest_receipt信息会被以base-64方式编码并包含在返回内容中。解码后的新的收据信息也会在latest_expired_receipt_info包含。你的服务器可以使用新的收据来维护最新更新订阅的信息。