对接业务流程

1、用户进入业务端的选择商品页面，选择商品下单

2、在业务端根据商品下单，业务端调用【生成签名API】生成签名，业务端将业务订单信息、参与签名的信息以及签名返回给前端，展示给用户订单信息，让用户选择支付方式

3、用户选择支付方式

4、业务客户端调用【iOS-APPSDK】【Android-APPSDK】

5、【APPSDK】会请求支付平台，获取跳转的支付页面信息

6、支付平台服务端返回支付相关信息给【APPSDK】

7、【APPSDK】唤起第三方SDK

8、用户支付

9、第三方SDK回调【APPSDK】支付结果

10、【APPSDK】将支付结果回调给业务客户端

10、如果用户支付成功，支付平台通过【支付成功IDP】通知业务服务端，最终支付状态以支付平台服务单支付流水为准

11、业务服务端可以通过【APP支付】查询支付

2.H5支付

支付流程图

业务流程说明：

1、用户进入业务端的选择商品页面，选择商品下单

2、在业务端根据商品下单，业务端调用【生成签名API】生成签名

3、支付平台将签名字段返回给业务端

4、业务端将业务订单信息、参与签名的信息以及签名返回给前端，展示给用户订单信息，让用户选择支付方式

5、用户选择完支付方式，前端调用【H5支付SDK】

6、SDK会请求支付平台，获取跳转的支付页面信息

7、支付平台重定向至第三方H5支付页面

8、展示给用户第三方H5支付页面，用户操作便可支付

9、用户支付

10、如果用户支付成功，支付平台通过【支付成功IDP】通知业务端

3.PC支付

业务流程说明：

1、用户进入业务端的选择商品页面，选择商品下单

2、在业务端根据商品下单，业务端调用【生成签名API】 生成签名

3、支付平台将签名字段返回给业务端

4、业务端将业务订单信息、参与签名的信息以及签名返回给前端，展示给用户订单信息，让用户选择支付方式

5、用户选择完支付方式，前端调用【PCSDK】

6、PCSDK会请求支付平台，获取跳转的支付页面信息

7、支付平台重定向至PC支付页面

8、用户通过扫描支付页面的二维码进行支付

9、如果用户支付成功，支付平台通过【支付成功IDP】通知业务端

4.微信小程序支付

支付流程图

业务流程说明：

1、用户进入业务端的选择商品页面，选择商品下单

2、在业务端根据商品下单，业务端调用【生成签名API】生成签名，生成签名时候_returnUrl传null即可

3、支付平台将签名字段返回给业务端

4-5、业务端将业务订单信息、参与签名的信息以及签名返回给前端，前端检测openId是否存在，如果存在，直接调用【微信小程序支付SDK】；如果openId不存在，前端可以通过自己的方式获取openId，也可以通过【支付SDK】获取openId

6、前端使用业务端返回的信息以及openId调用【微信小程序支付SDK】

7、【微信小程序支付SDK】会请求支付平台获取支付需要的数据，

8、唤起微信支付，展示给用户微信付款页面

9、用户支付

10、如果用户支付成功，支付平台通过【支付成功IDP】通知业务端

以下为外部文档

二、iOS内购支付详解

内购流程图

二、重点总结:

1.获取内购列表（从App内读取或从自己服务器读取）

2.App Store请求可用的内购列表

3.向用户展示内购列表

4.用户选择了内购列表，再发个购买请求，收到购买完成的回调（购买完成后会把钱打给申请内购的银行卡内）

5.购买流程结束后, 向服务器发起验证凭证以及支付结果的请求

6.自己的服务器将支付结果信息返回给前端并发放虚拟产品

7.服务端的工作比较简单，分如下几步：

7.1.接收ios端发过来的购买凭证。

7.2.判断凭证是否已经存在或验证过，然后存储该凭证。

7.3.将该凭证发送到苹果的服务器验证，并将验证结果返回给客户端。

7.4.如果需要，修改用户相应的会员权限。

7.5.考虑到网络异常情况，服务器的验证应该是一个可恢复的队列，如果网络失败了，应该进行重试。

简单来说就是将该购买凭证用Base64编码，然后POST给苹果的验证服务器，苹果将验证结果以JSON形式返回。

三、使用注意事项及遇到的坑

1、使用注意事项

1.代码中的_currentProId所填写的是你的购买项目的的ID，这个和第二步创建的内购的productID要一致，产品id与_currentProId一致。

2.在监听购买结果后，一定要调用[[SKPaymentQueue defaultQueue] finishTransaction:tran];来允许你从支付队列中移除交易。

3.真机测试的时候，一定要退出原来的账号(app store 登录的账号退出)，才能用沙盒测试账号。

4.请务必使用真机来测试，一切以真机为准。

5.项目的Bundle identifier需要与您申请AppID时填写的bundleID一致，不然会无法请求到商品信息。

6.沙盒环境测试appStore内购流程的时候，请使用没越狱的设备。

7.二次验证，请注意区分宏， 测试用沙盒验证，App Store审核的时候也使用的是沙盒购买，所以验证购买凭证的时候需要判断返回Status Code决定是否去沙盒进行二次验证，为了线上用户的使用，验证的顺序肯定是先验证正式环境，此时若返回值为21007，就需要去沙盒二次验证，因为此购买的是在沙盒进行的。

8.货币类型(Bank Account Currency) :填CNY(如果你的app在中国使用的话)。

2、获取不到商品信息

1.确定配置环节正确。

2.确定是真机测试且手机没有越狱。

3.确定内购商品添加到了需要内购功能的App中。

4.确定当前运行的App的Bundle ID和后台配置的App的Bundle ID是一致的。

5.可以尝试先删除旧App，再重新编译生成新的，避免新App未覆盖错误。

6.这里要提一点，沙盒的测试账号和你请求商品信息没有关系。请求商品信息的流程是，你在后台配置好了内购商品，并且将其添加到了需要集成内购功能的App中，然后你请求商品。请求到商品后的流程是这样的，苹果系统会自动弹出登录框让你登录账号。然后根据提示操作进行购买，这里的账号就是你配置的沙盒测试账号。

四、为什么要使用内购和内购是什么

1.如果你购买的商品，是在本app中使用和消耗的，就一定要用内购，否则会被拒绝上线，例如：游戏币，在线书籍

app中使用的道具等。本例中，就是直播中你用来打赏用的金币，那东西可就属于消耗型的。

2.如果是直接购买商城之类的快递包邮的那些东东，那就直接调用支付宝，微信啦，之类的三方支付就好了，淘宝，京东都玩过哈！

比较坑的一点就是，内购的话，还要和苹果3/7分成，那就可以说，充值相同的钱，相对来说，iOS是比安卓亏的！

有游戏厂商在产品中暗自嵌入第三方支付系统，试图绕过苹果支付，以避免分成。这其实并不是一件新鲜事，在业内早有发生，甚至被俗称为“切支付”。这些游戏基本都是绕过苹果支付，直接使用微信、支付宝进行充值。而通过对iOS游戏免费榜TOP100的游戏进行排查，我们发现榜单上有超过1/10的游戏都在“切支付”。这当中包括超过4款传奇类手游、2款仙侠手游、2款二次元手游、1款ARPG手游等。

还有一些游戏的“切支付”做得更加隐秘，例如某款二次元风格的产品，在6元、30元、50元、98元、198元、328元、488元、648元这几档充值金额中，部分遵循的是苹果IAP模式，不过有的高价位的则是绕过苹果支付，另外通过微信、支付宝充值，将钱全部放入厂商自己的口袋。

TOP100榜单上有超十分之一的游戏在“切支付”，这个比例已经远超我们的想象，而由于切支付本身需要的隐蔽性，使得大多数使用这一打法的产品都不会抛头露面，那么这也意味着，真正在做“切支付”的游戏绝不止十分之一。在暗处玩灰色玩法的不在少数。

二、动苹果的蛋糕于无形之中，这是怎么做到的?

根据苹果的规定，用户想在通过App Store下载的APP里花钱购买虚拟商品，只能通过苹果App Store的支付渠道购买(也就是“应用内购买”in-App Purchase)。目前App Store在中国支持银联、支付宝、微信等支付方式。而通过IAP支付，苹果会向App开发者抽取30%的平台佣金。

那么在玩“切支付”的产品到底是如何实现绕过苹果的呢?据手游那点事了解，目前主要集中在两种方式上。

一种是利用苹果的“热更新”。开发者先在后台上传一个正常的使用苹果IAP支付的安装包，通过审核并成功上线之后，再利用“热更新”的方式，将原本的支付系统换成其他的第三方支付，从而绕开了苹果的审核机制。这是目前大多数游戏在用的一种“切支付”的方法。

热更新不需要通过苹果App Store软件版本更新审核，这也成为了目前绝大多数移动游戏更新的主流方式之一。因为游戏需要时常进行数据更新、BUG修复、大型运营活动等等，这些都需要依靠热更新，而从热更新上“动手脚”，最为方便快捷。

有业内人士告诉笔者：“这在技术层面上一点都不难实现，不只是大公司能做到，就算是小团队也不难完成。”另外也有从业者表示：“切支付除了能多出30%收入之外，还能很好地规避账期，使得现金流运转地更顺畅，这30%的利润对很多发行团队都非常关键。”

另一种则是不在游戏中使用“切支付”的伎俩，而是在游戏外另外开设比较隐蔽的充值通道，例如微信公众号、官网等等，玩家在上面进行充值之后，再在游戏中发放相应的钻石、元宝等。

马甲包是“切支付”规模化的强大支撑

虽然当时已经有不少团队迫不及待想要实施切支付，而且也有了具体的操作方法，但毫无疑问的是，这一做法在当时风险极大，一被查到，前期的买量、ASO、营销推广等大量投入就付诸东流，甚至影响该账号之后在App Store上的游戏发布。

但后来，换皮、马甲包等做法出现了，给了切支付强有力的支撑。

通过在iOS平台上发布多个马甲包，并对当中的部分马甲包进行切支付的处理，同时这些游戏包通常不会做榜单排名类的推广，不会引起太多关注。而且多个马甲包能分散用户和降低风险，即便最终真的被苹果发现了，也就牺牲其中一个马甲包，能将损失降到最低。

马甲包的出现让切支付开始有了规模化的可能，后来甚至衍生出两套做法进行搭配。正规的产品，要做榜单的，就不切支付，通过推广把排名冲上去;换皮、马甲包等不做榜单的，则进行“切支付”，省下30%的分成。