3.1 匿名购买

3.2 跨平台同步

3.3 虚拟货币

3.4 退款问题

3.5 支付成功率

3.6 作弊

1 IAP规则详解

本文所说的IAP（In-App）特指 App的内购。 它是提供的用于在App内购买虚拟商品或服务的交易系统。

首先，我们来讨论一下IAP的基本规则及其一些要点：

1.1 适用范围

App内需要付费的产品功能或虚拟商品/服务，例如游戏道具、电子书、音乐、视频、订阅会员、App的高级功能等。

IAP不适用于应用内购买实体商品（如淘宝买衣服），也不适用于虚拟商品（如充话费）或不在应用内使用的服务（如滴滴打车）。该应用程序。

那么问题来了，如果你在App中购买音乐专辑，不仅可以在App中收听数字专辑，还可以获得实体产品CD，是否适合IAP？

答案是适用的。 由于App中的数字专辑和实体产品CD可以分开使用，因此数字专辑属于IAP范围，您必须使用IAP购买。 否则，各种游戏中售价648的道具都声称该产品不仅包含游戏道具，而且购买后还获得50美分的实体纪念品（例如），因此他们直接绕过IAP。 苹果这不是在耍花招吗？

苹果规定适用范围内的虚拟商品或服务必须使用IAP购买和支付。 不允许支付宝、微信支付等其他支付方式（包括Pay），也不允许以任何方式（包括跳出App、提示文案等）引导用户通过App外部的渠道进行购买。

原则上，苹果不允许使用外部兑换码来解锁应用内的虚拟商品或服务。 但事实上，对于兑换码的限制有些模糊，因为有些应用可以在应用内获取兑换码（如活动优惠券或签到奖励），很难严格界定是外部兑换码还是内部兑换码。内容兑换代码。 因此，在IAP购买中使用优惠券进行抵扣一般是允许的，但如果明显引导用户在App外购买兑换码，然后在App内兑换虚拟商品或服务，就会被苹果禁止。

另外，App 3.1.4中有这样一个特殊的规则：

“与可能的 IAP 上的某个（例如玩具）配合使用的应用程序，IAP 也是如此。”

这意味着用户在App内购买了一项功能，并且该功能需要与实体产品结合使用。 在这种情况下，允许使用IAP以外的方式解锁该功能，但前提是仍然需要IAP购买的选项。 。

例如，用户在健康管理应用中购买了高级计步功能，但该计步功能需要与手环配合使用，并且必须与手环一起打包购买。 这种情况下，App可以在IAP购买选项的基础上提供其他购买方式。

但现实中似乎并没有这样的案例。 因为App完全可以把计步器变成免费功能，但脱离了手环实际上就无法工作，然后把手环当作一个可以在App之外使用的实体产品，所以与IAP无关。 谁找麻烦，把这个东西做成IAP，想给苹果分一杯羹~

还有一些跨平台同步的复杂情况，将在本文第三部分进一步介绍。

1.2 IAP类型

前面说过，IAP是一个商品交易系统，而不是一个简单的支付系统。 每个购买商品都需要在App后台创建一个商品并提交给苹果审核。 购买商品需审核通过后方可生效。

创建IAP产品时，主要有4种类型可供选择：

1.2.1

该类型适合可多次购买的消耗品，如游戏道具、虚拟币等。

1.2.2 非

此类型适合一次性购买永久有效的物品，例如电子书、游戏关卡等。

此类项目支持跨设备同步和本地化。 例如，用户在某个App中购买一本书，则可以在同一个ID的设备上的所有App中免费获取该书，而无需依赖该App自身的账户系统。 即使该书从App中删除，也可以免费检索。

1.2.3 自动

该类型适用于自动续订的订阅项目，例如包月订阅。 用户购买后，订阅将每月自动续订，直至用户手动取消或开发者删除IAP项目。

与Non-一样，该类型也支持跨设备同步和本地机制。

此前，该类型仅支持类别（报纸和杂志）的应用程序。 从2016年6月开始，它支持所有类型的应用程序。 不过，除了品类之外，国内应用很少采用这种内购方式。

1.2.4 非

该类型适用于固定有效期的非自动续费项目，例如云音乐会员、部分视频应用的会员。 没有跨设备同步和本地机制，用户可以多次购买。

1.2.5 免费

该类型是Auto-的特例，适合免费订阅项目，仅支持类别App，还支持跨设备同步和本地机制。

“In-App”详细介绍了各类类型的范围和特点：

其中，特别要注意的是：

1 对于非IAP类型的项目，苹果会要求App提供“恢复购买”功能，支持跨设备同步和本地。 同时，如果App本身有用户账户体系，那么用户只需支付一次，就可以利用该机制将IAP项目无限制地复制到多个用户账户中。 这是一个骗局~

因此，对于电子书等一次性购买永久有效的商品，如果您想使用App本身的用户账号体系，避免跨设备同步和本地机制，可以考虑选择Non类型。 同时考虑到Non-一般都有固定的有效期，可以添加无限的有效期（比如9999天）来应对苹果的审核。

2和Non-都是可以重复购买的IAP物品。 前者更多的是消费品，后者更多的是订阅。 另一个区别是，对于非IAP商品，如果用户之前购买过一次，过期后再次购买或者切换App账号购买，则在支付过程中会出现系统弹窗提醒用户之前已经购买过该商品。 ，是否再次购买，如果用户不慎点击取消，支付流程将被终止。

苹果设计这个弹窗的初衷是为了根据用户的ID来识别用户，防止用户重复购买同一个商品。 但对于有用户账户系统的应用来说，这个提示就有点多余了，虽然影响不大。 因此，如果 IAP 项目同时适合非选项和比较选项，则建议使用。

1.3 定价

创建IAP项目时，您需要设置价格。 该价格只能从预设的价格水平中选择。 例如，1级对应1美元和6元人民币，2级对应2美元和12元人民币……最高级别。 87对应999.99美元和6,498元人民币。 另外，可能还会有一些特殊的级别来照顾某些币区的开发者和用户。 例如，储备水平A对应1美元和1人民币，储备水平B对应1美元和3人民币。 另外，IAP项目不能设定不符合任何级别的9.9元价格。 详细的价格等级列表请参见官方文档：

苹果的价格等级表通常不会调整，但不排除在某些货币汇率发生剧烈变化的情况下，该货币的定价将会调整。 苹果将​​在调整前发送电子邮件通知开发者。

另外，物价水平表中不同货币之间的汇率关系与实际汇率不同。 淘宝上一些低价的iOS游戏内购、充值服务利用某些币种的汇率差来做生意。

对于开发者来说，如果App在中国境外发布，可能需要注意汇率问题。 部分地区内购以人民币结算后的收入会低于相应价位的人民币收入。 因此，在某些需要严格计算实际收入的情况下（例如金融统计收入，或者应用内购收入），需要与平台CP方进一步协商。 分享），可能需要根据实际支付币种和内购金额以及对应的汇率来计算收益，或者可以通过一些方法来限制某些区域的内购（详见2.2节）本文）。

作为补充，IAP项目的价格可以在产品发布后后台修改，也可以设置限时折扣价格。 但是，大多数联网应用程序的应用内购买价格都是从其自己的服务器获取的。 如果要修改价格或者设置限时优惠，需要双方共同处理，相当麻烦。

1.4 划分

很多人都知道，对于付费应用和应用内购买，苹果和开发者默认是3/7的分成。

但事实上，在某些领域，苹果需要扣除交易税后才与开发者分享，而开发者的实际分成不一定是70%。 自2015年10月起，苹果公司对在中国购买的App征收2%的交易税。 对于使用中国账户购买的IAP，开发者的实际份额在68%至69%之间。 而且，中国以外不同地区的交易税标准也存在差异。 如1.3所述，如果需要严格计算实际收入，这部分可能需要考虑在内。

对于不同地区的应用内购买，应用内购买价格以及对应的实际开发者收入详见苹果的价格等级表（1.3中的链接）。

另外，根据苹果2016年6月的新规则，对于汽车型IAP，如果用户购买订阅超过一年，开发者从第二年开始可以获得85%的分成。 详细信息可参见：

1.5 结算

对于IAP交易收入，苹果一般以5周（每年1月/4月/7月/10月）或4周（其余月份）作为结算周期，并在每个结算周期结束后的第33天向开发者支付费用。

2 IAP设计与开发要点

2.1 创建并提交IAP项目

开发IAP之前，需要在后台创建IAP产品，并按照规格填写ID、产品名称、价格、截图等信息。

如果当前版本的App支持新的IAP项目，您可以直接提交IAP审核，无需发布版本。 如果您需要应用程序支持新功能，则需要将其与应用程序版本一起提交。

“In-App for”详细介绍了IAP的创建和提交流程：

其中，特别要注意的是：

2.1.1 尽量不要删除已创建的IAP

创建的IAP除ID外的所有信息均可修改。 如果删除一个IAP，则不会创建另一个具有相同ID的IAP，这意味着该ID将永久无效。 ID一般都有特定的命名规则，用于标记应用中的购买项目。 如果命名规则下的某个ID永久失效，可能会导致整个ID命名规则被修改，陷入陷阱~

2.1.2 注意区分名字与名字

这个名字是给开发者看的。 该名称会在IAP支付流程的购买确认弹窗中显示给用户，且不能随意修改（修改需要重新提交IAP审核），所以命名时要明确。

2.1.3 App审核被拒绝时

如果IAP与App版本一起提交审核，则所有新提交的IAP项目和App版本如果存在问题将同时被拒绝。 再次提交App送审时，一定要记得重新提交所有IAP项目（每个IAP都要手动编辑重新提交，真的很麻烦），否则苹果将无法继续审核。 别傻傻地等了半个月，发现苹果根本没有任何回应哦~

2.2 IAP支付流程

这部分内容属于功能实现的逻辑，在“In-App”中也有详细解释：

我个人觉得，了解产品规划或者交互中的业务逻辑是非常有必要的，这样我们才能和开发一起设计出用户体验更好的功能解决方案。

具体来说，IAP支付模式分为客户端验证和服务器验证两种模式。 客户端验证方式安全性较低，容易伪造支付凭证。 一般来说，只有非常简单的独立应用程序才会使用它。 大多数应用程序都会使用服务器端验证模式。

另外，不同类型的IAP的支付流程也会有一些细微的差别（主要是机制上）。 我们以最常用和非类型为例，讲解一下IAP的支付流程：

当用户准备购买商品时，App客户端通过ID向 API请求支付信息。 手机系统弹出验证用户ID（可能需要输入ID密码或验证ID）。 身份验证完成后， API将用户返回给App客户端。 支付的价格和货币单位由App客户端再次验证。 ID对应的支付价格和货币单位正确（可以跳过），手机系统继续请求支付。 弹出窗口提示用户确认要购买的内容和价格。 用户点击确认购买App客户端。 客户端获取 API返回的支付成功通知和支付凭证，请求App服务器验证支付凭证，App服务器获取客户端的支付凭证，然后请求服务器验证支付凭证（避免一些越狱插件伪造客户端支付凭证）App服务器成功验证支付凭证并通知App客户端。 App收到支付凭证验证成功的通知，表明用户支付成功，然后处理后续业务逻辑。

以上是一个标准的IAP支付流程。 看似符合逻辑，但实际上却存在很多陷阱。 我们来重点讨论一下需要注意的问题。

2.3 不可忽视的陷阱

2.3.1 支付结果延迟返回

上述流程第6步中，由于网络问题等各种原因，即使用户支付成功，客户端也可能会暂时收不到 API的支付成功通知，无法主动请求查看支付状态来自苹果API。 只能被动等待通知。

因此，在某些情况下，客户端会延迟收到支付成功的通知（可能是几分钟后，或者下次打开应用程序时）。 在这种情况下，需要做两件事：

1 客户端本地保存所有未确认支付结果的交易信息，并建立监听流程。 收到支付成功信息后，继续处理交易的后续流程。在极端情况下，如果用户在未确认交易结果的情况下删除App，则App本地数据库中保存的交易信息也会丢失。 因此，更好的解决方案是将交易信息保存在iOS系统中。

2、当本地有交易信息未确认支付结果时，交互提示用户可能需要等待支付结果，避免重复支付。

2.3.2 服务端验证延迟

在上述步骤6至步骤8的支付凭证验证过程中，由于网络问题等各种原因，客户端可能无法及时收到服务器发送的验证成功通知。 同样，这种情况需要：

1 客户端将支付凭证保存在本地，并不断向服务器轮询验证结果，直到返回明确的验证成功或验证无效的结果。支付凭证最好也保留在其中。

2、当客户端向服务器轮询结果时，为了防止用户在支付结果页面等待太久，可以在交互层面（经过一定的超时时间）结束支付流程，并提示用户等待付款结果，避免重复付款。

2.3.3 非官方渠道套餐支付失败问题

上述流程第1步中，如果用户安装的App不是官方App渠道包（从PP助手、同步推送等第三方应用商店下载的）， API会直接返回该id不存在并结束支付流程。 交互层面的表现 用户点击购买后，直接提示支付失败。 这个问题困扰了我们很长时间，在网上也找不到类似问题的信息。 我们用尽了日志埋藏、用户调研等一系列方法，才最终定位到。

同样，在越狱设备上安装某些内购破解插件后，将无法进行内购（返回的ID不存在）。 不过现在iOS设备的越狱率很低，基本可以忽略不计。

因此，解决这个问题的办法是：当返回的ID不存在时，提示用户安装非官方渠道包，并引导用户到App下载官方渠道包。

2.3.4 货币验证

如本文1.3节所述，如果该App是在中国境外发布的，但由于某些原因您想限制某些地区账户的内购，您可以在步骤4中验证用户支付的币种单位。上述过程并禁止某些货币购买。 同时，在交互方面也应该给用户相应的提示，比如弹窗提示不支持特殊地区账号购买等。

2.3.5 不与App支付方式绑定的用户支付流程

这是一个巨大的坑！

如果用户在进行内购前未绑定过App的支付方式，则在上述流程的第5步中，点击系统弹窗（首次）确认购买后，用户会自动跳转到App绑定的支付方式接口。 然后，如果支付方式绑定成功，会自动跳转回App，并再次（第二次）出现系统弹窗让用户确认购买。

然而，当用户点击系统弹窗（第一次）确认购买时， API会立即返回客户端支付失败...支付失败...失败...一般情况下，客户端收到支付失败时，应认为支付已取消，本地交易信息将被丢弃。 但万万没想到，用户在绑定支付方式后，仍然继续确认购买。 这简直就是苹果IAP系统设计上的一个大bug！

如果您知道这个陷阱，解决方案就非常简单。 当 API返回支付失败时，使用类似2.3.1的方法处理，保留待确认的交易信息，并继续监听支付结果的返回。