请教一个IAP问题：如何同步服务器和客户端的购买信息

应该是吧，服务器向Apple验证receipt的时候不也有可能发生异常吗。。。
总得验证了购买结果才算完成嘛
之前也遇到过这问题，不过那个项目没进行下去。。。

[[SKPaymentQueue defaultQueue] finishTransaction:transaction];
只要不finish 下次点击应该还是会走一遍流程，这时候你加判断。如果post receipt to sever失败重试3次，如果3次还是失败，弹出feedback 发送email给客服。

我就是这么搞的。
另外，还需要考虑服务器和苹果验证时超时的情况，有些时候苹果的服务器会超时。另外，攻击者会拿另外的支付成功的凭证来欺骗，记得验证凭证的bundle id

@satgi
@shellcodecow
@tangqiaoboy
谢谢

@shellcodecow 等服务器接口好了，试试这个方法。但有个疑问，在finishTransaction之前通知服务器向Apple验证，此时Apple给服务器的结果应该是已购买成功了吧？难道如果不调用finishTransaction，Apple还会重置为未购买？Transaction使用了长连接？

不会重置为未购买，SKPaymentTransactionStatePurchased就说明购买成功了，但是这时候购买成功只有你知道啊，你还需要完成验证交易，提供下载，解锁啊啥的，调用finishTransaction之后相应的那个payment才会从payment queue当中移除。

跑个题，为什么是consumable而不是subscription?

@ewangke 比如某个用户已买了一个月会员，在一个月结束前，就可以续费

@doubleone subscription不行么？这不是典型的场景

@ewangke 我的理解是 这就像游戏中买积分一样 所以选择了consumable

@doubleone 你理解得也有道理，但我担心被苹果拒。上线了么

@ewangke 之前的版本没有iap 已上线 新版还在开发中

@ewangke 你做过类似的 用的是subscription？

@doubleone 没做过
不过App Store上这类的都是subscription

@ewangke 怎么看出来的？没看到这类信息 pptv：https://itunes.apple.com/cn/app/pptv-wang-luo-dian-shihd-zui/id405667771?mt=8

@doubleone 好吧，既然你以国内发行商的标准

@ewangke 话说这和是不是国内发行商没什么关系吧？如果有更好的方式，应当学习。我想知道的是你是如何看出是consumable还是subscription？麻烦举个国外的例子

@ewangke http://stackoverflow.com/questions/2218539/in-app-purchase-subscription-vs-consumable

@doubleone
这个SO的link能说明什么，跟你的情况完全没有关系
NYTimes这类订阅用户，本质就是会员，通过订阅的方式获得每月的付费内容
续费不是可以auto renewable么？
只有开发者才完全清楚后面是什么模型，PPTV未必像你说的那样；非要跟苹果反着来，只有自己吃亏

@doubleone

你说的也不是完全不行，但总觉得很别扭。希望你们产品上线后，可以回来回这个贴，跟大家说说结果。
如果使用Consumable, 比如我买了两个1个月的迅雷会员，放在那里不用，又可以随时用掉。
Skype的点数/VPN流量/游戏金币，适合用consumable类型。

附：
http://developer.apple.com/library/ios/#documentation/NetworkingInternet/Conceptual/StoreKitGuide/APIOverview/OverviewoftheStoreKitAPI.html

Consumable products must be purchased each time the user needs that item. For example, one-time services are commonly implemented as consumable products.

分割线

Auto-renewable subscriptions are delivered to all of a user’s devices in the same way as non-consumable products. However, auto-renewable subscriptions differ in other ways. When you create an auto-renewable subscription in iTunes Connect, you choose the duration of the subscription. The App Store automatically renews the subscription each time its term expires. If the user chooses to not allow the subscription to be renewed, the user’s access to the subscription is revoked after the subscription expires. Your application is responsible for validating whether a subscription is currently active and can also receive an updated receipt for the most recent transaction.

Non-renewing subscriptions are a mechanism for creating products with a limited duration. Non-renewing subscriptions differ from auto-renewable subscriptions in a few key ways:

The term of the subscription is not declared when you create the product in iTunes Connect; your application is responsible for providing this information to the user. In most cases, you would include the term of the subscription in the description of your product.

Non-renewing subscriptions may be purchased multiple times (like a consumable product) and are not automatically renewed by the App Store. You are responsible for implementing the renewal process inside your application. Specifically, your application must recognize when the subscription has expired and prompt the user to purchase the product again.

You are required to deliver non-renewing subscriptions to all devices owned by the user. Non-renewing subscriptions are not automatically synchronized to all devices by Store Kit; you must implement this infrastructure yourself. For example, most subscriptions are provided by an external server; your server would need to implement a mechanism to identify users and associate subscription purchases with the user who purchased them.

@ewangke it should be non-renewing subscriptions.

@doubleone 请教一下，non-renewing和auto-renewing一般如何按场景区分使用

@ewangke 我的理解是non-renewing需要由自己去管理订阅 比如会员 其中会有苹果无法控制的东西 像是特权之类的
而auto－renewing苹果已经提供了管理方案 适合杂志之类的传统订阅服务

我的做法：purchasedReceipt每次发送前，都做本地保存。
发送成功后，移除purchasedReceipt。
发送失败，提示用户网络异常或者服务器异常，并提供联系方式。

在每次becameActive时候，判断是否有purchasedReceipt，有的话，发送到后台，成功才移除，出错就在每次Active都继续发送。

不知道这样是否会有什么问题？

@chisj 基本一样 保存在keychain里 不成功时告知用户会之后自动验证

@doubleone 多谢，我的版本还没发出去呢。