自开始以来,我们一直很高兴在iOS应用中处理应用内购买。因为代码已经存在了一段时间,所以当Store Kit调用transactionReceipt方法时,它在我们获得的事务上使用了现在不建议使用的paymentQueue:updatedTransactions:属性。我们将该收据发送到我们的服务器,该收据通过发布到Apple服务器的邮件进行验证,在服务器上完成我们需要做的事情,然后将“成功”报告给我们的应用程序。效果很好。

现在,我们要添加一个基于订阅的产品,因此我正在考虑必须使用主捆绑包上的appStoreReceiptURL属性重新实现IAP,然后从那里加载我的应用收据。有几件事我不明白。

首先也是最明显的:调用SKPaymentTransactionStatePurchased时,我会得到相同的paymentQueue:updatedTransactions:状态。现在,当我将其提交给Apple时,我只是显示返回的JSON。由于状态为非零,因此我也要提交到沙盒服务器并显示我从中得到的信息。问题是在两种情况下我都得到这个:

{"status":21002, "exception":"com.apple.jingle.mzfairplay.validators.DrmInvalidArgumentException"}

我怀疑这与我正在运行调试版本有关,尽管不是在sim卡中运行,而是在实际设备上运行。为了解决这个问题,我尝试将内部版本上传到App Store,以便可以通过TestFlight下载,但是由于使用的是我的沙箱Apple ID,TestFlight拒绝安装它。

因此,第一个问题是为什么我会收到此“ DrmInvalidArgumentException”,并且我已正确配置为进行测试(在真实设备上调试构建,使用我的沙盒Apple ID进行购买)。

第二个问题令我更加困惑。据我了解,我仍然会通过paymentQueue:updatedTransactions收到通知,并且我将迭代到达那里的交易(?),但不是在交易中提交收据,而是从URL中的提交应用收据。主捆绑包。它将包含有史以来的所有IAP购买,并且我将不得不遍历所有这些以找出新内容和我感兴趣的内容,对吗?

流程似乎不正确。我收到基于交易的通知,但随后查看了应用收据中包含的所有IAP交易的转储。所以我不可能正确地理解流程。

最佳答案

状态21002为The data in the receipt-data property was malformed or missing.。验证端点的POST主体必须是JSON字典,其中包含receipt-data密钥和password密钥,其中包含可以从iTunes Connect获取的应用程序特定的共享机密。

您可以尝试使用this tool测试收据。您无需使用TestFlight,只要您使用可以在iTunes Connect中创建的Sandbox iTunes帐户,一切就可以在调试版本上正常运行。

您的解释是正确的,您将希望将每笔购买的交易的完整收据发送出去。这是多余的,您可以保留应用程序端缓存,这样就不必每次都发送相同的收据数据,但是appStoreReceiptURL的内容可能随时更改。

还有许多其他棘手的案例实现订阅。我创建RevenueCat的原因是订阅时所有这些糟糕的事情。我认为,Apple确实很难将其固定在现有的IAP上。

10-07 19:40
查看更多