使用 deviceID、orderID、PurchaseToken 来验证服务器上的购买是否足够？

Question

在过去的几天里，我一直在设置应用计费，并试图以正确的方式解决它。指南建议使用安全的后端服务器来存储购买令牌，而不是在本地存储数据。在服务器上验证购买的文档非常薄，我不确定我是否走对了。

我正在使用云火商店来存储标题中提到的购买信息。我有几个问题：

我应该从服务器读取我的产品 ID，而不是在 apk 中硬编码吗？

在这种情况下，我/我需要多久读取一次设备 ID 并在数据库中搜索以确保用户进行了有效购买？只是购买时的一次还是间歇性的？

如果我要这样做，当买家更换手机时会发生什么？设备 ID 会有所不同，我不会有他们新设备成功购买的记录。或者在这里我查询一个 skupurchase 并返回该项目已经拥有，将这些新的详细信息写入数据库？

最后我是否应该在共享偏好中存储一个成功的购买标志或其他东西，这样我就不会经常阅读数据库并且用户可以离线使用设备？

我打算使用此答案here 获取用户电子邮件，但有很多 cmets 说这是非常侵入性的，我只需要它来做一件简单的事情。所以我去了设备ID路线。

顺便说一句，我只有一种产品可以解锁全部功能并且是非消耗品。

解决这个问题的正确方法是什么？

Answer 1

这是我解决相同问题的方法。它可能与您的场景无关。希望对您有所帮助。

我是否应该从服务器读取我的产品 ID 而不是拥有它 在 apk 中硬编码？

您应该将 productID 存储在代码中，因为它们将用于提供编码到应用程序中的功能。

我应该/我需要多久读取一次设备 ID？

您不应该依赖设备 ID，因为您提出了有关用户更换手机的担忧。您可能希望在购买产品之前实现登录系统并让用户登录到应用程序。这将使您的订阅设备独立。

流程应该是：

1. 用户尝试使用锁定功能。
2. 应用程序要求登录。让用户注册并登录。
3. 用户再次点击购买按钮，完成购买。
4. 您的服务器将用户登录信息与购买信息一起存储。
5. 用户更改设备。
6. 用户尝试使用锁定功能。
7. 应用程序要求登录。用户登录。
8. 服务器返回带有用户信息的购买详细信息。
9. 应用解锁了该功能。

我应该多久从服务器查看一次购买详情？

您应该不时检查购买详情。

为什么？用户可能会在一段时间后要求退款，否则支付网关会因某种原因使购买无效。

IMO，应该有两种类型的同步方法静默和强制。 在我的方法中，静默同步将每 9 天检查一次互联网。如果互联网不可用，它不会做任何事情。而强制同步将从上次同步后每 25 天检查一次互联网。如果互联网不可用，它会要求用户打开它，否则，用户将无法使用该应用程序。

我使用的是 1 个月的订阅期，但由于您拥有的是非消耗性产品，因此您可以承受 2-4 个月的强制同步期。

我应该将成功购买标志存储在共享偏好中还是 所以我不会经常阅读数据库并且用户可以使用 设备离线？

同步过程和登录可以解决这个问题。

我认为您可能不愿意为这么小的东西实施登录系统，并认为它会减少购买您产品的用户。但通过实施 Google 身份验证，速度会更快，用户也不会因此而感到沮丧。

实现此方法涉及大量服务器端逻辑。