In-App Purchase通信结构设计

In-App Purchase通信结构设计

1. iOS App 向 Developer Server 发送请求，获得一份产品列表（一般都是 Product ID）。
   获取产品列表需要 iOS App 主动获得，这样就可以在不升级iOS的情况下添加产品。
2. Developer Server 返回给 iOS App 包含 Product ID 的列表。
3. iOS App 向 App Store 发送请求，期望获得到产品的信息。
4. App Store 返回本地化产品信息。
   所谓本地化的产品信息指的是会根据目前所在的地区返回所在地区的描述信息。
   比如在中国地区，如果该产品有中文的描述，返回中文的描述，
   而如果你在美国，则返回的是英文的描述。
5. iOS App 把返回的产品信息显示给用户（iOS App 的 Store 界面）
   这个就是商店界面了，包括，在前面请求希望获得产品信息的时候的等待界面。
6. 用户选择某个产品。
7. iOS App 向 App Store 发送支付请求。
8. App Store 处理支付请求并返回交易完成信息。
9. iOS App从返回交易完成的信息中获得数据，并发送至 Developer Server。
10. Developer Server 记录数据，并进行审查。
    App Store Server 对于消耗型的商品，是不会保存购买记录的，所以需要 Developer 同步记录到 Developer Server 上。
    App Store Server 对于非消耗性的商品，在 App Store Server 是有记录可以查询的，可以通过 Restore 的方法恢复。
    而恢复的交易信息是新的，但是包含原始的交易信息。
    因此用户试图购买已经买过的非消耗性的商品时，iOS App 收到一个常规的交易信息，而不是恢复的交易信息，
    只不过用户不会被再次付费。因此程序应该把这类交易和原始的交易同等对待。
    其他订阅型的暂时没有测试。
    Developer Server 这边需要做逻辑的严格审查，看是否合理。
11. Developer Server 将数据发给 App Store来验证该交易的有效性。
12. App Store对收到的数据进行解析，返回该数据和说明其是否有效的标识。
    App Store 有效性的验证地址会根据是测试还是实际购买有所不同
    测试：也称为Sandbox环境 https://sandbox.itunes.apple.com/verifyReceipt
    实际：https://buy.itunes.apple.com/verfyReceipt
13. Developer Server 读取返回的数据，确定用户购买的内容。
14. Developer Server 将购买的内容传递给 iOS App。
15. iOS App 根据购买最早的结果进行处理。

上面为目前比较通用的In-App Purchase通信结构设计的做法，粗体部分为注意事项。

Related posts:

1. 《Running Panda》移动游戏开发心得分享 – 入门

2. 1. AIR Native Extension实现iOS应用内付费(In-App Purchase)全教程（二）——AIR面向iOS设备的原生扩展 : : 9RIA.Com 天地会博客聚合
      十月 8th, 2011 at 10:44 上午

   2. AIR Native Extension实现iOS应用内付费(In-App Purchase)全教程（三）——iOS应用内付费简介和准备流程 : : 9RIA.Com 天地会博客聚合
      十月 8th, 2011 at 10:46 上午

   3. AIR Native Extension实现iOS应用内付费(In-App Purchase)全教程（四）——ANE面向IAP的测试和开发 : : 9RIA.Com 天地会博客聚合