苹果充值常见的刷单手段和防范方法
1 重复使用receipt-data
这种问题发生的原因是虽然已经用安全的方式检查了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次，故对于小额次数限制规则应根据公司项目情况做自我限制规定）
针对以上刷单情况有以下技术点以及需要注意的点，做风控防刷机制（异常、黑名单机制）:
异常名单、黑名单等机制应有一定的等级序列（名单等级要有区分，比如涉及金额大小以及行为异常等做出明确的限制划分）
1.判断用户的常规登录Ip地址 和 充值时的ip地址，判断是否有异地刷单风险
例：用户常规登录IP地址-厦门、充值地址广州、长沙等且多次充值在不同地点则列入异常监控列表，对用户行为做监控。当监控到异常行为过多的情况下，加入到黑名单中。
2.针对小额支付（36技术）做防范机制，限制每日小额支付的次数以及针对多次充值小额的用户进行行为监控。
例：用户在三天（或一个星期，时间由app自主规划）内一直进行充值小额支付到日充值上限等行为，列入异常用户名单进行长期监控，当行为触发黑名单机制后，加入黑名单中。
3.外币折扣刷取(客户端可以限制,建立外币白名单)
例：由服务端提供币种白名单，客户端根据币种白名单进行限制。禁止用非常规币种进行充值
4.取消退款，验证已经通过
payload和transation记录，每隔一段时间重新校验，判断是否有退款日期
由服务端间隔一段时间，遍历服务器中内购订单的验证凭证，排查哪些属于退款用户，进行异常处理（以及采取相应措施，如退还等值虚拟币或者封号）
5.主播是否和用户合作刷单 ， 用户是否被标记异常，虚拟币来源是否异常 （虚拟币一定要能标记来源，可以返本溯源）
判断主播的虚拟币来源，比如主播的虚拟币是由多个异常（黑名单）用户送出的，对相关虚拟币进行提现限制（如走人工提现通道等），建立主播刷单机制（用以防止主播刷单）
