11

I'm researching method to implement auto renew subscription in app billing with google play. I read https://developer.android.com/google/play/billing/billing_subscriptions.html and see

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.

So have any method to my server know when user's subscription was renewed? Instead of google play send new bill subscription to android app after that android app send this new bill to my server just for validate.

Can google play send a notify to my server when user's subscription renewed such as notify the user by email ? I want to google play send me a notify that user's subscription was renewed automatically so that my backend will update expire their subscription in app increase. Don't need android app have to check bill each time user open store to check have new bill from goole play charge automation or not. Do it implement?

My workfollow

  1. Google charge a new cycle subscription and notify to my server { body such as bundId, bill, product_id or subscription package name, expire date...), also sent mail to user about their subscription automation renewed.
  2. My server determine change subscription of the user and validate in app purchase by google play api and change expire package subscription in your app if validate is valid.
  3. Store newest bill in my db

Is that possible?

[Update] Recommend from goolge play api doc

Recommendation: Include business logic in your app to notify your backend servers of subscription purchases, tokens, and any billing errors that may occur. Your backend servers can use the server-side API to query and update your records and follow up with customers directly, if needed.

How to implement recommend from google api, any doc or tutorials ?

Community
  • 1
  • 1
Loint
  • 3,560
  • 7
  • 26
  • 46

3 Answers3

9

I have currently exactly the same problem. The concept of Google is not well-conceived. There is a possibility to notify your backend server about financial transactions (see here), but I would not recommend this. You rely your business transactions on a lot of Google services and your server uptime. If anything goes wrong or is down or something, you will not be informed and your backend business logic does not work anymore.

This recommendation of Google you mentioned sucks as well. What happens if there is an auto-renawal (which delivers a new purchaseToken to your app) and the user never opens your app. Then the new subscription data will never be transferred to your server. And if you never got a new token, how can you check, if the user is still a subscriber, since this limited Google Play Developer API stupidly needs a purchaseToken as parameter (see here) that you never get as long as the user does not open your app at least once after an auto-renewal (to submit it to your server).

I think about implementing this in this way:
1.) I continuously check the purchase records by cron job. A purchase record is a database entry which contains all data from the initial subscription (orderId, purchaseToken, and so on, all that is needed for the security validation process on the server). Every purchase record is connected to a user's account (some UserID) in my backend system. As long as the autoRenewing attribute of the purchaseRecord is not false, the subscription is valid. Even if the expiryTimeMillis is exceeded, this one user could still have a valid subscription, because of the use case I described above: Subscription will be auto-renewed by Google, but the user never opens the app, so no transfer token is sent to your server and you are still not informed about the subscription update.

2.) If the use cancels his subscription any when, the autoRenewing would be false at any time. That means that the subscription will indeed end at the expiryTimeMillis.

3.) When the user opens your app and transfers the new purchaseToken to your backend, you will get a new purchase record which is again connected to the user account with his User ID. The user will probably have 2 purchase records now. The old one and the new one. If so, you could delete the old one, and the same process repeats with the new purchase record at step 1.

I didn't have implemented the concept so far, so I don't know if this really works like this. Maybe this could work in a different manner, but maybe it's a step into the right direction.

Bevor
  • 8,396
  • 15
  • 77
  • 141
  • yep!. This is exactly that i'm doing. I created a cronjob task to renew for user sub. I contacted with google play service support team, they said that they don't support a hook to notification when a subscription renewable. – Loint Nov 19 '17 at 11:43
  • 4
    my understanding is that auto renewals do NOT deliver a new purchaseToken. Querying the subscription with the orginal token should always give the current state: https://developers.google.com/android-publisher/api-ref/purchases/subscriptions – svn Mar 07 '18 at 09:56
  • @svn Obivously there is at least one case where you get a new token, so you can't rely on that: https://developer.android.com/google/play/billing/billing_subscriptions.html `It's possible, however, that the user regained access to the subscribed content by repurchasing the subscription during the hold period. In that case, a new purchaseToken value is returned to represent the new instance of the subscription.` (I implemented my backend logic to cover hopefully all these Google inconsistencies and soon I will test it.) – Bevor Mar 07 '18 at 10:09
  • The repurchase would be done through the regular process in the app and registered as a new subscription. You would have the new token in this case. This means you should not disable a users subscription based on only the status of the orginal purchase and its renewals. Either replace the token when the new subsciption occers or maintain both tokens and check if any are valid on the server sider – svn Mar 07 '18 at 11:10
  • @svn I decided to save as much as possible and will not delete anything (as I proposed b4). Since all the Google API descriptions mostly suck, one never knows what kind of information you will loose if you start to delete anything. – Bevor Mar 07 '18 at 17:42
1

I don't think, relying upon daily basis cronjob is a feasible way to go about this problem, It is messy and you have to also consider the case when your application is handling too many requests, you have a limit of transactions that made using android developer's api. The better way to implement it would be to use google's recommendation. Which stats:

... Note: Due to quota restrictions, it is not recommended to check state by polling the Google Play Developer API at regular intervals instead of leveraging Real-time developer notifications. ...

Mridul
  • 45
  • 6
0

Here, You can follow the following url How to get expiry date for Subscription with client side in Android? and to implement the auto-renewal subscription.

Sakthivel Appavu
  • 565
  • 5
  • 24