iOS内购：自动续期订阅总结

前期准备无非就是在App Store 建内购的选项，这部分网上有很多文章，我直接推荐看此篇 https://wwwjianshucom/p/479cf9e31104 完成前期准备及一些常理的知识了解。当然，项目中我也是直接集成IAPHelper https://githubcom/saturngod/IAPHelper 进行内购API集成。

主要参考如下解决：

上面的部分解决了消耗型商品内购的功能。

但是此篇是自动订阅：所以需要增加一个参数: password: 秘钥, 就可以了, 但是官方文档说秘钥仅仅用在自动续订上面

大家叫后台加个验证，如果苹果验证返回21004的话（21004 你提供的共享密钥和账户的共享密钥不一致），就加上password字段去验证，可以成功。 秘钥去 https://itunesconnectapplecom/ 里面对应的APP里创建

2中主要是手机内购成功后传receipt给服务端，然后去验证的。然后有没有想到很多需解决的问题？

31 订阅状态的处理

主要处理如下：

如果您阅读了RENEWAL事件的描述，您将注意到 - “过期订阅的自动续订成功。检查订阅到期日期以确定下一个续订日期和时间。” 通常，iTunes会在计划自动续订订阅到期前一天尝试向用户帐户收费。如果续订成功，则没有服务器到服务器通知，因为自动续订订阅未进入过期状态。但是，在少数情况下，iTunes无法续订订阅（通常与信用卡服务器存在连接问题）并且在expiration_date通过之前未续订自动续订订阅，从技术上讲，自动续订订阅被视为“过期”。然而，iTunes仍将继续尝试续订订阅。iTunes成功，然后发送“RENEWAL”事件。出于这个原因，提出了建议 - “检查订阅到期日期以确定下一个续订日期和时间”。

要验证自动续订订阅In-App Purchase是否是最新的，请使用verifyReceipt服务器验证appStoreReceipt。假设in_app数组中存在自动续订订阅项，则查看latest_receipt_info记录并查找具有晚于当前日期的expires_date的订阅记录，其中一个未设置cancellation_date字段。备注：被退款订单的唯一标识是：它带有一个cancellation_date字段。

参考： https://forumsdeveloperapplecom/message/283579#283579

in_app与latest_receipt_info

测试时发现，这两个字段的数值几乎相同，不过有几点需要注意：

（1）自动续订订阅类型，在到期后会再生成一条购买记录，这条记录会出现在last_receipt_info里，但不会出现在in_app里

（2）自动续订订阅类型可以配置试用，试用记录只有在latest_receipt_info里，is_trial_period字段才是true

（3）消耗型购买记录有可能不会出现在latest_receipt_info，因此需要检查in_app来确保校验正确

购买了一个订阅后得全额付款，只有通过联系苹果客服服务才能退款。 比如，如果用户意外买错了产品，客服中心可以取消该交易并退款。 用户不能在订阅周期中间改变注意不支付剩余的订阅。

要想确认某次交易是否已经被取消，在收据 (receipt) 中查找 Cancellation Date (取消日期)字段。 如果该字段有日期，不管该订阅的过期日期是什么，该交易都已经被取消---取消交易就是跟没有购买过一样。

根据产品类型，只能检查当前的活动交易，可能需要检查过去所有的交易。比如，杂志应用需要检查过去所有的交易来决定用户访问了那些期刊。

官方文档 https://helpapplecom/app-store-connect/#/dev7e89e149d

如果用户再同一自动订阅组，如用户自动订阅买过，免费试用标识就要隐藏掉。因为内购支付购买不会出现免费试用。

首次购买 is_trial_period = true; is_in_intro_offer_period是否是否是在试用期 ； expires_date-purchase_date 就是免费的周期

自动订阅expires_date 会苹果会自动订阅，然后App启动会- (void)paymentQueue:(SKPaymentQueue )queue updatedTransactions:(NSArray )transactions

在APP启动时候要增加侦听：

[[SKPaymentQueue defaultQueue] addTransactionObserver:self];

让用户管理订阅

不需要编码实现订阅管理 UI ，应用程序可以打开以下 URL

https://buyitunesapplecom/WebObjects/MZFinancewoa/wa/manageSubscriptions

参考：

记录：微信和支付宝支付-看我的，用我的就够了 https://wwwjianshucom/p/020621c3a660#

就是程序内有付费的内容

以下为介绍：

　　In App Purchase 给您支持各种不同的商业模型提供了灵活性。您可以在您的程序内给客户提供附加的服务和内容。

　　例如，您可以创建一个订阅杂志的程序，而用户可以按月，按年，或者按照您选择的周期付款。在游戏中客户需要付费以进行更高级别的体验。在一个通用的城市地图程序中，用户可以按照选择的城市来付费。这种新的能力带来了很多商机。

　　您只需创建程序，我们提供付款机制。新Store Kit框架提供了通过 iTunes Store 处理付款的能力。您将付款项提交到 iTunes Store 中并设定价格。当客户选择付款时，您的程序会创建一个支付请求并发送给 iTunes Store 来处理。在 iTunes Store 验证并批准该请求后，您的程序会得到通知从而可以提供随后的功能或内容。

　　相似的商业条款。In App Purchase 使用和 App Store 中同样的商业条款。您将收到您的程序中付款项价格的 70%，按月付款 — 没有额外的信用卡费用。

　　大体来讲，购买成功后，苹果AppStore服务器会向app端返回此次交易的数据，其中有这笔付款的收据(Receipt)。然后app与游戏服务器通讯，把购买成功的信息通知服务器端（为了防止越狱和IAP free等插件造成的欺诈性购买，还需要把收到的receipt发给游戏服务器，游戏服务器再将其发往苹果AppStore服务器验证其真实性）。服务器端确认此次购买成功后，修改服务器端记录的此客户端对应的财富值，并将修改后的结果反馈回App端，App端随之作相应更新。

       与服务器端的通信，就是一个RPC的过程，服务器端写好一些供调用的API接口，在客户端联网调用，具体有什么xmlrpc, jsonrpc的，都有开源的框架可以使用。

注意：客户端与游戏服务器端通信的时候，必需附带一个标识其身份的代码（UUID或者帐号名称），否则服务器端无法知道是谁进行了充值。

是的。

网站api接口开发不仅仅局限在某些类型的网站上，市面上很多的网站只要是想传输数据给他人的都需要做网站api接口开发。通过api接口开发，他人可以获取我们网站上的数据，这里头的数据不仅仅是指一些账号密码数据，还有其他的各种类型的数据；也可以是传输给我们数据在我们现有数据库上做验证。市面上我们经常在接触的网站API接口开发有腾讯账号同步登录、微信公众号/小程序系统、微博账号密码同步等等，这些都是很常见的。还有的就是各种网站为了提供数据而开发的各种API接口了，也就是不同网站间要数据传输，API接口开发就是必要的。