I am maintaining and updating the subscription state through the real time developer notification.
When an user purchased a subscription in app, my server is called to link the purchase with the user.
Whenever user repurchases a subscription after expiry, I get a notification from Google pub-sub in my server as a "SUBSCRIPTION_PURCHASED" notification. I just don't know to which user I have to link this purchase? Since the repurchase is happening from the play store and it has no link with the app, I am unable to register the subscription to the user. Kindly please help me.
Just to clarify the different cases, even if I know that's not what you're asking for here :
whenever a subscription expires on the Play Store because of a payment issue, it enters in a grace period (if you havent deactivated this feature). If the payment method is not fixed, the subscription enters into an "account hold" period (30 days) where any payment method resolution or re-subscription will bring back the subscription. In this case, you'll receive a SUBSCRIPTION_RECOVERED S2S notification with the purchaseToken known by your server and everything should work just fine (more on this here: https://developer.android.com/google/play/billing/subscriptions#account-hold)
in your case, the user has re-purchased the subscription in another context than an "account hold", that's why you'll have an unknown purchaseToken and you won't be able to associate the subscription with any user. I'm afraid in this case, you can't do much.
The only solution for your user is to "restore" his subscription within your app. In another words, you should add a link in your Paywall which, when clicked, will retrieve the subscription from the Play Store and send them back to your server (like for a normal purchase). Your server will detect the new subscription and will linked the subscription to the correct user.
Here is an example of a Paywall with this restore link:
You could thought that it would be a good idea to always look in the Play Store for subscriptions when your app launch... and whenever your detect a subscription that isn't attached to your user, send the receipt to your server to attach the subscription to your user. It would be an error though since a same device can be used by 2 persons and one user would "steal" the subscription from the other.
Related
After read all documentation and examples, I still have open questions regarding user charge process:
Do Google Play Market send any callback to client after every successful charge with appropriate order id and other billing details?
Is it possible to configure subscription with only one trial period?
(If user will cancel subscription and then subscribe again for the
same sku, we don't want to give him trial again)
Thanks in advance
I am developing an app with android in-app subscription purchase with a self login procedure, basically which means multiple user can use single device to access app. Everything works fine as long as i use a single user in my app, but as i logout and login another user and try to do a subscription purchase it either tells me you already have this subscription or changes my subscription to new requested subscription.
This happens because previous user had a subscription which is reflecting in this user, as subscriptions/purchases are associated with the primary play store account.
So How can i manage this situation with multiple user each with a same or different subscription on a single device? Is it possible ?
Thanks in advance for help.
I have gone through most of the links here on stackoverflow and i have some doubts regarding InApp Subscriptions and Google Wallet.
What i know:
InApp Subscriptions basically allows a user to be able to subscribe to an app, say for example if it offers one year trial period, then once thats over, Google automatically handles the subscriptions then after.
Google Wallet, its a method that can be used to perform the purchase. What i don't understand is, can i use this method in order to allow users to use the app for one year, and then make them pay for the next years?
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.)
This is what happens in my app:
1. A user logs in, and i get a date that probably keeps track of the billing cycle
2. If the sessions expired, the user is asked to pay using the inApp Billing serivce
3. Based on TrivailDriveApp Example, where we have the success log printed on subscription, we update the date of payment.
Some questions i have:
As per the quote from android, if the user is automatically subscribed to the service, and if a mail is sent to the user, does that mean that i would never be able to get a notification about the payment extension? How do i sync that with the server then?
Is my approach wrong in handling this kind of scenario? Or do i have to select a different method of handling app extensions?
P.S: There is no way of testing inapp subscriptions also. I wonder if i could do that without using real credit/debit card credentials.
EDIT:
I would also want to keep track of when the purchase or billing was done, if subscriptions are auto-renewed, then should i take up the purchase flow as an InApp Product instead of an InApp Subscription?
Please help.
How do I implement (Auto-renewable) Subscriptions for an Android App.
I've read the documentation
and as far as I understand, the process is the following:
User subscribes to such a subscriptions on the app. This will generate a Purchase token.
The app sends this token to the server along with something to identify this user
The server will store this Purchase token with this user and will mark the subscription as valid
the server validates this Purchase token via the http-api periodically (typically once per day) with something like a cronjob
if the subscription isn't valid anymore, the subscription will be marked as invalid on the server-side.
If the app makes requests to the server to resources that need the subscription, the client will send this user-identity-string along with the requests. We then check in the database, if the subscription of this user is still marked as valid.
My question is now, how we should identify this users? Do we have a simple user id available that we can share between our app and our server? or should we use something different? What is the best practice here?
We did already similar subscriptions on ios and we used the uuid of the device to identify the users (at least as long as we were able to use the uuid).
From the Answer below we should generate a unique ID. This would be unique per device (or per app-installation). But if a user changes his device or reinstalls the application this id would not be the same anymore. So I'm not sure, how the process is in this use case. I thought of something like this:
The user is logged in with the same google play account on his second device.
As the app starts (or becomes active) we would fetch the users subscriptions
We then would receive this purchase token from the subscriptions and send them along with the new unique-ID to our backend-server as if the user had made a new subscription.
Would this be the right process? And stays the purchase token the same as it was on the first device?
Ok, my question about identifiying users is answered, the link provided delivers enough informations. I'll put further questions in new threads on SO, if I have some.
This link maybe helpful to you as you want to identify the users uniquely.Please note that the personal information of a user rests with Google only.And you should avoid getting private information of a user.
http://www.pocketmagic.net/2011/02/android-unique-device-id/#.URIe_B3Wgr7
I can't test this myself, because there is no way to completely terminate subscription, apparently.
So, I want to test the following use case: user buys subscription, cancel's it (or it expires), than user buys same subscription.
What will I get with RESTORE_TRANSACTIONS response? Will I get two items with same item id, different purchase tokens and different state? Or purchaseToken will remain the same? I'm afraid that there will be only one subscription with different order ID and purchase token, and the information on previous subscriptions will be lost, but I can't confirm it right now. Also, will orderId be changed with every recurring purchase inside a subscription?
Why I need this - subscription will supply user with new content daily, so when user cancel subscription (subscription A) and later buys a new one (subscription B) I need to show to user content released during time-frame of subscription A,and content in a time-frame of subscription B, but not the content released in period used didn't had active subscription.
Note: You should use the RESTORE_TRANSACTIONS request type only when your application is installed for the first time on a device or when your application has been removed from a device and reinstalled.
Using RESTORE_TRANSACTIONS on a regular basis is not recommended because of performance impacts.
Taken right from Android Developers http://developer.android.com/guide/google/play/billing/billing_overview.html
Although I do understand your concern for the Subscription Billing. Google is pretty good about their API and how you should interact with purchases.
When you send a RESTORE_TRANSACTIONS request you will get two broadcast back. A RESPONSE_CODE and a PURCHASE_STATE_CHANGED. Here's the table from Google stating the different values you could receive.
Coming back to your question about buying two subscriptions: you should check to see if the user has bought a subscription with the GET_PURCHASE_INFORMATION request, if the Subscription is in the list check the Purchase State of the Subscription to see if you should continue with the purchase.
As for what you would get if you "Could" buy two of the same subscriptions, its (I want to say impossible) unlikely... But you will get two order transactions.
As long as you're always aware of the user transactions on your part, Google's API will do the rest. Good luck!