苹果应用内购买实践

最近项目中开发了道具功能,按苹果的要求(虚拟道具-应用可以不断的生产,没有成本的功能或服务)都需要通过苹果帐号购买,苹果会按你收入的30%提成,你只能到手70%.在开发此功能的时候,代码部分没有多,更多的精力是在itunes后台的配置上。

以下我会把后台设置,道具创建,购买和发布都介绍给大家:

1.后台条款与帐号

先登录苹果itunes后台https://itunesconnect.apple.com,选择“Agreements,Tax,and Banking”;页面上有三个地方需要设置:

  • Contact Info: 就是你公司一些相关联系人的信息,如果是个人开发者都可以选自己。首先Add New Contact,把相关人员信息写完,然后在下面的Role里面就可以选择刚编辑好的人员信息了。
  • Bank Info:选择Add Bank Account,会让你填写一个CNAPS Code的东西,你直接你银行卡的大线客服,说你要这个CNAPS Code(实际上是开户行的一个代号,招商银行是12们的数字);然后填写你银行的开户人和卡号,名字要求是英语或拼音。
  • Tax Info:选择U.S. Tax Forms,按他的提示选择,最后最麻烦的就是那个税的条款,1.Tax Information都要写;2.Substitute Form W-8BEN-E 选择14的a,b;15的Income from the sale of applications.其他按默认。提交
  • 都填写完成后,提交审核,大概一天能通过。

    2.创建道具

    打开后台后,选择My Apps;选择进入要增加道具的app;在上方会有四个功能(App Store,Features,TestFlight,Activity),选择进入Features;在In-App Purchases下,点击+号,开始创建自己的道具。需要注意以下几个问题:

  • 道具的价格只能选择苹果已定好的价格,不能自定义;
  • 道具的Product ID在同一应用内不能重复,在操作购买的时候需要此ID,所有在定义Product ID的时候要和服务器后台的数据关联。我们的做法是(com.companyname.item.道具的服务器Id);这样的好处是在代码部分就可以灵活拼接出product id.而不用在服务器数据库保存这个product id
  • 道具介绍和使用说明要认真写,并提交一张道具在应用内的截图。方便苹果工作人员审核
  • 以上应用都填写完整后,道具的状态会变为ready for submit.
  • 每次新增道具都必需跟着发版本,再次进行审核
  • 道具不能出现有效期多少天。个人理解是花钱买的东西应该是永久有效的
  • 3.完成以上步骤后开始创建内购时使用的测试帐号,此帐号也要在提交审核的时候一并提供给苹果

  • 选择进入Users and Roles后,上方会有三个选项(iTunes Connect Users, TestFlight Beta Testers, Sandbox Testers) ,选择"Sandbox Testers";
  • 选择+号后,开始添加自己的测试帐号;记录好自己的邮箱和密码
  • 添加成功后,在iPhone的设置中先把自己原来的app store帐号注销。先不要登录测试号,在后面的应用内点击了购买后会让我们再次登录的。
  • 4.代码开发内购

    购买流程大概是,第一步你告诉苹果一个要购买的道具productId后,苹果返回这个productId对应的商品信息(SKProduct);第二步把获取到的商品加入到购买队列中,等待购买结果的回调。要注意以下:

  • 代码有好多,自己去找个博客copy一下
  • 对商品信息进行缓存,这样第一步所消耗的时间就会减少。我们应用是在app打开后,获取到所有商品的productId后就进行了第一步操作,并把返回的商品信息(SKProduct)都以productId为key保存到了一个字典中。
  • 每次开始购买的时候先从字典中找有没有相关的商品信息(SKProduct);没有继续第一步操作,反之从字典中取出SKProduct直接开始第二步。研究了几个大厂的应用基本上都第一步很快(应该是加了缓存)。第二步大家都差不多慢
  • 可以把SKMutablePayment中的applicationUsername设置为自己业务中的订单号,这样在返回支付状态的时候也会带回来,我们再和服务器做校验base64串的时候一起发回服务器
  • 如果没有校验成功的SKPaymentTransaction,请不要调用[[SKPaymentQueue defaultQueue] finishTransaction:transaction];这样苹果每次有支付的时候把未完成的订单发回来给你,这样我们自己不用维护未校验的base64串和订单号(换手机或异常闪退也不用担心)
  • 从appStoreReceiptURL获取到一个receipt的凭证(在不产生新订单的情况下,receipt每次请求都不变),把这个凭证发给自己服务器去校验,如果服务器拿receipt再去苹果服务器验证,返回的内容中在in_app里有我们购买的道具说明此次购买就成功了,就可以finish transaction
  • 在in_app中有一个transaction_id,请返回器把这个返回后,然后在客户端把这个id对应的transaction关闭。不要轻易关transaction
  • 在有些情况下,新的订单支付成功了,但是receipt中没有in_app内容,此时可以调用SKReceiptRefreshRequest做一次刷新receipt.每次refresh后,receipt都会变。所以我们可以每次获取receipt的时候都先刷新一下
  • 因为看到猿题库的支付分享,说了越狱手机支付带来的风险(新浪微博也不让越狱用户购买),我们也直接判断了如果手机是越狱的,提示不让购买。
  • 服务器验证返回json要好好看,里面有一个products的数组,只有那个数组里面有数据的时候才算真正购买成功,每次有支付完成的时候,通过appStoreReceiptURL获取到的base64串都会发生变化,之前生成好的同一个base64串每次从苹果验证取到的内容都一样。
  • 在xcode8.3后发现如果在XCode Capabilities tab没有打开In-App Purchase会报“ Error Domain=SKErrorDomain Code=0 "Cannot connect to iTunes Store" ”
  • 5.发布时选择道具一起进入review

    刚开时以为只要把app提交了,这个版本的道具也会一并进入Review。但是当我提交后,进和In-App Purchases发现道具的状态还是”ready for submit”;网上说要把二进制包删除了再提交才会出来一个按钮,把道具加入审核;实际上最新版本在你当前准备提交的app itunes后台,选择Build的下方,有一个In-App purchases的选项,在那里把自己的道具添加后,再提交就一切正常了

    6.财务与退款相关

    产品上线后,每天都可以在itunesconnect后台看到我们昨天的收入,但是这个统计里面只有你的收入,而没有退款相关的。苹果退款直接走appstore那个平台了所以与这个管理后台是脱节的。申请退款是有时间限制,即必须在购买应用程序的90天内提出;开发商无法直接知道哪些Apple ID进行退款,更无法知道AppleID对应哪个玩家。但开发商可以同苹果核对充值订单号,再通过充值订单号上提供的时间和游戏后台的充值数据进行比对,从而找到退款人。 运营商不知道这次退款是正常的退款行为还是来自淘宝的低价代充订单,他们只能凭借经验判断。而且部分订单的退款周期比较长,比对起来相对复杂,同时不排除有同一时间同时充值的可能,想要弄清楚,可能需要较大的人力成本。

    所以在应用内购买的道具面值比较大的话,可要考虑那些恶意刷单(国内有太多这样的产业了,老外可能都没有听说过)。苹果也没有什么可靠的解决方案,打电话给苹果的技术,商店,财务都互相推诿。而在应用内我们不能做引导用户去网站购买,这样苹果是会下架的。

    上线线大家最关心的就是什么时候苹果给结算钱了,苹果的“财务月”与我们的自然月是不一样的(如下图)。

  • 1.财务月报可以通过“Payments and Financial Reports”模块下载。N月的财务报告,在N+1月的月底生成。
  • 2.月报根据App分发地区生成,每个地区有单独的报告。但每份报告没有固定生成日期,取决于该财务月内,在该地区的全部交易是否已完成。完整报告在下一个付款日之前的几天才会出具,而且这个“几天”也不固定。
  • 3.每个财务月结束后的45天内,苹果需要完成对开发者的支付。要符合最少支付金额(10刀)。金额不够就一直累计到够为止。通常在每个财务月结束之后的第五个星期四支付。我们目前只有4月的报告,支付日期是6月2日。
  • 4.日报和周报是根据用户点击和购买行为实时生成的,和自然日历一样;月报则按照财务月计算。两个系统特意设计得不一样,官方也不建议合并对账
  • 结算方法为:开发者实际收入= 定价*0.98*0.7。原因是,从去年9月起,在中国地区增收2%的交易税。 无法给出包含Apple ID和电话的对账单明细,特别是电话,走App内支付的时候这个信息是不收集的。 发票问题,没有回答,确实是“世界性难题”。 向PC端引导,是个风险问题,如被发现试图绕过app内支付功能,可能被下架。

    苹果虚拟商品定义

    苹果财务月