我们很高兴从一开始就在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 PURCHASES EVER，我将不得不迭代所有这些来弄清楚什么是新的和我感兴趣的，对吧？
流程似乎不对。我正在收到基于交易的通知，但随后查看应用收据中包含的所有IAP交易的转储。所以我无法正确理解流程。
答案 0 :(得分：1)
状态21002为The data in the receipt-data property was malformed or missing.。验证端点的POST主体必须是一个JSON dict，其中包含receipt-data密钥和password密钥，其中包含您可以从iTunes Connect获取的特定于应用程序的共享密钥。
您可以尝试使用this tool来测试收据。您不需要使用TestFlight，只要您使用可以在iTunes Connect中创建的Sandbox iTunes帐户，一切都应该在调试版本上正常工作。
您的解释是正确的，您需要为每个购买的交易发送整个收据。这是多余的，您可能会保留应用程序端缓存，因此您不必每次都发送相同的收据数据，但appStoreReceiptURL的内容可能随时更改。
还有许多其他棘手的边缘案例正在实施订阅。我构建了RevenueCat因为订阅所有这些糟糕的事情。在我看来，Apple真的把它用在了现有的IAP上。