in-app-billing - 如何在应用计费谷歌播放中实现自动续订订阅

Question

我正在研究使用 google play 在应用计费中实现自动续订订阅的方法。我读了 https://developer.android.com/google/play/billing/billing_subscriptions.html看看

Billing continues indefinitely at the interval and price specified for the subscription. At each subscription renewal, Google Play charges the user account automatically, then notifies the user of the charges afterward by email. For monthly and annual subscriptions, billing cycles will always match subscription cycles, based on the purchase date. (Seasonal subscriptions are charged annually, on the first day of the season.)

When the subscription payment is approved, Google Play provides a purchase token back to the purchasing app through the In-app Billing API. Your apps can store the token locally or pass it to your backend servers, which can then use it to validate or cancel the subscription remotely using the Google Play Developer API.

那么有什么方法可以让我的服务器知道用户的订阅何时更新？在 android 应用程序将此新账单发送到我的服务器仅用于验证之后，而不是 google play 向 android 应用程序发送新的账单订阅。
google play 可以在用户续订时向我的服务器发送通知，例如通过电子邮件通知用户吗？我想 google play 向我发送一个通知，通知我用户的订阅已自动续订，以便我的后端将更新过期他们在应用程序增加中的订阅。不需要Android应用程序必须在每次用户打开商店时检查帐单以检查是否有来自goole play收费自动化的新帐单。执行了吗？
我的工作人员

谷歌收取新的周期订阅费用并通知我的服务器{主体如bundId、bill、product_id或订阅包名称、到期日期...)，还向用户发送了关于他们订阅自动化更新的邮件。

我的服务器确定用户的更改订阅并通过 google play api 在应用程序购买中进行验证，如果验证有效，则更改您的应用程序中的过期包订阅。

在我的数据库中存储最新账单

那可能吗？
[更新] 从goolge play api doc推荐

Recommendation: Include business logic in your app to notify yourbackend servers of subscription purchases, tokens, and any billingerrors that may occur. Your backend servers can use the server-sideAPI to query and update your records and follow up with customersdirectly, if needed.

如何实现来自 google api、任何文档或教程的推荐？

Answer 1

我目前有完全相同的问题。谷歌的概念并不完善。有可能通知您的后端服务器有关金融交易的信息(请参阅 here )，但我不建议这样做。您的业​​务交易依赖于许多 Google 服务和您的服务器正常运行时间。如果出现任何问题或出现故障或其他问题，您将不会收到通知，并且您的后端业务逻辑将不再起作用。

你提到的谷歌推荐也很糟糕。如果存在自动更新(向您的应用程序提供新的购买 token )并且用户从未打开您的应用程序，会发生什么情况。那么新的订阅数据将永远不会传输到您的服务器。如果您从未获得过新 token ，您如何检查用户是否仍然是订阅者，因为这个受限的 Google Play Developer API 愚蠢地需要一个 purchaseToken 作为参数(请参阅 here )，而您永远不会像用户一样获得该 token 自动续订后至少不会打开您的应用程序(将其提交到您的服务器)。

我想以这种方式实现这一点:
1.) 我通过 cron 作业不断检查购买记录。购买记录是一个数据库条目，其中包含来自初始订阅的所有数据(orderId、purchaseToken 等，所有这些都是 security validation process on the server 所需的)。每个购买记录都连接到我后端系统中的用户帐户(某些用户 ID)。只要自动续订 purchaseRecord 的属性不为 false，订阅有效。即使到期时间Millis 超出，这个用户仍然可以有一个有效的订阅，因为我上面描述的用例:订阅将由谷歌自动续订，但用户从未打开应用程序，因此不会将传输 token 发送到您的服务器，您仍然没有被告知订阅更新。

2.) 如果用户在任何时候取消订阅，自动续订 随时都会是假的。这意味着订阅确实会在 结束。到期时间Millis .

3.) 当用户打开您的应用程序并将新的purchaseToken 转移到您的后端时，您将获得一个新的购买记录，该记录再次连接到具有他的用户ID 的用户帐户。用户现在可能有 2 条购买记录。旧的和新的。如果是这样，您可以删除旧的，并在步骤 1 中对新的购买记录重复相同的过程。

到目前为止我还没有实现这个概念，所以我不知道这是否真的像这样。也许这可以以不同的方式运作，但也许这是朝着正确方向迈出的一步。