【问题标题】:iOS in-app purchase transactionReceipt vs. appStoreReceiptURLiOS 应用内购买 transactionReceipt 与 appStoreReceiptURL
【发布时间】:2017-12-01 23:15:56
【问题描述】:

从一开始,我们就一直很乐意在 iOS 应用中处理应用内购买。因为代码已经存在了一段时间,所以当我们的 paymentQueue:updatedTransactions: 方法被 Store Kit 调用时,它在我们得到的事务上使用了现在已弃用的 transactionReceipt 属性。我们将该收据发送到我们的服务器,该服务器通过向 Apple 的服务器发送消息来验证它,执行我们需要在服务器上执行的操作,并将“成功”报告给我们的应用程序。效果很好。

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

首先也是最明显的:当调用paymentQueue:updatedTransactions: 时,我得到相同的SKPaymentTransactionStatePurchased 状态。现在,当我将它提交给 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 交易的转储。所以我不可能正确理解流程。

【问题讨论】:

    标签: ios objective-c in-app-purchase


    【解决方案1】:

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

    您可以尝试使用this tool 来测试您的收据。您不需要使用 TestFlight,只要您使用沙盒 iTunes 帐户(您可以在 iTunes Connect 中创建该帐户),一切都应该在调试版本上正常工作。

    您的解释是正确的,您需要发送每笔购买交易的完整收据。这是多余的,您可能会保留应用程序端缓存,因此您不会每次都发送相同的收据数据,但appStoreReceiptURL 的内容可能随时更改。

    还有许多其他棘手的边缘案例实现订阅。我建立了RevenueCat,因为订阅的所有这些蹩脚的东西。在我看来,Apple 确实很糟糕地将其固定在现有的 IAP 上。

    【讨论】:

    • 我还没有添加我的订阅——我正在使用现有产品进行测试,以验证我可以处理我已经在做的事情。我的印象是,仅当字典包含可自动更新的订阅时才需要密码。
    • 呃。加号。需要对 base64 字符串进行百分比编码。不知道为什么我的其他收据一直正常。我也会再看看 RevenueCat。
    • 啊,是的,这就是我对 URL 内容进行编码的方式:NSString *fetchToken = [data base64EncodedStringWithOptions:0];。如果您想看看我是如何做到的,请使用 RevenueCat 实现 is open source
    • 我将收据作为 URL 字符串的参数发送到服务器,因此加号被解释为空格。仅供参考,当我将 base64 字符串插入您的收入工具进行解码时,我无法滚动右侧的结果 div。在 OS X 上使用 Safari。
    • 我还有一些其他大的 URL 字符串是出于其他原因发送的,所以我不担心长度。由于移动到应用程序收据(我认为它可能会变得很大)而不是个人交易收据,我将不得不改变我发布到服务器的方式。因为我控制了服务器,所以我刚刚增加了查询字符串的最大长度。现在至少是4096。 :-)
    猜你喜欢
    • 1970-01-01
    • 2011-09-17
    • 2015-03-13
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2011-04-21
    • 1970-01-01
    相关资源
    最近更新 更多