参考借鉴了一下几篇文章（在这里很感谢各位作者大大做出的总结和方案）：

http://blog.csdn.net/autfish/article/details/52682778 

http://blog.csdn.net/a351945755/article/details/22928491

http://www.cnblogs.com/fengmin/p/5562769.html

iOS游拍 iAP 充值 SDK

一、登录 App的ItunesConnection，添加内购

我们打开创建的App,会看到左侧的App 内购买项目。我们为App添加内购项目。填写内购产品的相关信息，将内购产品送到APPStore审核

二.申请沙盒测试账号(用来测试购买项目)

首先我们到iTunes Connect中,在这里我们选择用户和职能。

然后在上面的沙箱技术测试员中添加测试员。

PS1:所有信息都可以随意填写，不用管是否真实。App Store地区选择，一定要选对，它对应的是你创建的App的地区， 你App是中国的话， 在这里我们依然选择中国。

PS2:此账号只能用来测试，不要在正式的appstore上使用

PS3:填写完毕，点击保存后，我们则生成一个测试账号，当然这个账号是可以随时删除和添加的。

三、实现方式（服务器类型实现内购）

客户端

程序向服务器发送请求，获得一份产品列表详细信息。

程序把返回的产品信息显示给用户

用户选择某个产品

程序向App  Store发送支付请求，同时向服务器发送支付请求

App Store处理支付请求并返回交易完成信息。

程序从信息中获得数据（收据），并发送至服务器。

服务器验证通过后将返回结果（购买的内容）传递给程序。

服务端

服务端录入产品列表（列表信息跟iTunesConnect里添加的购买信息一致）

服务器接收客户端请求返回包含产品信息列表。

服务端接收客户端的购买请求生成订单

服务器接收并纪录客户端发来的数据，并进行审(我们的)查。

服务器将数据发给App  Store来验证该交易的有效性。

App Store对收到的数据进行解析，返回该数据和说明其是否有效的标识。

服务器读取返回的数据，确定用户购买的内容。

服务端验证收据流程：

从transaction的transactionReceipt属性中得到收据的数据，并以base64方式编码。

创建JSON对象，字典格式，单键值对，键名为"receipt-data"， 值为上一步编码后的数据。效果为:{"receipt-data"    : "(编码后的数据)"}

发送HTTP POST的请求，将数据发送到App Store，其地址为:

appStore上线：https://buy.itunes.apple.com/verifyReceipt

沙盒测试：https://sandbox.itunes.apple.com/verifyReceipt

App Store的返回值也是一个JSON格式的对象，包含两个键值对，

status和receipt:    {"status"    : 0,"receipt"    : { … }}

如果status的值为0， 就说明该receipt为有效的。 否则就是无效的。

```

Status其余状态

0recipt有效

​21000AppStore无法读取你提供的JSON数据

21002收据数据不符合格式

21003收据无法被验证

21004你提供的共享密钥和账户的共享密钥不一致

​

21005收据服务器当前不可用

​

21006收据是有效的，但订阅服务已经过期。当收到这个信息时，解码后的收据信息也包含在返回内容中

​

21007收据信息是测试用（sandbox），但却被发送到产品环境中验证

​

21008收据信息是产品环境中使用，但却被发送到测试环境中验证

​

receipt中对应的内容：

​

键名描述

​

quantity购买商品的数量。对应SKPayment对象中的quantity属性

​

product_id商品的标识，对应SKPayment对象的productIdentifier属性。

​

transaction_id交易的标识，对应SKPaymentTransaction的transactionIdentifier属性

​

purchase_date交易的日期，对应SKPaymentTransaction的transactionDate属性

​

original_-transaction_id对于恢复的transaction对象，该键对应了原始的transaction标识

​

original_purchase_-date对于恢复的transaction对象，该键对应了原始的交易日期

​

app_item_idAppStore用来标识程序的字符串。一个服务器可能需要支持多个server的支付功能，可以用这个标识来区分程序。链接sandbox用来测试的程序的不到这个值，因此该键不存在。

​

version_external_-identifier用来标识程序修订数。该键在sandbox环境下不存在

​

bidiPhone程序的bundle标识

​

bvrsiPhone程序的版本号

```

App Store的收据

发送给App  Store的收据数据是通过对transaction中对应的信息编码而创建的。

当App Store验证收据时，  将从其中解码出数据，并以"receipt"的键返回。

返回的响应信息是JSON格式，被包含在SKPaymentTransaction的对象中（transactionReceipt属性）。

Server可通过这些值来了解交易的详细信息。 

Apple建议只发送receipt数据到服务器并使用receipt数据验证和获得交易详情。

因为App  Store可验证收据信息，返回信息，保证信息不被篡改，这种方式比同时提交receipt和transaction的数据要安全。

PS：如果用户退款，在recipt字段中会接收到cancel_data字段取消日期对于由Apple客户支持取消的交易，取消的时间和日期。

四、漏单等情况预防与处理方案

1.漏单必须要处理，玩家花RMB购买的东西却丢失了，是绝对不能容忍的。所谓的漏单就是玩家已经正常付费，却没有拿到该拿的道具。

解决：只要购买成功，便将购买记录(receipt等账单信息)保存下来，然后将账单信息传送给我们游戏服务器，游戏服务器获得账单后，和苹果服务器验证，账单有效的话，回馈给游戏服务器处理，游戏服务器处理后，返回给游戏客户端处理，处理完毕，将本地保存的购买记录删除。

2.漏单的检测位置

解决:

2.1 做法1：在任意购买成功之后，顺便检测一次漏单，有漏单数遍处理了。

2.2 做法2：是在游戏登陆的时候检测一次漏单，即循环检测漏单数据，挨个发送给服务器验证处理，直到将所有的漏单处理完毕。这是原因是购买服务器未返回结果而客户端崩溃的情况下，玩家再次登陆，会产生漏单。

3.漏单的版本兼容

漏单要做好版本兼容，eg.玩家购买英雄ID为100的英雄，产生了一次漏单，但是一直未再次登陆游戏，由于版权等原因，这个英雄在后期版本中被删除了，如果玩家这是漏单处理，会在服务器获得一个丢弃的英雄，产生数据异常。

处理是，如果是英雄，检测英雄在本地hero.csv中是否有效，如果有效，检测这个英雄是否已经拥有，如果没有且数据正常，发送给服务器处理漏单，否则丢弃掉这条漏单。

4.服务器和客户端漏单对应顺序

遇到过这种情况，客户端产生了多个漏单，发送给游戏服务器验证，游戏服务器请求苹果服务，苹果服务器返回的receipt的json数据中包含一个所有未处理的订单列表，最后产生的购买数据在最后，客户端的漏单顺序和服务器的验证顺序要保持一致。

五、苹果充值常见的刷单手段和防范方法

1 重复使用receipt-data

这种问题发生的原因是虽然已经用安全的方式检查了receipt-data的有效性，但是没有检查receipt-data的唯一性。苹果验单接口返回的数据格式如下：数据为json格式，其中status值为0表示该receipt有效，但是苹果只负责真假，而不负责检查是否已被使用过。同一个有效的receipt，无论多少次、相隔多少时间去苹果接口验证，都会返回成功。如果只检查了"status":0即发货，则非法用户可以先真实充值一笔，截取到receipt-data后，再多次使用到购买中骗过服务器端验证。防范的方法是在确定status值为0后，进一步解析出数据中的transaction_id并存入数据库。每次发货前先检查数据库中是否已经有本次的transaction_id存在，如果已存在则拒绝发货。还有一种情况需要注意，有些游戏购买前先有一步创建订单的行为，在服务器端记录购买的商品、时间等，且发货时是按照订单记录中的商品，那么需要比较苹果返回信息中的product_id与订单表中的记录值是否一致。

这种问题发生的原因是虽然已经用安全的方式检查了receipt-data的有效性，但是没有检查receipt-data的唯一性。苹果验单接口返回的数据格式如下：

数据为json格式，其中status值为0表示该receipt有效，但是苹果只负责真假，而不负责检查是否已被使用过。同一个有效的receipt，无论多少次、相隔多少时间去苹果接口验证，都会返回成功。如果只检查了"status":0即发货，则非法用户可以先真实充值一笔，截取到receipt-data后，再多次使用到购买中骗过服务器端验证。

防范的方法是在确定status值为0后，进一步解析出数据中的transaction_id并存入数据库。每次发货前先检查数据库中是否已经有本次的transaction_id存在，如果已存在则拒绝发货。

还有一种情况需要注意，有些游戏购买前先有一步创建订单的行为，在服务器端记录购买的商品、时间等，且发货时是按照订单记录中的商品，那么需要比较苹果返回信息中的product_id与订单表中的记录值是否一致。

2 利用信用卡黑卡

这是最常见的刷单手段，是指用户利用无效信用卡，在AppStore中进行消费，由于信用卡已在银行冻结，因此银行不会将款项结算给苹果，苹果自然也不会分成给开发者。

通常的形式是用户去交易网站找代充，代充的商家用绑定了黑卡的AppleID给用户的账号充值，并收取远低于正常价格的金额。也有的代充商户是召集大量的非游戏用户接单，给指定的账号充值后再申请退款，并给这些参与者一定返利来达到“共赢”。

对于这种情况，除了寄望于苹果更严格的审核信用卡信息外，开发者还可以通过监控和分析数据尽可能减小损失。对于最常见的代充形式，我们可以推测：

a. 用户充值时不在自己的常用设备上，而是由商户在自有设备上操作

b. 商户的充值设备可能为多个账号充值

分析用户的常用设备可以通过用户日常的游戏记录，如果只有在充值时会切换到不常用设备上，那么可以判定为可疑用户。如果某些设备只在充值记录中出现，却不属于任何用户的常用设备，那么使用这些设备充值的用户也可以判定为可疑用户。

对可疑用户可以进一步分析，确定后执行扣除非法所得、封停账号等。

3 利用外币卡折扣赚取差价

这是一种需要天时的刷单手段。在一些新兴市场，如墨西哥、土耳其等，苹果有专门的优惠折扣，使用这些货币充值，折扣后的差额即刷单的获利。还有一种情况是利用汇率的变化，如著名的南非币事件。

防范这种手段也很简单，客户端获取用户支付使用的货币类型发给服务器验证，在服务器端建立货币白名单，只允许使用人民币或稳定的国家和地区的货币支付。

4 利用苹果对小额消费不做验证规则的"36技术”（小额消费为40元以下的消费）

这是一种更有技术含量的手段，利用苹果对信用卡的小额消费不做验证的规则，并使用自动注册的虚拟信用卡完成绑卡。用户发起购买后，苹果不确认扣款即返回给客户端成功信息，而此后再进行信用卡扣款时，会出现扣不到钱的情况。 从开发者的角度来看，这笔订单是真实有效的，receipt-data也能通过苹果服务器的验证，但是最终苹果不会对这些账单分账。

相比传统的黑卡，这种方式实现了自动化处理，刷单效率很高，对开发者造成的损失更大。特别是具有交易功能的游戏，刷单者大量充值，然后在游戏内换成货币或道具低价售卖给普通玩家。

对于这种手段，目前开发者能做的就是监控用户的异常充值行为，对于频繁小额充值的用户予以限制。手游中，常见的小额商品就是6元和30元商品，也可以直接限制这些小额商品每用户每日的购买次数，来尽可能减少损失。

（PS：据调研资料整理显示，目前行业没有统一的限制标准，如热血江湖游戏对于小额支付限制是每天6次，而腾讯代理的游戏龙之谷每日限制是3次，故对于小额次数限制规则应根据公司项目情况做自我限制规定）