【iOS开发必收藏】详解iOS应用程序内使用IAP/StoreKit付费、沙盒（SandBox）测试、创建测试账号流程！2012-6-25日更新iap恢复

转载自：http://www.himigame.com/iphone-cocos2d/550.html

本站文章均为 李华明Himi 原创,转载务必在明显处注明：

转载自【黑米GameDev街区】 原文链接: http://www.himigame.com/iphone-cocos2d/550.html



　　　　　　　　　　☞
点击订阅 ☜ 本博客最新动态!及时将最新博文通知您！

//——2012-6-25日更新iap恢复

看到很多童鞋说让Himi讲解如何恢复iap产品，其实博文已经给出了。这里再详细说下:

首先向AppStore请求恢复交易：

然后当用户输入正确的appStore账号密码后，进入

- (void)paymentQueue:(SKPaymentQueue *)queue updatedTransactions:(NSArray *)transactions//交易结果

进入上面函数中的

然后我们再以下重写函数中处理即可！

- (void) restoreTransaction: (SKPaymentTransaction *)transaction

//——-

在应用内嵌入付费代码这一快Himi可以直接将代码分享给大家，所以我们来说一些主要流程，毕竟没有接触过这一块的童鞋肯定相当头疼 =。 =

OK，步入整体，如果你想在iOS里内嵌收费，那么分为以下几步：

【提示：以下创建App部分内容，你不用非要等项目能打包了才开始做，可以随时并且随便的创建个测试项目即可，因为嵌入付费并不要求上传App的ipa包的！！】

第一步：你需要在iTunesConnect中创建个新的App，然后为这个App设置一些产品（付费道具）等；

OK，这里Himi稍微解释下，iTunesConnect是苹果提供的一个平台，主要提供AP发布和管理App的，最重要的功能是创建管理项目信息，项目付费产品（道具）管理、付费的测试账号、提交App等等，这里就简单介绍这么多，关于产品一词在此我们可以理解成游戏道具即可；在苹果看来所有付费都属于产品 =。 =千万不要纠结字眼哦～

OK，打开iTunesConnect网站：https://itunesconnect.apple.com/WebObjects/iTunesConnect.woa (注意：企业级的用户必须使用公司主开发者账号登陆才可！)

成功登陆后的页面如下：





这里大概说下重要的一些项：

Contracts, Tax, and Banking ： 管理银行账号、联系人以及税等等；这里要根据提示完成对应的信息填写！一定要详细填写喔～

Manage Users ：管理用户的，比如主账号以及测试付费的（测试App）账号；

Manage Your Applictions：管理应用程序的，你所有发布的应用和每个应用的状态都在这里面；

下面我们新建一个App项目，大家放心，我们这里创建的是不会直接提交给App审核的，所以放心创建，只要控制好App的状态不要是待审核状态即可，不过即使你不小心将项目提交了，也没事，直接更改App状态即可了；

选择Manage Your Applictions选项，然后新建一个项目：【Add New App】，根据提示来填写吧，这里就不细致说明了～

创建好一个App之后，在点击Manage Your Applictions后的界面应该如下：





这里你将看到自己创建的App，点击你创建的App项目，这里Himi创建的项目名字叫”ProjectForBuyTest“，点击你的App进入如下界面：





(注意：这里的Bundle ID一定要跟你的项目中的info.plist中的Bundle ID保证一致！！！！）

这里可以管理你的项目的信息、状态、是否嵌入GameCenter等等选项，那么本章我们重点介绍如何使用IAp沙盒测试程序内付费，所以这里我们点击右上角的”Manage In-App Purchases“选项进入创建产品（游戏道具）界面如下：





上图中的下方看到Himi创建过的四个产品（道具）了，你可以点击”Create New“选项新建一个产品（付费道具），点击新建如下界面：





上图中Himi没有截图出所有的选项，这里大概介绍下，这个界面是选择你的消费道具的种类，种类说明如下：

类型选择有四种选择：

1.Consumable（消耗品）: 每次下载都需要付费；

2.Non-consumable（非消耗品）: 仅需付费一次；

3.Auto-Renewable Subscriptions：自动订阅；

4.Free Subscription：免费订阅

最下方是你沙盒测试的截图，暂且不管即可；

这里Himi选择Consumable选项，比如很多游戏都是购买金币啦这样子就可以选择这个；然后出现如下界面：





Reference Name： 付费产品（道具的）参考名称

Product ID（产品ID）: 你产品的唯一id。通常格式是 com.xx.yy，但它可以是任何形式，不要求以程序的App ID作为前缀。

Add Language: 添加产品名称与描述语言；

Price Tier：选择价格，这里你选择价格后，会出现如上图最下方的价格对照表

Screenshot（截屏）: 展示你产品的截屏。（这个直接无视，测试App务必要管这个的）

Product ID（产品ID）可以创建多个，比如我想游戏中分为0.99$ 、1.99$等道具那就创建对应多个产品ID！

我们填写好了”Reference Name“与”Product ID“以及”Price Tier“后，点击”Add Language“选项然后出现如下界面：





上图中的选项：

Language：语言

Displayed Name（显示名称）: 用户看到的产品名称。

Description（描述）: 对产品进行描述。

Ok，一路 Save保存回到”Manage In-App Purchases“界面中会看到我们新建的产品（道具）如下：





大家可以看到新建的产品（道具）ID：这里Himi创建的产品ID是com.himi.wahaha ，这里要记住这个产品ID哦～

第二步：申请测试账号，利用沙盒测试模拟AppStore购买道具流程！

回到itunesconnect主页中，选择“Manage Users”然后选择“Test User”，然后出现的界面如下图：





这里Himi已经创建了两个测试账号了，点击界面中的 “Add New User”进行创建即可；记住账号和密码哈，记不住就删掉重新建 娃哈哈～（切记：不能用于真正的AppStore中使用此账号，不仅不能用，而且一旦AppStore发现后果你懂得～）

第三步：在项目中申请购买产品代码以及监听；

这里关于购买的代码部分呢，我都有备注的，Himi这里就不详细讲解了，Himi只是在代码后介绍几点值得注意的地方：

这里Himi是新建的一个Cocos2d的项目，然后给出HelloWorldLayer.h以及HelloWorldLayer.m的全部代码，所有购买代码也全在里面也对应有Himi的注释！

HelloWorldLayer.h

HelloWorldLayer.m

代码注释的相当清楚了，没有什么可解释的，这里说几点值得注意的地方：

1.添加对应对应代码时不要忘记，添加框架 StoreKit.framework,如何添加框架请看我的博文【iOS-Cocos2d游戏开发之十四】音频/音效/视频播放（利用Cocos2D-iPhone-Extensions嵌入Cocos2d进行视频播放！）！

2. 越狱机器无法沙盒测试！模拟器的话，Himi用4.3模拟器不可以，因为提示没有开启程序内付费- -（我都没看到模拟器有store的选项，so～）；但是使用iOS5的模拟器可以测试沙盒，但是执行的顺序会有些问题，但是还没真机的童鞋可以使用，建议一切以真机实测为准

3. 千万不要忘记在iTunesConnect中创建App Bundle ID一定要跟你的项目中的info.plist中的Bundle ID保证一致！！！！

4. 以上代码中你需要修改的就是我在HelloWorldLayer.m类中的宏定义的Product ID(产品ID)，例如Himi刚才新建了一个产品ID是“com.himi.wahaha”

然后我运行项目截图如下以及运行控制台打印的信息如下：
















[b]这里Himi最后一张截图是没有购买成功，这里Himi是故意截图出来的，原因就是想告诉童鞋们：

[/b]

如果你的产品信息能够正常得到，但是始终无法成功的话，不要着急，因为你的产品要进入iTunes Connect，并且Apple准备好沙箱环境需要一些时间。Himi之前遇到过，然后在过了段时间后我没有修改任何一行代码，但产品ID变为有效并能成功购买。=。
=郁闷ing~~ 其实要使产品发布到Apple的网络系统是需要一段时间的，so～这里别太着急！

越狱机器无法正常测试沙盒的喔～

顺便提示一下：Bundle ID 尽可能与开发者证书的app ID 一致。

好了，写了这么多了，咳咳、Himi继续忙了，做iOS的童鞋们我想此篇将成为你必须收藏的一篇哦～嘿嘿！

2012-3-13日更新内容：

1.验证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，其地址为:

https://buy.itunes.apple.com/verifyReceipt

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“];

2. 自动更新的订阅服务

In-App Purchase提供了自动更新型订阅服务的标准方式。自动更新型订阅有如下新的显著特征：

1. 当你在iTunes Connect中配置自动更新型订阅服务时，需要同时指定更新周期和其他的促销选项。

2. 自动更新型订阅服务会被自动恢复（使用Store Kit中恢复非消费型商品一样的函数）。原始的交易信息会和更新的交易信息一起发送给你的程序。详情请查看“Restoring Transactions”一节。

3. 当你的服务器向App Store验证收据（receipt），订阅服务被激活并更新时，App store会向你的app返回更新后的收据信息。

3.为你的商店添加自动更新型订阅服务

按以下步骤来实现自动更新型订阅服务：

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 收据无法被验证

21004 你提供的共享密钥和账户的共享密钥不一致

21005 收据服务器当前不可用

21006 收据是有效的，但订阅服务已经过期。当收到这个信息时，解码后的收据信息也包含在返回内容中

21007 收据信息是测试用（sandbox），但却被发送到产品环境中验证

21008 收据信息是产品环境中使用，但却被发送到测试环境中验证

注意：在这里的非零状态码只是针对自动更新型订阅服务，不能将这些状态码用在测试其他类型产品的返回值中。

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包含。你的服务器可以使用新的收据来维护最新更新订阅的信息。

4. 如果交易是恢复过来的（restore），我们用这个方法来处理：

- (void) restoreTransaction: (SKPaymentTransaction *)transaction

{

[self recordTransaction: transaction];

[self provideContent: transaction.payment.productIdentifier];

[[SKPaymentQueue defaultQueue] finishTransaction: transaction];

}

这个过程完成购买的过程类似。 恢复的购买内容提供一个新的交易信息，这个信息包含了新的transaction的标识和receipt数据。 如果需要的话，你可以把这些信息单独保存下来，供追溯审(我们的)查之用。但更多的情况下，在交易完成时，你可能需要覆盖原始的transaction数据，并使用其中的商品标识。

更新内容参考文章：http://www.cocoachina.com/bbs/read.php?tid-24738.html