【问题标题】:Google InApp restore transaction response for subscriptionsGoogle InApp 恢复订阅的交易响应
【发布时间】:2012-09-24 15:11:39
【问题描述】:

我已实施 Google 应用内结算。我添加了一个月的订阅产品。 假设我在 2012 年 7 月购买了这个产品,之后在月底我取消了这个订阅。 9 月再次购买了这一个月的订阅。我创建了这个用例来清除我的用例。

这里我想知道,当您在 9 月份进行恢复交易时,整个响应是如何以 json 格式发送给您的。 考虑到您是在 2012 年 7 月订阅的,那么您在 2012 年 8 月取消了订阅,之后又在 2012 年 9 月订阅了。

如果我讨论它,响应的一小部分为我提供了json响应中的两个主要内容,一个是purchaseTime,另一个是purchaseToken。

所以现在的重点是当您在 2012 年 9 月进行恢复交易时,作为每月订阅,您如何管理 2012 年 9 月和 2012 年 7 月的订阅验证。

有人可以解释一下这种情况下的工作方式吗?提前非常感谢。

【问题讨论】:

    标签: in-app-purchase


    【解决方案1】:

    我问了同样的问题here。仍然没有响应,但恐怕在响应 json 中,您只会得到一件带有您的订阅 ID 和更新的购买时间、订单 ID 以及更新的购买令牌的项目。意味着 2012 年 7 月的订阅数据将被覆盖和丢失。我现在无法确认,因为我需要等待将近三周才能再次购买相同的订阅。

    因此,您需要一种方法将以前的订阅存储在某处(在您的服务器上?)并通过用户识别它们(获取用户的 google play 电子邮件?)。

    【讨论】:

    • 您好 Sver 感谢您提供信息想问一下,存储在某个服务器上是什么意思,如果我没有错,那么就像您必须针对 emailID 存储 purchaseTime、purchaseToken、productID已用于购买该产品。你认为还有一件事,除了等待整个月来测试这个场景之外,还有什么方法可以测试这一点。谢谢。
    • @Devavrata 是的。您需要存储 purchaseToken、productID 和用户电子邮件。 purchaseTime 是可选的,因为您可以在检查订阅有效性时查询google API。而且,不,不幸的是,我仍然没有找到一种无需等待即可对其进行测试的方法:(
    • 感谢 Sver :),如果您对此有所了解,请告诉我。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2020-03-15
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2017-04-13
    • 1970-01-01
    相关资源
    最近更新 更多