1.简介
苹果内购是指Apple Store的应用内购买，是苹果为App内购买虚拟商品或服务提供的一套交易系统。
1.1内购商品类型
1.1.1消耗类型商品
该类型适用于可多次购买的消耗型项目，如游戏道具、虚拟币等。
1.1.2非消耗类型商品
该类型适用于一次购买永久有效的项目，如电子书、游戏关卡等。
该类型项目支持跨设备同步和本地restore，比如说，用户在某个App中购买了一本书，可在所有相同Apple ID设备的App中免费获取这本书，而不要需要借助App本身的帐号体系，即使在App中删除了这本书，也可免费重新获取。
1.1.3自动续费的订阅商品
该类型适用于自动续费的订阅项目，如Apple Music的按月订阅，用户购买后会每月自动续费，直到用户手动取消或者开发者下架IAP项目。类似非消耗类型商品，该类型也支持跨设备同步和本地restore机制。
1.1.4非自动续费的订阅商品
该类型适用于固定有效期的非自动续费项目，如云音乐的会员和一些视频App的会员。没有跨设备同步和本地restore机制，用户可以多次购买。
1.2商品定价
在创建IAP项目的时候，需要设定价格，这个价格只能从苹果预设的价格等级中选择，比如等级1对应1美元、6元人民币，等级2对应2美元、12元人民币，最高等级87对应999.99美元、6498元人民币。另外可能是为了照顾某些货币区的开发者和用户，还有一些特殊的等级，比如备用等级A对应1美元、1元人民币，备用等级B对应1美元、3元人民币这样。除此之外，IAP项目不能定一个9.9元这样不符合任何等级的价格。详细价格等级表可以看苹果的官方文档：(https://itunesconnect.apple.com/WebObjects/iTunesConnect.woa/ra/ng/app/880452926/pricingMatrix/subscription)苹果的价格等级表通常是不会调整的，但也不排除在某些货币汇率发生巨大变化的情况下，对该货币的定价进行调整，调整前苹果会发邮件通知开发者。
1.3分成
很多人都知道，App Store上的付费App和App内购，苹果与开发者默认是3/7分成。但实际上，在某些地区苹果与开发者分成之前需要先扣除交易税，开发者的实际分成不一定是70%。从2015年10月开始，苹果对中国地区的App Store购买扣除了2%的交易税，对于中国区帐号购买的IAP，开发者的实际分成在68%~69%之间。而且中国以外不同地区的交易税标准也存在差异，如1.3中所述，如果需要严格计算实际收入，可能需要把这个部分也考虑进来。
针对不同地区的内购，内购价格和对应的开发者实际收入在苹果的价格等级表中有详细列举。(https://developer.apple.com/app-store/subscriptions/)
1.4结算
针对IAP的交易收入，苹果一般以5周(每年1/4/7/10月)或4周(其余月份)作为一个结算周期，并在每个结算周期结束后第33天向开发者付账。
2.IAP支付流程
这部分内容在《In-App Purchase Programming Guide》中有详细说明：https://developer.apple.com/library/content/documentation/NetworkingInternet/Conceptual/StoreKitGuide/Introduction.html#//apple_ref/doc/uid/TP40008267
具体来说，IAP的支付模式分为客户端校验和服务端校验2种模式，客户端校验模式因为容易伪造支付凭据，安全性比较低，一般只有非常简单的单机App才会使用，大部分App都会采用服务端校验模式。
另外不同类型的IAP支付流程也会有一些小差异（主要是restore机制），下面就以最常用的消耗品类型为例，来说明一下IAP的支付流程：
1.用户准备购买某个项目时，App客户端通过product id向苹果API请求支付信息。
2.App客户端再次验证product id对应的支付价格和货币单位无误（可跳过），继续请求支付。
3.手机系统弹窗提示用户确认将要购买的内容和价格，用户点击确认购买，App客户端获得苹果API返回的支付成功通知以及支付凭据，向App服务端请求校验支付凭据。
4.App服务端拿到客户端的支付凭据，再向苹果服务器请求校验支付凭据（避免一些越狱插件伪造客户端支付凭据）。App服务端校验支付凭据成功，通知App客户端。App收到支付凭据校验成功通知，代表用户付费成功，再处理后续业务逻辑
以上就是一个标准的IAP支付流程，看上去顺理成章，但实际上有很多坑，下面重点来讲一下需要注意的问题。
3.不能忽视的坑
3.1 延迟返回支付结果
在上述IAP支付流程中，由于网络问题等种种原因，即使用户已经付款成
功客户端也可能一时半会收不到苹果API的支付成功通知，也无法主动向苹果API请求查询支付状态，只能被动等待通知。因此有些情况下，客户端会延迟收到支成功的通知（可能是过了几分钟，也有可能是下次打开App的时候）。
针对这种情况，需要在每次苹果通知到客户端有未完成订单的同时，客户端需要及时把相关凭证等信息给到服务器。
3.2 服务端校验延迟
在上述支付凭据校验过程中，因为网络问题等各种原因，客户端可能无法及时收到服务端的校验成功的通知。
类似的，这种情况需要客户端本地持续向服务器轮询校验结果，直到返回明确的校验成功或校验无效的结果。
3.3 非官方渠道包支付失败问题
在上述流程步骤中，如果用户安装的App不是App Store官方渠道包（从
PP助手、同步推等第三方应用商店下载），苹果API会直接返回product id不
存在并结束支付流程。
类似的，越狱设备在安装某些内购破解插件后，也会导致无法进行内购（返回product id不存在）。因此，针对这个问题的解决办法是：当返回product id不存在时，提示用户安装的可能是非官方渠道包，引导用户到App Store下载官方渠道包。
4.IAP使用中需要注意的问题
4.1绑定苹果内购的交易信息和应用的用户信息
利用内购中的applicationUsername，可以实现每一个订单和APP对应用户的绑定。值得一提的是，applicationUsername上面可以放置一个任意字符串，开发者可以根据自己的需求，做出调整。
4.2 记录支付成功以后的交易信息
苹果内购付款成功以后，苹果会返回订单号之类的交易信息。建议APP拿到这些信息以后，将其发送到APP的服务器，方便以后使用。（注意，目前在苹果的线上环境没有做出测试，还不能确认内购返回的交易订单号和用户收到交易订单号是否一致。）
4.3尽量不要删除已创建的内购商品
已创建的IAP除了product id之外的所有信息都可以修改，如果删除了一个IAP，将无法再创建一个相同product id的IAP，也意味着该product id永久失效。而product id一般有特定的命名规则，用来标示App内的购买项目，如果命名规则下有某个product id永久失效，可能会导致整个product id命名规则都要修改，掉进坑里~
4.4注意区分reference name和display name
reference name是给开发者自己看的，display name会在IAP支付流程的确认购买系统弹窗中展示给用户，而且不能随意修改（修改需要重新提交IAP审核），所以命名的时候要弄清楚。
4.5当App审核被拒时
如果IAP随App版本一起提交审核，有问题时所有新提交的IAP商品和App版本会同时被拒，再次提交App审核时，一定要记得重新提交所有IAP商品（每个IAP还得要手动编辑一下才能重新提交真麻烦），否则苹果是无法继续审核的。
4.6无法避免的丢单
当游戏客户端没有拿到支付凭证或者游戏服务器没有拿到支付凭证的情况下，用户再也不打开这个应用甚至删除掉，目前看来，没有办法解决这种情况的丢单。
4.7退款问题
根据苹果政策，用户在购买IAP后90天内，能以各种原因申请退款（扣款后购买失败、买错了、不喜欢等等），但实际能不能退成功苹果说了算。
如果一个用户申请退款成功，苹果会在与开发者结算时记一笔退款订单（当然原来购买成功的订单也在），钱就不给了，而且苹果也不会告诉你是哪个用户退款的，而且用户购买的东西还在。
订单数据可以在itunes connect后台的“付款和财务报告”中查看，但没有详细时间信息和用户信息，很难定位到相应的平台订单。
从历史数据来看，一般不遇到大量恶意退款的情况下，IAP的退款率可能在1~3%之间（取决于App内容质量、用户心情，还有苹果的心情）。对于IAP营收额很大的App，可能需要考虑一下退款的问题。
5.参考资料
http://www.cnblogs.com/meteoric_cry/p/4598304.html
http://rhd361.com/special/news?id=bafeabd95c854196b753be356cf501e3
http://blog.csdn.net/u013152587/article/details/50488353
//www.greatytc.com/p/8c958e75f98f
