国内自主研发的隐私计算TEE技术通过金融科技产品认证，蚂蚁集团主导研发的
06-18
为什么选择IAP？相对来说，应用内支付的用户体验与微信支付、支付宝还有一定差距，但为什么要发展应用内支付呢？这与苹果的AppStore审核政策有关。
在官方（App Store Review Guidance）中，有以下观点： 1.2 应用程序利用除应用内购买API（IAP）之外的系统来购买应用程序中的内容、功能或服务将被拒绝。
在应用程序内使用非 IAP 系统购买内容、功能或服务将被拒绝。
11.3 使用IAP购买实体商品或在应用程序之外使用的商品和服务的应用程序将被拒绝。
IAP购买实物商品或App外的商品或服务将被拒绝； 11.4 使用 IAP 购买积分或其他货币的应用程序必须在应用程序内消耗这些积分。
通过 IAP 购买的积分或其他货币只能在应用程序内使用。
这就提出了这个问题。
如果您要购买的服务既在IOS内部使用，又在Android等IOS系统之外使用，应该按照规则11.2还是规则11.3执行？例如，在视频网站上，视频可以在IOS和Android上观看。
需要通过IAP购买吗？苹果在这里采取了一种模糊的方法。
对于爱奇艺和腾讯视频，IOS上的会员购买只能通过IAP支付。
这与苹果的审核有关。
IAP支付流程 IAP支付的一般开发流程首先需要做一些准备工作，包括：在developer.apple.com上配置一个App ID，并使用该ID生成并安装相应的Provisioning Profile文件。
登录 iTunes Connect 并使用 App ID 创建新应用程序。
在应用中创建应用内支付项目，设置价格和产品ID，以及购买介绍和截图。
在沙盒中添加一个用于支付的测试用户，并填写相关税务、银行、联系信息。
完成这些准备工作后，就可以进入正式开发了。
这里不讲开发代码。
流程如下：用户选择要购买的内容，点击购买按钮；用户通过App Store账户验证Apple服务器。
用户请求Apple服务器验证用户的账户是否被扣款，Apple向用户返回购买成功信息。
该软件接收并显示用户的购买信息。
老手都可以看出，这里有很多陷阱。
用户访问AppStore时使用的是Apple账户，而不是应用系统账户。
换句话说，我们不知道谁在购买这些内容。
例如，应用程序中有两个帐户A和B。
使用A账户登录后，我在IAP上买了东西。
然后我用B账号登录，也在IAP上买了东西。
这两次购买使用了同一个 Apple 帐户。
苹果不会告诉你哪个账户付了钱。
账户陷阱对于单次购买来说不是问题，但是对于订阅来说，就需要小心处理了。
从上面的流程可以看出，苹果服务器与客户端打交道，似乎没有涉及到应用服务器。
客户端收到Apple的返回信息后，才能将此信息转发给应用服务器。
如果用户从未在手机上打开应用程序，应用程序服务器将永远不会收到通知。
幸运的是，苹果后来提供了验证功能。
应用服务器可以将收到的返回信息（加密字符串）发送给Apple服务器进行验证和解密。
IAP 订阅 IAP 订阅是另一个大陷阱。
官方文档在这里。
内容不多，但还有很多没有解释清楚。
续订周期IAP的计算主要是针对音乐、电子书等内容的定期订阅提供的。
一般情况下，期限是按月计算的。
苹果以自然月计算权益周期。
例如，如果您在1月3日购买了权利，则该权利将于2月3日到期，您需要在此之前完成续订。
那么问题来了，1月31日购买的权益什么时候到期呢？按自然月计算，该福利将在3月1日之前到期。
如果在2月和3月续订，4月则享受到4月30日。
自动续订应用开发应该不需要担心续订的细节。
苹果会自动处理。
权利到期前10天，苹果会检查用户账户是否可以扣款以及产品价格是否发生变化。
苹果将??在权利到期前 24 小时开始扣款。
如果失败，则会重试多次，直至成功。
问题是，这种重试会在用户的权限过期后持续很短的一段时间。
苹果没有说明这段时间是否应该被视为拥有权利，但开发者需要注意如何处理。
免费试用 免费试用不是强制性的，但它可以帮助用户决定是否值得购买该产品。
免费试用期在 itunes connect 中设置。
当用户第一次购买这个东西时，客户收到的收据中包含免费试用信息。
当免费期即将到期时，苹果发起了第一次扣费。
整个过程和自动续费类似，唯一的区别是第一个月是免费的。
回执验证 客户端收到回执后，需要提交给服务器进行处理和权限激活。
这就带来了一个问题：Receipt应该在客户端解析还是在服务器端解析？当然，需要在服务器端进行处理，以防止越狱后的一些插件，如IAP Cracker、IAP Free等伪造交易凭证来欺骗苹果服务器并激活权限。
另外，还需要注意的是，需要HTTPS和参数签名来保证客户端和服务器之间的通信安全。
服务器收到Receipt后，首先验证请求的有效性，然后将Receipt发送到Apple服务器进行验证和解析。
收到Apple处理结果后，对Receipt中的user_id、product_id、purchase_date、transaction_id等进行验证和处理。
IAP破解与防御 由于IAP验证主要在苹果服务器和手机客户端进行，并且使用域名。
这确实为攻击打开了大门，而不仅仅是漏洞。
早期的IAP内购解锁工具IAP破解器在破解IAP方面相对简单粗暴。
写过IAP程序的人都知道，程序中基本都是用transactionState来判断交易是否成功。
transactionState 有四种状态： SKPaymentTransactionStatePurchasingSKPaymentTransactionStatePurchasedSKPaymentTransactionStateFailedSKPaymentTransactionStateRestoredSKPaymentTransactionStatePurchased 表示购买成功。
只要修改这个变量的值，如果客户端应用程序直接根据交易状态处理业务流程，就会收到这条假的交易成功消息，然后用户就可以不用花钱就得到购买的商品。
这个过程甚至不需要访问互联网。
另一种工具 IAPfree 功能更强大，但安装和使用也更复杂。
它通过修改DNS，让客户端访问黑客提供的服务器而不是访问苹果服务器，从而实现所谓的MITM中间人攻击。
当用户在客户端触发购买流程时，会被引导至伪装的苹果服务器，不会扣款，而是直接返回扣款成功的收据。
用户无需支付任何资金，客户可以获得完整的收据。
如果在客户端处理收据验证是没有问题的。
为了防止用户使用的设备被屏蔽，这些软件甚至可以提供伪造UDID的功能。
为此，苹果特别表示，用户购买信息必须在服务器端进行验证。
验证内容包括收据签名、证书、制造商信息等，确保收据正确后才能授予权利。
如果发现欺诈行为，该用户将被封锁。
两种账户系统 Apple Pay的账户系统当然是基于Apple ID的，它允许用户在多个设备上共享一个账户。
一台设备上通常只有一个活动帐户。
但对于应用系统来说，大多数都允许多个账户登录，这对于续费来说是一个大问题。
用户使用a账号登录后，发起续费并获得权限。
然后我用B账号登录，显然A的权限不会派生给B。
过几天A就开始续费了。
续费后，切换到B账户登录。
客户端使用B账户登录时会收到续费回执，并发送给应用服务器。
那么这是谁的续订请求呢？当然是A了。
在该apple ID发起的续费请求中，所有收据都会有相同的原始交易号original transaction Id。
当用户发起订阅时，需要记录ID和账户的关系。
每次续费，都需要解析收据后根据原始交易号从这里获取真实的充值账户。
客户端提交的用户ID不能作为凭证。
还是这个坑，如果登录B账户后也发起订阅请求会怎样？这个调用将会失败，所以你需要阻止用户提出这样的请求，或者设置该产品的多个副本供用户购买。
分享、定价和国际化 iTunes 中的产品定价必须是税前的，苹果与商家之间的分享也是按税前基础计算的。
商家给出一个主要销售国家和地区的价格（比如中国基本上就是中国），即基准价。
对于其他地区的销售价格，苹果会根据当前汇率自动将其转换为当地货币。
当然，您也可以自行修改这些国家或地区当地设定的价格。
目前，它支持国家。
还要特别注意版权问题。
如果基础价格调高，用户下次续订时需要用户确认。
如果价格下调，则无需用户确认，直接扣款。
苹果对商户的产品定价体系有群组的概念，与国内的定价体系类似，如白金会员、黄金会员、VIP等。
在同一个群组中，用户只能选择一个级别，例如用户是白金会员或白金会员。
您要么是金卡会员，要么同时是金卡会员。
在同一群体中，如果用户订阅超过一年（天），商家可以获得更高的用户收入分成，目前为85%。
此订阅期不包括免费试用期。
还有 60 天的宽限期。
也就是说，在这一年里，如果用户停止续费再开始续费，只要不续费的时间不超过60天就可以。
目前IOS 10.0版本中使用的陷阱较多。
该版本存在与 IAP 相关的缺陷。
先记录一下：沙盒环境下，无法进行退订操作。
只能在线模拟。
因此，在设计和开发产品时，尽量不要依赖退订操作，也不应该依赖这个操作。
在沙箱环境下，部分收据可能收不到交易ID。
网上暂时还没发现这个问题。
Apple 提供两种格式：单一收据和清单收据。
建议使用列表数据，但问题是苹果不知道这个列表收据的最大长度。
Android IAP 嗯，用这个话题来总结一下不太好。
在IOS上使用Apple Pay是被迫的，但在Android上使用IAP还有什么意义呢？支付宝和微信支付拥有如此庞大的用户群，接入非常方便，而且费用比IAP便宜很多。
如果您有访问android IAP的经验，我期待分享。
相关阅读支付系统设计：支付系统的账户模型（1）支付系统设计：对账处理（2）支付系统设计：银行卡支付（3）支付系统设计：卡绑定、签名与身份验证（4）雷锋网注：本文由人人都是产品经理社区作者@凤凰品牌老熊（微信公众号：shamphone）原创发布。
凤凰牌老熊，程序员&架构师。
曾就职于富龙、三星（中国）研究院及国内一些大型互联网公司。
2006年加入爱奇艺，负责数据仓库和支付系统建设。
文章未经许可不得转载。
版权声明：本文内容由互联网用户自发贡献，本站不拥有所有权，不承担相关法律责任。如果发现本站有涉嫌抄袭的内容，欢迎发送邮件 举报，并提供相关证据，一经查实，本站将立刻删除涉嫌侵权内容。
标签：
相关文章
06-08
06-17
06-17
06-18
06-17
最新文章
Android旗舰之王的过去与未来
智能手表不被开发、AR眼镜被推迟，Meta的产品经历了一波三折
为什么Cybertruck是特斯拉史上最难造的车？
更新鸿蒙3后，文杰允许你在车里做PPT了
新起亚K3试驾体验：追求“性价比”，韩系汽车仍不想放弃
阿维塔15登场！汽车配备了增程动力，理想情况下会迎来新的对手吗？
马斯克宣布创建 ChatGPT 竞争对手！ OpenAI的CEO给他泼了冷水， GPT-5可能会发生巨大变化
骁龙无处不在，是平台也是生态