In App Purchase的介绍

最近做项目，要用到支付功能，搜集一些资料分享给大家。

In App Purchase（程序内购买）为苹果开发人员们打开了一个新的盈利渠道，如果您对此并不了解，下面这段 CocoaChina 会员“leon”翻译的 In App Purchase 详细介绍一定不能错过。

一、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. 订阅类。订阅类商品拥有以上两种类型的特性。和消耗性商品一样，订阅类商品可以被多次购买； 你可以在程序内部加入自己的订阅计划更新机制。 另外，订阅类商品必须提供给和某一用户关联的所有设备。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. 程序通过bundle存储的plist文件得到产品标识符的列表。
2. 程序向App Store发送请求，得到产品的信息。
3. App Store返回产品信息。
4. 程序把返回的产品信息显示给用户（App的store界面）
5. 用户选择某个产品
6. 程序向App Store发送支付请求
7. App Store处理支付请求并返回交易完成信息。
8. App获取信息并提供内容给用户。

2. 服务器类型使用这种方式，要提供另外的服务器将产品发送给程序。 服务器交付适用于订阅、内容类商品和服务，因为商品可以作为数据发送，而不需改动程序束。 例如，一个游戏提供的新的内容（关卡等）。 Store Kit不会对服务器端的设计和交互做出定义，这方面工作需要你来完成。 而且，Store Kit不提供验证用户身份的机制，你需要来设计。 如果你的程序需要以上功能，例如，纪录特定用户的订阅计划， 你需要自己来设计和实现。

服务器类型的购买过程

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》文档中有相关的提示说明。

    虽然非消耗性商品可以用内置模式来恢复，订阅类商品必须通过服务器来恢复。你要负责纪录订阅信息、恢复数据。 消耗类商品也可以通过服务器方式来纪录。例如，由服务器提供的一项服务， 你可能需要用户在多个设备上重新获得结果