13518219792
1、在开发者账号设置协议、打开itunes Connect,选择协议，税务和银行业务。
创新互联一直秉承“诚信做人，踏实做事”的原则，不欺瞒客户，是我们最起码的底线！ 以服务为基础，以质量求生存，以技术求发展，成交一个客户多一个朋友！为您提供做网站、成都做网站、成都网页设计、微信小程序定制开发、成都网站开发、成都网站制作、成都软件开发、手机APP定制开发是成都本地专业的网站建设和网站设计公司，等你一起来见证！
2、点击Request Contracts(申请合同)下面的,request，点了几个确定和下一步后回到主界面。
Contact info:联系人信息
Bank info:银行信息
Tax info:税务信息
3、首先设置联系人信息,点击Contact info下面的 Set up(设置),点击Add New Contract(增加先的联系方式)。
4、填写详情，填写完成后点击save(保存)。
5、在下面的所有项目中都选择刚刚填写的信息,选择后点击右下角的done(完成)，你可以创建很多联系人,在不同的职务选择不同的联系人。因为我是独立开发,所以我全部填写的我自己。
6、设置银行信息,点击Back info下面的Set up,弹出页面,点击Add Bank Account(添加银行账号)
6.1、选择china,后点击next。
6.2、填写了CNAPS Code后点击Next
查询现代化支付行号
6.3、会弹出你的银行卡开户地的信息,确认一下点击next
6.4、填写银行卡信息，注意:户主名只能写拼音,比如：李三(Li San)。填完后点击Next
6.5、弹出确定信息页面，在下面打钩后点击Save
6.6、点击了save后就可以在弹出的页面中选择刚刚填写的卡了。选择后点击Save
7、设置税务信息，点击Tax info下面的Set up,此时联系人信息已经变成可以编辑状态,银行信息为浏览状态。
7.1、弹出的界面中,税务分为三种 U.S Tax Forms: 美国税务、Australia Tax Forms：澳大利亚税务、Canada Tax Forms: 加拿大税务
这里我选择的美国税务,就是第一个
弹出第一个选择,点击submit(提交)后,弹出第二个选择
弹出第二个选择,选择后点击submit
弹出第三个页面，填写的资料后点击提交,记得勾选页面上的几个复选框
在提交成功后,状态就变成processing成功
1.进入到项目的APP信息页面,点击功能，在弹出的页面点击App内购买项目后面的➕。
2.在弹出的新对话框中选择你需要哪一种服务，由于我的项目需要兑换成消耗的金币,所以我选择第一个。选择后点击创建。
3.开始填写内购项目信息。填完后点击右上角的存储(所有信息必须填写完整)。
4.点击存储后，内购列表就会有刚刚创建的内购条目。
1.点击用户和职能
2.点击沙盒测试员,然后点击左边的➕按钮
3.设置好信息点击右上角存储就可以,记住里面的邮箱和密码用于支付的时候登陆Apple id
注意：
1.必须用真机测试。
2.测试的时候必须退出自己的apple ID。弹出页面后登陆沙盒的测试apple id。
// 1.首先导入支付包#import Storekit
[iOS]应用内支付(内购)的个人开发过程及坑！
APP内购集成详解
这个问题是最典型的财务问题之一，只要你公司内购有收入，你多多少少都会被财务同事或者老板问过这个问题。可能你会说是漏单啊，苹果误差啊，汇率啊等等各种原因，来解释过去。这些似乎也对，似乎又不对，如果你深究下去，会发现很多有意思的事情。这里笔者来详细的分析下为什么会出现这个情况。 首先要区分下，公司的苹果财务报表数据是怎么来的？在这里我们假设为最通常的场景。即公司的报表数据是由后台同事统计而得。而后台同事的数据是由客户端传的凭证来统计，验证通过，xx商品售出数量+1，收入+xxx。然后统计出来一个月的内购数据。这就是公司的财务报表数据了。苹果后台的财务预付款数据为 付款和财务报告-估计总收入栏的值。如下图
在明确了两个统计数据来源后，我们来列举下产生这个问题的所有可能性原因。
后台统计金额时，时间用的不是UTC时间（0时区时间）
此类原因比较容易排除，分别看后台数据xx商品销售量和苹果后台xx商品销售量一一比较即可。这里需要注意，可能后台会出现销售量比苹果销售量还多的情况，这个情况原因可能是后台判重逻辑未做好，有Bug。也有可能是用户发生了退款。那么如何看用户是否退款了呢？
销售和趋势-产品销量-添加过滤器-交易类型-退款 如下图
如果你发现后台销售量与苹果销售量完全对的上，没有出现丢单多单退单等现象。但是苹果的预付款收入还是比财务统计的要少几百，几千甚至几万刀。那么很有可能这个巨大的误差是来自苹果坑爹的财务日历系统。
我们正常理解是假设为内购5月份的收入，那自然是5月1日-5月31日的总收入。然后苹果会在7月初进行打款。打款的金额应该是5月整个自然月，然后扣除掉30%手续费的收入。后台同事往往也是这么统计的。然鹅。苹果对于自然月的理解并非如此。点击付款和财务报告-选中日期-点击最下方的查看财务日历，如下图
点进去，我们会发现，苹果的5月是这么算的。。。
如果你不知道这个事情，可能会连续两个月被财务追问，为什么这个月苹果又少打钱了....
当然这些钱，苹果也并未贪你的，比如苹果的7月是指6月28日到8月1日。嗯，一般多打款的话，财务是不会找你的。。。
我们上面说的都是苹果后台预估总收入的数据，实际上这个数据并不一定准确，可能会有变动。变动的原因一般是因为退款，用户退款，苹果是不会承担任何责任的，会扣掉你的收入。即使你内购商品早已经发放了，还一个原因是因为汇率。
所以如果你分析了以上所有的情况，发现数据还是相差，不妨等等最终公司银行卡到账的金额。
另外实际到账的金额也可能会有偏差，这个偏差主要是是否有中间的金融机构或银行进行手续费扣除。实际到账的金额应该不是正好为真实收入*0.7，多少都会有损耗。
如果你的App是面向全球用户的App，那么肯定遇到过此类问题。产生这个问题的主要原因是，各地区的税率问题。比如我们商品定金是0.99美金。但是在欧盟区，用户实际支付的金额（换成欧元后）的价值 也是大于0.99美金，大概是1.几美金。所以看苹果后台你的销售额会增长很多。然鹅实际上，收入还是0.99美金*0.7。多出来的那些钱是欧盟向苹果收取了，跟公司没关系，只是表面上看着让公司销售额增长了。
付款和财务报告上面会有详细的预估苹果打款日期。如果日期还未显示，则说明还未到打款时间。
一般来说，当月的款，会在下下个月的月初进行转账。
即5月份的款项 一般是7月月初（最晚不超过15号）。也就是说如果你发现你的款项已经超过45天都未收到。那肯定是有问题的。可能的原因如下：
①内购收入未达到当地开发者账号结款的最低要求。
②账号本身出现问题，涉嫌欺诈、隐瞒、或被调查（非必要原因，有时候调查期也会正常打款）
③其他原因（如银行卡有问题，苹果尝试转账却扣款失败，或者已经超过汇率结算，被银行拦截等）。等等这些问题都可以去联系苹果支持来寻求帮助。
对，也不对。
对于大部分地区的开发者账号，最低打款门槛限制为150美金（如中国）
对于部分地区的开发者账号，最低打款门槛限制为10美金（如香港，印度，英国，法国，日本，意大利，加拿大等）
对于韩国来说，其最低付款门槛为 50 美金。
具体数据可参考以下网址：
苹果最低打款金额限制
点击 “协议、税务和银行业务”
内购用的是付费应用程序，先签署《付费应用程序协议》，同意后状态变更为“用户信息待处理”，等待审核。
状态更改完毕后，点击“开始设置税务、银行业务和联系信息”。
（1）添加银行账户,按照要求填写相关内容即可。
（2）选择报税表，并填写。所有与 Apple 有商业合作者必选都是美国，若有其他需求，可以多选。
继续填写，首先认证公司基本信息，选择所有人类型，确认无误后认证条款处打对勾
Part I 部分，继续核对公司相关信息，选填内容可不填。
Part III 部分，签署税务条约，设置利益限制条款的种类，选填内容可不填。此部分如果需要可勾选上下图勾选框，不需要可不勾选，我们这个项目没有用到part III 部分,所以没有勾选。
Part XXX 部分，确认之前填写的信息，勾选完毕后，提交
（3）填写联系信息，共5个。高级管理、财务、技术、法务、营销。只需要提供5个人的基本信息即可。
只可使用一次的产品，使用之后即失效，必须再次购买。
示例： 钓鱼 App 中的鱼食。
只需购买一次，不会过期或随着使用而减少的产品。
示例： 游戏 App 的赛道。
允许用户在固定时间段内购买动态内容的产品。除非用户选择取消，否则此类订阅会自动续期。
示例： 每月订阅提供流媒体服务的 App。
允许用户购买有时限性服务的产品。此 App 内购买项目的内容可以是静态的。此类订阅不会自动续期。
示例： 为期一年的已归档文章目录订阅。
App 内购买项目的截屏，即所售项目的示意图。例如，如果 App 内购买项目是一本图书，您可以提交图书的截屏。您也可以提交购买页的截屏。该截屏仅用于 Apple 审核，不会在 App Store 中显示。
截屏要求如下：
iOS 至少需要 640 x 920 像素
Apple tvOS 需要 1920 x 1080 像素
macOS 需要 1280 x 800 像素
App 审核图像上传后，可以替换，但无法移除。当您的 App 内购买项目处于审核中时，您无法更新截屏。
沙箱账号是不能直接在App Store进行登录的，只能在点击了购买商品之后，在弹出的登录框进行登录 。
验证是否已登录沙箱测试账号：
设置--iTunes Store与App Store，页面拉到最底部，会看到沙箱账户项会列出你已登录的沙箱测试账号！
操作方法一：打开App Store应用首页滑到最下方--选中AppleID--注销
操作方法二：设置--iTunes Store与App Store--选中AppleID--注销
checks if the client can make payments(检测App是否能支付)
getAvailablePurchases
Get all non-consumed purchases 获取未消费的商品
打印信息查询；
原因：
没有先执行getProducts，直接执行requestPurchase方法,要先拉取商品列表，再执行购买操作.
问题描述；
1.漏单必须要处理，玩家花RMB购买的东西却丢失了，是绝对不能容忍的。所谓的漏单就是玩家已经正常付费，却没有拿到该拿的道具。
解决：只要购买成功，便将购买记录(receipt等账单信息)保存下来，然后将账单信息传送给我们游戏服务器，游戏服务器获得账单后，和苹果服务器验证，账单有效的话，回馈给游戏服务器处理，游戏服务器处理后，返回给游戏客户端处理，处理完毕，将本地保存的购买记录删除。
官方文档：向苹果校验支付凭证
21000 App Store无法读取你提供的JSON数据
21002 收据数据不符合格式
21003 收据无法被验证
21004 你提供的共享密钥和账户的共享密钥不一致
21005 收据服务器当前不可用
21006 收据是有效的，但订阅服务已经过期。当收到这个信息时，解码后的收据信息也包含在返回内容中
21007 收据信息是测试用（sandbox），但却被发送到产品环境中验证 【请求sandbox校验支付凭证】
21008 收据信息是产品环境中使用，但却被发送到测试环境中验证
消耗类型： 例如：金币、道具等。
非续订订阅： non-renewable subscription 例如：VIP
您的首个 App 内购买项目必须以新的 App 版本提交。请创建您的 App 内购买项目，然后前往 App 的“App Store”页，从“App 内购买项目”中进行选择，点按“提交”。 了解更多
在上传二进制文件并提交首个 App 内购买项目以供审核后，您可以使用下表提交其他 App 内购买项目。
唐巧-iOS应用内付费(IAP)开发步骤列表
未完~待续
当使用内购购买过商品之后没有把这个交易关闭，所以再次去购买商品后就会调用以前已经购买成功的交易去购买因为已经购买过，才会有这个提示
原因：添加内购项目时，信息填写不完整，app审核图像未上传
处理方法：上传app审核图片( 合适的尺寸 )，点击提交，状态改为正在准备审核中。
这个是内购选择类型不匹配原因导致。
购买成功之后，Apple会返回以下四个数据给应用
Reference
Review the updated Paid Applications Schedule.
游客身份解决方案：即不登录也要能购买
1）服务器端做一个苹果审核机制，审核期间游客身份可以进行一切行为，一旦审核通过，修改服务端即可达到强制用户登录进行内购买的目的（这个有点。。。）
2）游客可以进行内购买，购买时以设备UUID为准，生成一个游客账号，将购买信息保存在服务器和本地，当用户登录正式账户后判断此设备是否进行过内购，有的话提示用户将游客身份购买的权益与现有账号绑定，如果绑定，游客权益则迁移到正式账户，如果不迁移，则游客身份和正是账户是两个独立账户，正式账户不享有游客身份的权益（我用的这个）
内购游客模式解决方案
iOS内购规则
首先：我只是个iOS开发的菜鸟，语文不及格的学渣。写的东西都只是一点自己的浅显的理解。如有不对，欢迎大神们指点，小弟虚心学习~我只是个梦想成为大神的菜鸟。
闲话少说。这篇文章是关于苹果IAP的一个可能导致项目丢单的bug.（可能是bug,也可能是我没有透彻的领悟苹果的用意，抛出来供大家参考）
问题的根本出现在内购SKMutablePayment 类的 applicationUsername对象在部分情况下会被苹果丢掉，成为null。
applicationUsername 是苹果在iOS7.0及以后为内购增加的一个自定义字段，开发者可以在该字段中记录一些自定义的数据。但是在使用过程中发现，部分（注意强调下，是部分）用户第一次使用苹果内购时，手机会提示用户去绑定银行卡。这时用户点确定过去绑定银行卡后继续点确定支付，苹果内购回调：
- (void)paymentQueue:(SKPaymentQueue *)queue updatedTransactions:(NSArray *)transactions;
方法接收到的付款成功的 SKPaymentTransaction交易中的SKMutablePayment对象的applicationUsername会被苹果置为null.再次强调，这个问题只会部分用户发生。目前还没有找到规律，也没办法复现。
基于以上问题。如果大家的项目将例如内部订单号等信息存入applicationUsername中，就有可能导致存入的信息丢失的问题。不同的设计可能会引发不同的bug。由于我的项目将内部订单号存入applicationUsername，丢失后，无法提交服务器校验小票。所以就丢单了。
另外在分享个需要注意的：就是前面提到当用户点击确认绑定手机卡跳走后，苹果会首先返回一个支付取消的通知。如果用户很乖的绑卡并且确认支付，苹果又会返回一个支付成功的通知。所以这里也需要大家注意，不要因此引发什么问题。
可能这个问题对大家来说并不会导致丢单或其他问题。只是在这里给大家分享下这样的一个坑，万一有人跟我一样的做法呢~防止大家入坑，希望能帮到大家~ Ps.马上过年了，祝大家新年愉快。
iOS苹果内购(详细步骤)
iOS 内付费（in-app purchase）－－非消耗品的购买与恢复
恢复购买官方地址
苹果内购商品信息获取
Unity苹果(iOS)内购接入（Unity内置IAP）
# Unity3d发布IOS(包含u3d自带IAP内购)的流程-小白篇(三)-u3d配置ios内购部分
每次支付行为或每笔交易被认为是一个SKPaymentTransation，只有当SKPaymentTransation被finishTransaction:，这次支付（交易）行为才算是正常结束了。即使这次支付途中被中断，其实也并没有丢失。假设支付没有完成 App 就退出了（比如崩溃），那么当下次 App 重启之后，只要设置了监听addTransactionObserver:，之前被中断的支付就会接着进行。
第1步，这个过程中 App 进程因为某种原因被 kill 了，其实支付行为还在系统后台进行着，苹果自己做的，很有可能扣款成功。但是这时候没法为用户充值虚拟货币。
第2步，App 端与自己服务器端通信失败；自己服务器端与 AppStore 服务器之间的通信失败。
针对第一种情况，可以在 App 一启动就设置监听，如果有未完成的支付，则会回调- (void)paymentQueue:(SKPaymentQueue *)queue updatedTransactions:(NSArray *)transactions;这个方法，在这个方法里调用接口充值。
至于第二种情况，App 端需要做接口重试，设置一个重试的逻辑。
在发起支付请求之后，苹果返回商品列表，先请求服务器下单接口，成功之后，将订单信息保存在钥匙串，然后发起支付，在支付状态的回调当中， 成功了就去做服务器的验签操作，验证成功，关闭事物，并将订单信息删除，支付完成
app启动时监听掉单情况， 如果有掉单情况，回走事物更新的回调，然后再回调里，通过钥匙串拿出订单相关信息，然后获取支付凭证，重新向服务器发起验单的流程。
钥匙串保存订单信息作用：为了拿到订单的相关信息作为参数来请求服务器验签接口。
iOS内购这块的开发一直比较麻烦，除了各种购买选项的问题，最恶心的问题就是丢单问题。
丢单就是iOS内购过程中付了钱，但是App没有发货的问题。要解决丢单问题，先要梳理一下整个购买的过程:
以上就是整个购买的过程，现在我们根据每一步分析下可能出问题的点
这一步的操作就是让服务器创建当前购买商品的订单，返回结果失败或者成功，这里基本不会出问题，成功就继续接下来的流程，失败的话，客户端返回失败的提醒就行。
绝大多数的问题都出在这里,在这里说一下我遇见的坑
对于第一个问题，内购的api有一个监听机制，在每次app刚启动的时候调用 [[SKPaymentQueue defaultQueue] addTransactionObserver:self]; 方法， - (void)paymentQueue:(SKPaymentQueue *)queue updatedTransactions:(NSArray *)transactions ，会回调所有未执行 [[SKPaymentQueue defaultQueue] finishTransaction:tran]; 的transaction，这个时候再去和服务器进行订单的验证。这里还有一个很麻烦的问题，在上个流程中，调用服务器创建了订单，会返回一个订单号，验证的时候一般都是把订单号，以及receipt，transactionid一起发送给服务器，但是这里是拿不到订单号的。针对这个问题，网上有人用 applicationUsername 这个字段去存入订单号，但是也有一些人在使用这个字段的时候出现了Bug（App杀死后，获取这个字段的值为空，参见下面的引用），为了保险，这里还是不用字段。我的解决方案是在用户创建完订单之后，存储当前的订单信息，用户token等等，当购买完之后，再去取这个订单信息，完成验证，删除订单，这个方案的核心是永远只存储一个订单，若在购买的时候有未完成的订单，必须先验证之前的订单，验证完之后，再去发起新的购买，这样就能规避多个transaction不能匹配订单号的问题；
对于第二个问题，这个问题好解决，不用这个第三方就行，自己造个轮子，基本的购买逻辑很简单，没必要用这个插件。当 - (void)paymentQueue:(SKPaymentQueue *)queue updatedTransactions:(NSArray *)transactions 返回的transaction的state为failure时候，finish这个transaction，state为purchsed的时候，去验证。
这里还有一个问题，finishTransaction：的调用时机，一定要在与服务器完成验证之后，再去调用这个方法，因为在与服务器的验证的过程中，也是会出现错误的，如果再购买成功回调之后就调用这个方法，验证错误的订单也被finish了，下次去取transaction的时候，就取不到了，这样就造成了丢单问题。
这里的逻辑基本就是自己的了，跟苹果内购关系不大，把订单、receipt等信息发给服务器就行，唯一需要注意的问题就是网络错误，这个时候我会做一个轮循，在发生错误的时候，轮循几次，超过这个次数，认为验证失败，等到用户购买下一个商品、或者app重新启动，会重新验证这个订单（当然，这个情况是极少的！为了严谨，做了以上处理）
终于到最后一步了，这里有一个地方需要注意一下，就是本地服务器与苹果服务器验证的方式，之前我们公司出了个问题，在调用 /verifyReceip 这个接口去验证，苹果会返回一个数据status，它们认为status等于0就是完成购买了，但是这个字段的含义并非如此
它只是反映这个receipt是不是完整的,并不能证明这次购买完成。正确的做法应该是服务器拿到此次的transaction和receipt之后，解析receipt，拿当前的transaction和receipt里的transaction数组去比对，若数组中有这个transaction对应的transactionid，则认为购买成功。
苹果服务器返回的错误码中，我们只需留意21005即可，它代表验证服务器当前不可用（当然这种情况是级级级小的！为了严谨），处理的方式和网络错误的处理方式是一样的。
