IOS内购支付server验证模式

IOS 内购支付两种模式：

• 内置模式

• server模式

内置模式的流程：

1. app从app store 获取产品信息

2. 用户选择须要购买的产品

3. app发送支付请求到app store

4. app store 处理支付请求。并返回transaction信息

5. app将购买的内容展示给用户

server模式的流程:

1. app从server获取产品标识列表

2. app从app store 获取产品信息

3. 用户选择须要购买的产品

4. app 发送 支付请求到app store

5. app store 处理支付请求，返回transaction信息

6. app 将transaction receipt 发送到server

7. server收到收据后发送到app stroe验证收据的有效性

8. app store 返回收据的验证结果

9. 依据app store 返回的结果决定用户是否购买成功

上述两种模式的不同之处主要在于：交易的收据验证。内建模式没有专门去验证交易收据，而server模式会使用独立的server去验证交易收据。

内建模式简单快捷，但easy被破解。server模式流程相对复杂，但相对安全。

---

开发之初，苹果方就非常负责的告知:我们的server不稳定。真正开发之后。发现苹果方果然是非常负责的，不仅是不稳定，并且足够慢。app store server验证一个收据须要3-6s时间。

1. 用户是否能忍受3-6s的等待时间

2. 假设app store server 宕机，怎样确保成功付费的用户可以得到正常服务。

对于第一个问题，我们有理由相信用户全然无法忍受，所以採用异步验证的方式，server收到client的请求后，就将请求放到MCQ中去处理。

对于第二个问题，因为苹果人员非常负责人的告知：我们的server不稳定。所以不排除收据验证超时的情况。对于验证超时的收据，保存到数据库中并标记为验证超时。定时任务每隔一定的时间去app store验证，确保可以获取收据的验证结果。

在开发过程中，须要測试应用是否可以正常的进行支付。可是又不能进行实际的支付，因此须要使用苹果提供的sandbox Store測试。

Store Kit不能在iOS模拟器中使用。測试Store必须在真机上进行。

在sandbox中验证receipt:

https://sandbox.itunes.apple.com/verifyReceipt

在生产环境中验证receipt:

https://buy.itunes.apple.com/verifyReceipt

在实际开发过程中，server端通过issandbox字段标识client传递的收据是沙盒环境中的收据还是生产环境中的收据。

在提交苹果审核前。沙盒測试均无问题。提交苹果审核后。被告知购买失败，审核未通过。通过查询日志发现，client发送的交易收据为沙盒收据，可是issandbox字段却标识为生产环境。

结论：

苹果审核app时，仍然在沙盒环境下測试。可是client同事在app提交苹果审核时。将issandbox字段写死。设置为生产环境。这样就导致沙盒收据发送到https://buy.itunes.apple.com/verifyReceipt去验证。

那么怎样自己主动的识别收据是否是sandbox receipt呢？

识别沙盒环境下收据的方法有两种：

1.依据收据字段 environment = sandbox。

2.依据收据验证接口返回的状态码,假设status=21007。则表示当前的收据为沙盒环境下收据， t进行验证。

苹果反馈的状态码。

• 21000App Store无法读取你提供的JSON数据
• 21002 收据数据不符合格式
• 21003 收据无法被验证
• 21004 你提供的共享密钥和账户的共享密钥不一致
• 21005 收据server当前不可用
• 21006 收据是有效的，但订阅服务已经过期。

  当收到这个信息时，解码后的收据信息也包括在返回内容中

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

先生产验证后測试验证，可以避免来回切换接口的麻烦。

測试验证仅仅要用你自己申请的測试appid的时候才会用到，用户不会拥有測试appid，所以不会走到測试验证这一步。

即使生产验证出错，应该也不回返回21007状态吗。測试验证通过的username，和充值金额最好用数据库记录下来，方便公司资金核对。