• Maintaining linkedPurchaseToken correctly to prevent duplicate Subscriptions
  • Originally written by Emilie Roberts
  • The Nuggets translation Project
  • Permanent link to this article: github.com/xitu/gold-m…
  • Translator: yuwhuawang
  • Proofread by: ZX-Zhu

Are you using Google Play subscriptions? Make sure your back-end services are implemented the right way.

The Subscription REST APIs are a trusty source for managing user subscriptions. The return from the ROBBED. Subscriptions API includes a very important field called linkedPurchaseToken. Proper handling of this field is important to ensure that the right users can access your content.

How does it work?

As the subscription documentation points out, each new Google Play purchase process — initialization purchase, upgrade and downgrade, and re-registration — generates a new purchase token. The linkedPurchaseToken field can be used to identify multiple purchase tokens that belong to the same subscription.

For example, A user purchases A subscription and receives A purchase token A. The linkedPurchaseToken field (gray circle) has no value in the API return because the purchase token belongs to a brand new subscription.

If the user upgrades their subscription, a new purchase token B is generated. Since this upgrade replaces the subscription represented by buying token A, token B’s linkedPurchaseToken field (shown in gray circles) will point to token A. Notice that it points to the original purchase token in reverse chronological order.

Purchase token B will be the only token to be updated. Purchase token A should not be used to authorize users to access your content.

Note: Purchase tokens A and B will both be active if you query Google Play’s order server when renewing your subscription. We’ll talk about this in the next section.

Now, let’s assume that another user performs the following actions: subscribe, upgrade, and downgrade. The original subscription creates purchase token C, the upgrade creates purchase token D, and the downgrade creates purchase token E. Each token points to the previous token in reverse chronological order.

Let’s add a third user to this example. This user keeps changing his mind. After initializing the subscription, the user unsubscribes three more times and then re-subscribes (re-subscribes). The initial subscription creates the purchase token F, and the re-subscription creates G, H, and I. Purchase token I is the most recent token.

The most recent tokens B, E, and I represent the final authorization and paid subscription for users 1, 2, and 3, respectively. Only the most recent tokens have corresponding rights. For Google Play, however, all tokens are “valid” if the initial expiration date has not been reached.

That is, if you query these tokens by retrieving the subscription API, including A, D, F, G, and H in the diagram above, you will get the subscription resource response indicating that the subscription has not expired and the payment has been received, but even then you should only authorize based on the most recent token.

At first glance it seems strange: Why is the original token still valid even after it has been updated? The simple answer is that this gives developers more flexibility in providing content and services, and Google better protects users’ privacy. However, it does require you to focus on recording on the backend server

Operating linkedPurchaseToken

Every time you confirm a subscription, your backend service should check if the linkedPurchaseToken field is set. If set, the value of this field represents the previous token that was replaced. You should immediately invalidate the previous token so that users can’t use it to access your content.

Looking at user 1 in the example above, when the backend server received certificate A representing the initial purchase, the linkedPurchaseToken field of certificate A was empty, authorization should be made based on the certificate. Next, when the back-end server receives the updated new purchase certificate B, the server checks the linkedPurchaseToken field, finds that it is set to token A, and disenforces token A’s authorization.

In this case, the back-end database always holds purchase credentials with valid permissions. In the example of user 3, the database state changes should look like this:

Check the linkedPurchaseToken pseudocode:

You can be in an open source, the application of end-to-end subscription Elegant look at some examples on the backend Firebase of a taxi, especially see disableReplacedSubscription method, it’s in PurchasesManager. Ts.

Clean up the existing database

Your back end should now be in sync with the latest, successive purchase tokens, you check the linkedPurchaseToken field for each purchase, and each token corresponding to the replaced subscription is properly disabled. This is great!

But what if you had a database of existing subscription data and didn’t adjust it according to the linkedPurchaseToken field? You need to run a one-time cleanup algorithm on the database.

In many cases, the most important task of cleaning up a database is whether a token is authorized to the corresponding content and services. That is: there is no need to recreate the upgrade/downgrade/re-subscribe purchase history for each subscription, just to determine the correct authorization for each token. A one-time database cleanup task can clean up the subscription status. Next, new incoming subscriptions need to be processed as described in the previous section.

Imagine that the purchase credentials of all three users are stored in a database. These purchases can occur at any time and in any order. If the cleanup function is handled correctly, tokens B, E, and I will eventually be marked as valid authorization, while the rest of the tokens will be disabled.

Walk through the database once and check each entry. If the linkedPurchaseToken field is set, the fields included in that field are disabled. According to the chart below, we move from top to bottom:

Element A: linkedPurchaseToken is not set, move to the next element D: linkedPurchaseToken == C, disable C element G: linkedPurchaseToken == F, disable F element E: LinkedPurchaseToken == D, disable THE D element F: linkedPurchaseToken was not set, moved to the next item, etc.

Clean up the pseudocode for an existing database:

After a one-time cleanup, all old tokens are disabled and your database is ready.

Something simple but important

Now that you understand how the linkedPurchaseToken field works, make sure you handle it correctly on your back end. Every subscription application should check this field. The right tracking authorization is critical to ensuring that the right user is granted the right rights at the right time.

The resources

  • Google Play Billing Library
  • Subscription upgrades and downgrades
  • Subscriptions API
  • ClassyTaxi Simple application for end-to-end subscription

¹ Re-register is when a user subscribes, then unsubscribes, and then re-subscribes before the original subscription expires. Although the user will not lose the authorization and the new subscription will be the same as the previous one, they will still go through another payment process because they are committed to future payments. They receive a new purchase token and the linkedPurchaseToken field is set at the time of upgrade or downgrade.

All the code in this article followsApache 2.0 license. This article does not include any part of the official Google product and is intended for reference only.

The token image at the beginning of the article was copied from this link. Attribution: Portable Antiquities Project/British Museum Foundation. Creative Commons under the Commons 2.0 license.

Thank you, Cartland, Cartland.

If you find any mistakes in your translation or other areas that need to be improved, you are welcome to the Nuggets Translation Program to revise and PR your translation, and you can also get the corresponding reward points. The permanent link to this article at the beginning of this article is the MarkDown link to this article on GitHub.

The Nuggets Translation Project is a community that translates quality Internet technical articles from English sharing articles on nuggets. The content covers Android, iOS, front-end, back-end, blockchain, products, design, artificial intelligence and other fields. If you want to see more high-quality translation, please continue to pay attention to the Translation plan of Digging Gold, the official Weibo, Zhihu column.