转载自【黑米GameDev街区】 原文链接: http://www.himigame.com/iphone-cocos2d/550.html
//——2012-12-11日更新 获取”产品付费数量等于0这个问题”的原因
看到很多童鞋问到，为什么每次都返回数量等于0？？
其实有童鞋已经找到原因了，原因是你在 ItunesConnect 里的 “Contracts, Tax, and Banking ”没有完成设置账户信息。
确定 ItunesConnect 里 “Contracts, Tax, and Banking ”的状态，如下图所示，即可：
这里也是由于Himi疏忽的原因没有说明，这里先给童鞋们带来的麻烦，致以歉意。
//——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”
然后我运行项目截图如下以及运行控制台打印的信息如下：
这里Himi最后一张截图是没有购买成功，这里Himi是故意截图出来的，原因就是想告诉童鞋们： :tx:
如果你的产品信息能够正常得到，但是始终无法成功的话，不要着急，因为你的产品要进入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
