Q1:内购和Apple Pay的区别？
- A1:内购是内购，Apple Pay是Apple Pay。我不知道有多少人第一次接触时，会把这俩概念混淆掉，这里你可以简单这么理解，虚拟的物品就是用内购，实际的物品就是用Apple Pay。Apple Pay是一种支付方式，你可以类比为支付宝，微信那种。但人家只支持实际物品，如果你东西是虚拟的话，你却集成Apple Pay上架是要被拒绝的哦~当然反过来，实际物品你却集成内购上架，也是一样被拒。对于大部分的国内开发者而言，你很少会遇到需要集成Apple Pay的App的。能用支付宝/微信的场景还要求支持Apple Pay的产品毕竟是少数。
Q2:内购项目的类型区别？
-
A2：首先内购项目分为以下4种，消耗型项目，非消耗型项目，自动续期订阅，非续期订阅。我们来一个个介绍。
消耗型项目：只可使用一次的产品，使用之后即失效，必须再次购买。就是大家最广为所知的虚拟币，比如直播平台斗鱼的鱼翅，熊猫的竹子，哔哩哔哩的B币等，这个概念大家应该很好理解，不过多解释了。 -
非消耗型项目：只需购买一次，不会过期或随着使用而减少的产品。这个一般是游戏那里用的多，一般是付费解锁关卡的场景，用户买过一次，卸载重装或者同一个Apple id但换App账号时，也要能保证用户重新获得该内购商品。所以App内部需要额外去实现恢复购买的逻辑。
-
自动续期订阅：允许用户在固定时间段内购买动态内容的产品。除非用户选择取消，否则此类订阅会自动续期。iTunces上给的示例是：每月订阅提供流媒体服务的 App。对比我们熟悉的，网易云音乐的内购商品-连续包月黑胶VIP，就是此类型。一般来说，没啥必要不要选这一种，如果是VIP的那种场景推荐下面非续期订阅类型去做。自动续期订阅的坑非常多，比另外几种内购类型都要复制。
-
非续期订阅：一般来说VIP可以用这种方法来做订阅，我们公司项目的VIP购买就是这种方式。他的实现方式你可以完全照搬消耗性项目，不用做什么额外处理，也不用去管返回的订阅日期什么的东西，就是以服务器那边为准。服务器的日期开始，服务器的日期结束。既简单又保险，不需要额外的做什么处理。
Q3：VIP一定要用内购做吗？
- A3：其实判断你们公司的App到底需不需要用内购，很简单，就是看跟实际物品有没有关系。如果你的VIP功能是类似饿了么这种，点外卖可以打折/多领红包 那么就不需要用内购，上架的时候说清楚就行了。如果你的VIP功能是虚拟的，比如头像更炫酷，尊贵的VIP身份标示，独特的入场动画等等虚拟相关的，比如QQ会员，就必须要用内购去做。需要说明的是，那种是VIP才能和某某用户聊天的场景，是VIP才能得到App里某某用户的服务【语音，视频】时，这一类的场景苹果一样认为是虚拟的，一样要用内购去做。
Q4：VIP内购一定是非续期/自动续期订阅吗？我可不可以用虚拟币购买VIP呢？
- A4：这个问题我自己经历过。我的答案是你也可以用虚拟币购买VIP的这种方式，但如果被拒绝，你只能老老实实的按前种方式去做。如果你们的App既有虚拟币又有VIP，产品希望你VIP是直接用虚拟币去购买，这样整个流程都很方便。那么你一定要记住。千万不要在1.0版本这么做，这是血泪教训。1.0版本会抓的很严很严，同时虚拟币+VIP功能，百分百苹果会要求你VIP要用续期订阅去实现。最保险的做法呢，1.0版本不要做任何内购，迭代几个小版本后，加入虚拟币内购，在迭代几个小版本，加入VIP直接用虚拟币购买的功能，这是最最保险的做法。记住：1.0的审核力度是真的很严，能先不做内购就不要做内购，老板或许不懂，1.0版本什么都想要，但往往因为内购，会让你们的产品反复被拒。这一块如果大家感兴趣，可以看看，我的1.0版本就是加了内购，反复被拒5次。血泪教训
Q5：我们老板心疼那百分之30的手续费，我能不能不用内购啊，有没办法绕过内购？
- A5：办法是有的。但是有风险。我16年做过绕开内购的方法。思路很简单，就是App里集成支付宝/微信/内购这种功能，后台做控制开关，审核时，开关打开，给审核人员看内购功能，审核通过后，开关关闭，给正常用户是用支付宝/微信功能。这个方法，我17年的时候听到很多群友说不行了，你在上架审核时，苹果会扫描你的包，检测到第三方支付sdk时，会拒绝掉。后来又有群友说可以用H5的方式实现支付功能。另外可能会有别的绕开苹果审核的实现方式，如果有哪位朋友知道，不妨留言告知。但不管是哪种方式，都是有风险的，苹果对内购一直抓的很严，如果让它知道你们在钱的方面上欺骗过他，后果还是很严重的。iOS上的用户付费率还是很不错的，付费意愿基本上可以是安卓用户的十几倍。所以如果你们的产品真的有前景，并且想长久做下去，还是奉劝不要做欺骗苹果的事情了。
Q6：网上有好多讲丢单的博客，看的是一脸懵逼，有的看懂后，在看下一篇又不懂了，感觉都好复杂。
-
A6：我在刚接触内购的时候也是这样，我觉得有些博客讲的真有点过了，它为了考虑一些用户的极端操作，多出来很多逻辑处理，导致博客异常的复杂，我记得有博客讲必须要把receipt_data等信息存到keychain里，因为用户有可能卸载App，如果你只存到NSUserDefaults里，那样就丢单了。 …那么有没有这种情况呢？我觉得是肯定有的。但我们来算算几率，首先他内购成功，在向服务器调接口的时候，他手机突然没电了/断网了/程序崩溃了/网络差等的久他自己杀死进程了 巴拉巴拉。 然后他在下一次手机恢复正常的时候，果断卸载掉App，重新去App Store上下载安装，进入App后，发现内购没到账。
867088104DC1554FE5CDF4E962061E43.jpg -
网上博客还爱用那种切换账号的场景举例，A内购成功了，但用户各种骚操作后，自己换到B账号，然后服务器那边把商品发到B账号上了，等等。
-
这些情况都是存在的，因为苹果的内购机制问题，你是不能百分百保证不丢单的，不要把丢单情况看的那么严重，逻辑写的那么复杂。你看看所有大厂的App上都会写充值遇到问题，点我联系客服 巴拉巴拉。关于丢单，我的做法是这样的，在苹果内购成功的回调里，NSUserDefaults存每一笔支付成功的订单，如果服务器校验成功，就把本地存的这笔订单删除。如果没收到服务器的响应，就一直保留。然后每次App启动就会去把本地存的丢单信息扔向服务器校验，校验成功删除，校验失败不管。这里还是看开发时间，当时我写内购功能的时候，预算时间就两天不到，所以写的飞快，就简单的用这个办法去防止丢单，目前来看，没有发现过一笔真正用户充钱但商品没到账的例子。如果大家开发时间充足，可以慢慢去弥补极端操作漏洞。
Q7：内购为什么会有这么多坑啊？看网上好多博客都在说，我自己做微信/支付宝的时候，没感觉有这么多坑啊
A7：苹果的内购坑主要有以下几点
applicationUsername该字段可能为nil 导致客户端没办法用这个参数给服务器透传订单编号，来形成一个交易订单号的绑定。
校验订单流程是必须服务器主动去询问苹果服务器，而支付宝/微信 却是他们的服务器会在用户支付成功时主动给我们服务器回调。正是这个原因，让iOS开发者饱受折磨，大部分的丢单漏单都是苹果的这个设计造成的。苹果不会主动回调给我们服务器，也就意味着我们服务器需要主动去苹果那里询问这笔订单，到底成没成功。但服务器询问的时机，又是客户端告诉服务器的。这就鸡儿坑了，一些情况下，用户在付费成功后，突然断网了/崩溃了/出现意外了等等，客户端没办法告诉服务器，这就出现了，用户钱成功了，内购商品却没到账。所以网上才会有这么多篇讲防止丢单的博客。
越狱下，插件也能破解掉苹果内购，然后校验状态status还返回成功。也就是本篇博客开头讲的那种情况。这一点真的是无力吐槽，亏你特么回调给我的receipt_data那么一大长串，有卵用？
苹果的订单机制。苹果为了保护用户隐私，你是看不到一条条流水明细的。你看到的只有这种。
每一种内购类型的总收入，或者总销量。导致对账查询的时候加了不少麻烦。
苹果的退款机制。这个比上面一点更坑，iOS用户，内购了某商品，你可以在完全用完了后，联系苹果客服，说我误操作了巴拉巴拉或者说感觉这个商品不值那么多被开发者欺骗了巴拉巴拉，快给我退款，客服就会温柔的告诉你，不要急，她会帮你处理，1-2个工作日把，你就会发现你的钱就退回来了。没记错的话，一段时间内，一个Apple Id可以申请1-2次。但不能多，多了的话就会被苹果拒绝。而这一切，开发者这边是完全不知情的。你不知道哪个用户退款了，你知道的只是一个图，类似下面的这种。
239
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
