产品提交苹果审核爬坑总结之：苹果IAP内购规则
iOS应用内付费(IAP)开发步骤列表
前两天和服务端同事一起，完成了应用内付费（以下简称IAP, In app purchase）的开发工作。步骤繁多，在此把开发步骤列表整理如下。因为只是步骤列表，所以并不含详细的说明教程，需要看教程的新手，可以看我附在最后的一些参考链接。
配置Developer.apple.com
登录到Developer.apple.com，然后进行以下步骤：
- 为应用建立建立一个不带通配符的App ID
- 用该App ID生成和安装相应的Provisioning Profile文件。
配置iTunes Connect
登录到iTunes Connet，然后进行以下步骤：
- 用该App ID创建一个新的应用。
- 在该应用中，创建应用内付费项目，选择付费类型，通常可选的是可重复消费(Consumable)的或是永久有效(Non-Consumable)的2种，然后设置好价格和Product ID以及购买介绍和截图即可，这里的Product ID是需要记住的，后面开发的时候需要。如下图所示：
-
添加一个用于在sandbox付费的测试用户，如下图所示。注意苹果对该测试用户的密码要求
和正式账号一样，必须是至少8位，并且同时包含数字和大小写字母：
-
填写相关的税务，银行，联系人信息。如下图所示：
###开发工作(ios端)
1、 在工程中引入 storekit.framework 和 #import
2、 获得所有的付费Product ID列表。这个可以用常量存储在本地，也可以由自己的服务器返回。
3、 制作一个界面，展示所有的应用内付费项目。这些应用内付费项目的价格和介绍信息可以是自己的服务器返回。但如果是不带服务器的单机游戏应用或工具类应用，则可以通过向App Store查询获得。我在测试时发现，向App Store查询速度非常慢，通常需要2-3秒钟，所以不建议这么做，最好还是搞个自己的服务器吧。
4、当用户点击了一个IAP项目，我们先查询用户是否允许应用内付费，如果不允许则不用进行以下步骤了。代码如下：
|
if ([
SKPaymentQueue canMakePayments]) {
// 执行下面提到的第5步：
[
self getProductInfo];
}
else {
NSLog(
@"失败，用户禁止应用内付费购买.");
}
|
5、 我们先通过该IAP的ProductID向AppStore查询，获得SKPayment实例，然后通过SKPaymentQueue的 addPayment方法发起一个购买的操作。
|
// 下面的ProductId应该是事先在itunesConnect中添加好的，已存在的付费项目。否则查询会失败。
- (
void)getProductInfo {
NSSet * set = [
NSSet setWithArray:@[
@"ProductId"]];
SKProductsRequest * request = [[
SKProductsRequest alloc] initWithProductIdentifiers:set];
request.delegate =
self;
[request start];
}
// 以上查询的回调函数
- (
void)productsRequest:(
SKProductsRequest *)request didReceiveResponse:(
SKProductsResponse *)response {
NSArray *myProduct = response.products;
if (myProduct.count ==
0) {
NSLog(
@"无法获取产品信息，购买失败。");
return;
}
SKPayment * payment = [
SKPayment paymentWithProduct:myProduct[
0]];
[[
SKPaymentQueue defaultQueue] addPayment:payment];
}
|
6、 在viewDidLoad方法中，将购买页面设置成购买的Observer。
|
- (
void)viewDidLoad {
[
super viewDidLoad];
// 监听购买结果
[[
SKPaymentQueue defaultQueue] addTransactionObserver:
self];
}
- (
void)viewDidUnload {
[
super viewDidUnload];
[[
SKPaymentQueue defaultQueue] removeTransactionObserver:
self];
}
|
7、 当用户购买的操作有结果时，就会触发下面的回调函数，相应进行处理即可。
|
- (
void)paymentQueue:(
SKPaymentQueue *)queue updatedTransactions:(
NSArray *)transactions {
for (
SKPaymentTransaction *transaction
in transactions)
{
switch (transaction.transactionState)
{
case
SKPaymentTransactionStatePurchased:
//交易完成
NSLog(
@"transactionIdentifier = %@", transaction.transactionIdentifier);
[
self completeTransaction:transaction];
break;
case
SKPaymentTransactionStateFailed:
//交易失败
[
self failedTransaction:transaction];
break;
case
SKPaymentTransactionStateRestored:
//已经购买过该商品
[
self restoreTransaction:transaction];
break;
case
SKPaymentTransactionStatePurchasing:
//商品添加进列表
NSLog(
@"商品添加进列表");
break;
default:
break;
}
}
}
- (
void)completeTransaction:(
SKPaymentTransaction *)transaction {
// Your application should implement these two methods.
NSString * productIdentifier = transaction.payment.productIdentifier;
NSString * receipt = [transaction.transactionReceipt base64EncodedString];
if ([productIdentifier length] >
0) {
// 向自己的服务器验证购买凭证
}
// Remove the transaction from the payment queue.
[[
SKPaymentQueue defaultQueue] finishTransaction: transaction];
}
- (
void)failedTransaction:(
SKPaymentTransaction *)transaction {
if(transaction.error.code !=
SKErrorPaymentCancelled) {
NSLog(
@"购买失败");
}
else {
NSLog(
@"用户取消交易");
}
[[
SKPaymentQueue defaultQueue] finishTransaction: transaction];
}
- (
void)restoreTransaction:(
SKPaymentTransaction *)transaction {
// 对于已购商品，处理恢复购买的逻辑
[[
SKPaymentQueue defaultQueue] finishTransaction: transaction];
}
|
8、服务器验证凭证(Optional)。如果购买成功，我们需要将凭证发送到服务器上进行验证。考虑到网络异常情况，iOS端的发送凭证操作应该进行持久化，如果程序退出，崩溃或网络异常，可以恢复重试。
###开发工作(服务端)
服务端的工作比较简单，分4步：
- 接收ios端发过来的购买凭证。
- 判断凭证是否已经存在或验证过，然后存储该凭证。
- 将该凭证发送到苹果的服务器验证，并将验证结果返回给客户端。
- 如果需要，修改用户相应的会员权限。
考虑到网络异常情况，服务器的验证应该是一个可恢复的队列，如果网络失败了，应该进行重试。
与苹果的验证接口文档在这里。简单来说就是将该购买凭证用Base64编码，然后POST给苹果的验证服务器，苹果将验证结果以JSON形式返回。
苹果AppStore线上的购买凭证验证地址是https://buy.itunes.apple.com/verifyReceipt ，测试的验证地址是：https://sandbox.itunes.apple.com/verifyReceipt
参考链接
以下参考链接详细说明了完成应用内付费开发的步骤：
- https://developer.apple.com/appstore/in-app-purchase/index.html
- http://www.himigame.com/iphone-cocos2d/550.html
- http://www.cocoachina.com/iphonedev/sdk/2011/1028/3435.html
- http://www.cocoachina.com/newbie/basic/2012/0214/3976.html
App Store 审核指南
在 App Store 中，您可以通过多种方式让自己的 App 实现盈利。如果您的业务模式并不显而易见，请务必在其元数据和 App Review 备注中加以说明。如果我们无法理解 App 的工作方式，或者 App 内购买不是那么一目了然，则审核会有所延误，并可能会导致 App 被拒绝。尽管价格由您决定，但是我们不会分发要价明显过高的 App 和 App 内购买项目。对于试图以不合常理的高昂价格欺骗用户的 App，我们将予以拒绝。
3.1.1 App 内购买：
▪ 如果您想要在 app 内解锁特性或功能（解锁方式有：订阅、游戏内货币、游戏关卡、优质内容的访问权限或解锁完整版等），则必须使用 App 内购买。App 不得包含指引客户使用非 IAP 机制进行购买的按钮、外部链接或其他行动号召用语。
▪ 通过 IAP 购买的所有点数和游戏货币必须在 app 内使用且不得过期，并且您应确保为所有可恢复的揂pp 内购买设计一套恢复机制。
▪ 请务必指定正确的可购买类型，否则您的 app 将被拒绝。
▪ App 不得直接或间接地将 IAP 内容、功能或消耗品赠予他人。
▪ 通过 Mac App Store 分发的 app 可托管基于非 App Store 机制的插件或扩展功能。
3.1.2 订阅：无论属于 App Store 上哪一类别，App 都可以提供自动续订的 App 内购买订阅。在 app 内集成可自动续订的订阅时，请务必遵循下述指导原则。
3.1.2(a) 允许的用途：如果您提供自动续订订阅，则必须为客户提供持续的价值。以下并非详尽列表，适当的订阅示例包括：新游戏关卡；连载内容；多玩家支持；持续提供实质性更新的 app；对媒体内容的大型合集或持续更新的访问权限；软件即服务 (SAAS)；以及云服务支持。此外：
▪ 订阅可与单点式服务一起提供。例如，您可以提供整个影片库的订阅，以及单部影片购买或租赁。
▪ 您可以提供在您自己的不同 app 间共享的单一订阅，但此类订阅不得扩展到第三方 app 或服务。订阅必须适用于可使用该 app 的所有用户设备。进一步了解在您的 app 之间共享订阅。
▪ App 不得强制要求用户为 app 评级或点评、下载其他 app，或执行其他类似操作，然后才能访问该 app 的功能、内容或者使用该 app。
▪ 与所有 app 一样，此类服务订阅应当允许用户直接获得付费购买的项目而无需执行额外任务，如在社交媒体上发帖、上传通讯录，以及在 app 内签到特定次数等。
▪ 订阅不得包含消耗性的积分和游戏内货币等，即使与其他服务相结合也不行，但您可以提供包含消耗性商品打折权益的订阅，例如能以优惠价购买宝石包的高级会员资格。
▪ 如果要将现有 app 更改为基于订阅的业务模式，您不得减掉现有用户已付费购买的主要功能。例如，针对新客户引入订阅模式后，已购买完整游戏解锁的客户应能够继续访问完整版游戏。
3.1.2(b) 升级和降级：用户应能获得无缝的升级/降级体验，并且不会出现无意间订阅同一内容的多个不同版本。请查阅关于管理订阅升级和降级选项的最佳做法。
3.1.2(c) 订阅信息：在让客户订阅之前，您应当清晰描述付费后的具体权益。每月有几期？云存储容量有多大？具体能访问您的哪些服务？另外，务必要清晰地表述相关的要求，即您协议的 Schedule 2 中Agreements, Tax, and Banking部分所述的要求。
3.1.3 基于内容的阅读器擜pp：App 应允许用户访问先前购买的内容或内容订阅（具体而言是：杂志、报纸、图书、音频、音乐、视频、专业数据库访问权限、VoIP、云存储以及经批准的服务，如用于管理学生成绩和课表的教育类 App），前提是 app 不得引导用户使用非 IAP 机制进行购买。
3.1.4 内容代码：App 不得使用自身机制来解锁内容或功能，如许可证密钥、增强现实标记、二维码等。在为数不多的情形中，例如当功能依赖于特定的硬件功能时，App 可在不使用 App 内购买的情况下解锁该功能（例如，天文 App 会在与望远镜同步后增加功能）。与经过批准的实际产品（如玩具）配合使用的可选 App 功能可在不使用 IAP 的情况下解锁特定功能，前提是同时也提供 IAP 选项。您不得要求用户通过购买无关产品或参与广告或市场活动来解锁 App 功能。
3.1.5 App 之外的实物商品和服务：如果 app 允许用户购买将在 app 之外使用的商品或服务，则必须使用 IAP 以外的购买方式来收取相应款项，如 Apple Pay 或传统的信用卡入口。App 可支持获批虚拟货币的流通（如比特币、狗币），前提条件是，在该 app 能够正常使用的地区，前述做法必须遵守各州法律和联邦法律。
3.1.6 Apple Pay：如果 app 使用 Apple Pay，则在销售任何商品或服务之前，必须先向用户提供所有的基本购买信息，并且必须正确使用 Apple Pay 品牌和用户界面元素，具体要求可参考Apple Pay 识别标志指南和Human Interface Guidelines。使用 Apple Pay 提供重复付款服务的 App 至少需要披露以下信息：
▪ 续订周期的时长；除非被取消，否则续订将会继续
▪ 每个周期中会提供哪些服务
▪ 将向客户收取的实际费用
▪ 如何取消
得出如下结论：
1.虚拟货品，应用内部使用的商品必须用IAP
2.实物交易 必须用三方 非IAP
3.如果只是虚拟交易，集成微信支付等三方支付是没有必要的，因为微信的表情购买，也是需要调到iTunes的
所以建议，只集成IAP
二、IAP
在应用程序内购买虚拟商品。如果你在App Store上销售的应用程序，将收到支付金额的70％。
需要做的是：
配置ItunesConnect
1、填写相关的税务，银行，联系人信息
iOS App提交指南：协议、税务、和银行业务 http://www.jianshu.com/p/c7cf65911bc1
这个里面的描述已经很清晰了
2.添加一个用于在sandbox付费的测试用户
3.修改应用内付费项目，选择付费类型
APP内购买项目摘要填写
我们在应用内需要拿到app内购买摘要里面的产品ID
参考http://www.cnblogs.com/XimuYouzi/archive/2016/04/17/5401749.html
三、iTunes Connect 关于税费的填写
Tax Infomation
Review the tax forms below and complete the ones applicable to your situation. Note that U.S. tax forms are required for everyone.
税务信息总共分三种：
1.U.S Tax Forms:美国税务
2.Australia Tax Forms
3.Canada Tax Forms
看公司需求填写
然后会问你两个问题
1.Are you a U.S citizen,U.S resident, U.S partnership. or U.S corporation? 询问你是否是美国居民，有没有美国伙伴关系或者美国公司，如果没有直接选择No。
2.Do you hava any U.S Business Activities? 询问你有没有在美国的商业性活动，没有也直接选No。
然后就开始填写税务信息
Manage your Tax Infomation
Tax Infomation
第一条 Certificate of Foreign Status of Benificial Owner
1.个人或组织名称
2.所在国家
3.受益方式、独立开发者选择个人
4.居住地址
5.邮寄地址
6.下面一条是声明 ：
我宣布iPhone开发者计划的个人或组织命名任何支付的许可协议是有益的所有者在这样的协议。我宣布,有益的所有者没有任何员工在美国和不拥有,租赁或控制任何设备或其他资产在美国,用于从苹果开发者计划获得收入。我宣布我是有益的所有者或授权,我做出这个声明代表有益的所有者。
大致就是受益方没有美国的关系
7.Name of Person Making this Declaration :声明人
8.Title:头衔
剩下的是填写W-8BEN表格
Form W-8BEN: Certificate of Foreign Status of Beneficial Owner
for United States Tax Withholding and Reporting (Individuals)
W-8BEN税表：在美预扣税受益人的外籍身份证明
Part I: Identification of Beneficial Owner
受益方身份
1.作为受益方的个人或机构名称
2.国籍
3.永久居住地址（不要填写邮箱或者转交地址）
4.邮寄地址
5.美国的缴税身份编号（选择填写）（SSN or ITIN or EIN ） SSN: SSN是 Social Security Number 的缩写，译为「社会安全号码」，为美国社会安全卡（Social Security Card）上的 9 位数字。SSN 原本目的是用于追踪个人的纳税情况，但是现在用途已被扩大到包括区分个人身份，类似中国「居民身份证号码」之作用。社会安全号码一般写作类似 450-12-3672 这样「3位 - 2位 - 4位」的形式。
ITIN:ITIN号申请美国个人报税号码
EIN:国雇主识别号码（Employer Identification Number）也称作联邦税号。按照美国的法律，一般而言，绝大多数生意或者实体都需要EIN作为美国国税局的识别号码，这样能够处理和税务相关的事宜。美国的EIN号码适用于在美国境内注册的公司或者实体，在美国境外注册的公司或者实体以及个人。
6.外国的缴税身份证编号（选择填写）
7.参考编号
8.出生日期
PartII:税收协定优惠待遇（如果适用）
9.我在此作出如下声明：受益方居住在China属于美国和该国家之间的达成的税收协定的作用范围以内。
10.特别的比例和条件（如果使用-参见说明）：受益方根据以上9a中所述的税收协定中的第 XX条 要求退回其对XX（指的是收入种类）所征收的XX%预扣税。
解释受益方附和税收协定中的优惠条款的具体原因
PartIII:证明
我在此声明我已经详细检查了本表的信息，而且在我所知的范围内证明这些信息是是真实、正确和完整的，并且愿意承担作伪证的惩罚：
1.我是和本表格涉及的全部收入相关的受益方(或被授权代表受益方进行签署).这种形式涉及或正在使用这种形式来记录自己作为一个个体,一个所有者或帐户持有人的外资金融机构
2.在这个表格的第一行的这个人 不是美国人
3.这个表格涉及的收入：
a.不是来自在美国的业务或贸易行为
b.虽然有联系但根据所得税协定不应缴税，以及
c.合伙人收益在合作关系下的有效地相关收入
4.表格第一条的人是表格第九条所列条约国家的居民（如果有任何）符合该国家和美国之间的税法条约，和
5.对于中间交易或事物交易，受益方根据说明中的定义是免税的外国人。
此外，我授权可以将本表提供给任何对涉及收入有控制、接收和监管功能的税务机构或向我这个受益方进行减退税实际支付的机构。
我同意在30天内提交一个新表格，如果任何这个表格中任何认证有不正确的地方。
如果是个人开发者，并且与美国没有以上所说的税务金钱关系，只用填写 Certificate of Foreign Status of Beneficial Owner 和 Part III: Certification部分 中间位置可不标记
但是如果是有关系 ，请与财务方面沟通按照公司的相关流程填写
做产品的童鞋都知道，应用想要通过appstore审核，并且顺利上线到市场，是需要规避很多苹果不允许的事情。比如图片应用在提交的时候，不允许出现色情、政治等相关的不符合规定的图片，所以需要在提交的时候删除这些图片或者隐藏；再比如，UGC类的产品在提交的时候，必须有一个“举报”的功能，如果没有肯定会被拒。例子有很多，不过今天想说一下最近遇到关于支付的一个例子。
IAP内购规则
我们的产品是一款社交类的app，应用内有经济系统的运转。其中包含了可以使用人民币购买钻石（虚拟货币），然后钻石可以购买礼物（虚拟道具）。这一类的经济都属于虚拟物品，也属于消耗型物品。按照苹果的规定，必须使用IAP支付，否则将会被拒。原因一个是因为苹果需要收30%的分成，另一个原因可能是苹果防止洗钱之类的事情。
其实如果不是硬性规定虚拟物品需要IAP的话，可能大家都会选择使用微信、支付宝等第三方支付，因为IAP是苹果的服务，在国内操作起来第一是慢，并且稍微有点复杂，可能很多用户并不会使用苹果支付，所以在支付率上来讲，会有所折损。第二是在提交应用描述的时候，虚拟物品必须贴合苹果规定的价目。第三是必须支付30%的分成给苹果。所以有些应用会做一些投机取巧的事情，他们会单独开发一个h5的支付页面，当用户点击支付的时候，跳转到网页支付。看似巧妙地避开了IAP支付的鸡肋，但是一旦审查出来，产品就会被下架。所以建议大家不要做这些欲盖弥彰的事情，无规矩不成方圆，每家都有自己的规则需要遵守。
还有一种类型是不需要使用IAP的，就是应用内直接使用现金支付的功能。比如QQ的会员开通、众筹应用的支持众筹等等，这些都不需要走IAP支付，可以大胆的使用微信和支付宝的接口来搞定这件事，且不需要和苹果分成。
物品概念
虚拟物品分为以下几种：
解释一下这些概念：
- 消耗型项目（Consumable products）：消耗，顾名思义，就是会不断减少。比如你买了映客的钻石，钻石在购买礼物赠送给主播的时候，就是一个消耗的过程，那么钻石就属于消耗品。
- 非可消耗型项目（Non-consumable products）：其实就是一次性购买，就拥有了使用权，可以一直使用。比如你在微信或者陌陌购买了某个表情包，这个就属于不可消耗品。
- 自动续订订阅（Auto-renewable subscriptions）：和不可消耗品的不同点是有失效时间。比如说你在qq购买了一个月的qq音乐会员，或者是在乐视tv购买了1个月的会员。在这种模式下，会员用户可以享受到其他非会员用户享受不到的服务。会员快要过期时，系统将自动续费（如果用户同意）
- 免费订阅品（Free subscriptions）：如图中表述。
- 非续订订阅（Non-renewable subscriptions）：一般使用场景是从用户从IAP购买后，购买信息存放在自己的开发者服务器上。可用日期是由开发者服务器自行控制的。
其中非消耗型项目、自动续订订阅、免费订阅品可以多个device共同使用一个Apple ID。消耗型项目和非续订订阅服务，则是现买现用。
使用了IAP，如何避免被拒
如果你的产品中，包含了虚拟（消耗型）物品购买，但是同时也包含了提现功能，这个时候可能会被拒，附上我们其中一次被拒的图：苹果的审核会认为我们既然有了内购，却还有提现，是不符合消耗型物品规则的，可以做一些调整再提交。
-
直接改变规则，去掉内购，或者去掉提现。这种方式是苹果会给的建议，但是会直接影响到产品设计的规则。
-
使用微信发红包形式，替代提现概念，举例说明，比如映客， 当用户使用映客提现的时候，映客会提示需要去微信关注映客的公众号，才可以提现。
-
使用积分兑换，替代收入概念，比如网易的美聊还有对面（都是社交app） 用户可以使用自己的收入，兑换现金或者重新兑换金币，会员积分属于正常现象，只要可以在产品上强说明，我们的积分与虚拟礼物无关即可。另外一个对面app，使用的是积分兑换实物，也就是说，你在应用内获得的收入，不能提取现金，只能换取物品，比如很多人会在滴滴积分商城换取一些小物件。
-
最直接的方式就是把收入页面做成可控的，当应用提交的时候，把收入涉及的页面都隐藏，审核通过之后再放开。不过这种方式属于不正当方式，可能在上线之后会被举报，举报之后你的应用将面临下架的风险。
所以方法其实因产品而异，如果遇到，可以从规则入手修改，或者从一些取巧的方式上入手，目的都是为了使自己的产品顺利上线，希望这则分享可以帮的到你！