I am implementing an app that will have an in-app subscription purchase. The subscription is renewed on a monthly basis. When a user purchases the subscription, they get a free 30 day trial. I understand that I have access to the purchaseDate value from the JSON that is returned, however I have a few questions about this:
When a person's subscription renews, does the purchaseTime / purchaseDate get updated to the date/time of the renewal? Or does it always remain the original purchase date?
I am trying to figure out the best way to cache this locally in the application so as to only have a check using getPurchases a couple of times per month around the time of renewal, are there any good examples or best practices I could follow?
Please don't respond by posting the documentation link. I know where to find that and have read it already :)
The getPurchases() method mentioned here only pulls non-expired purchases. Therefor, if your app notices that a user does not have a purchase (no purchases returned from 'getPurchases()', but they DO have purchase info (has_purchase, purchase_token, etc..) in your app's DB, then you found an expired purchase, so remove all purchase info in the DB for that user.
Hope that helps.
Here is my current guess on this I haven't been able to find a good doc either.
I believe the simple answer is that the purchase date is the original purchase date not the date of the renewal.
In other words if the subscription started on March 1 and you do getPurchases in July the purchase date will still be March 1 even though there have been a few renewals.
You can tell the subscription is active with getPurchaseState() = "0" (Purchased), "1" = Cancelled, "2" = Refunded.
To know the expiration date use the Day of the Month from the Purchase Date and find the next occurence of that Day of the Month. For example if today is July 15th and the getPurchaseState() = "0" then the expiration date must be August 1.
All of the above is a bit of guesswork. I wish I could find a good doc on this too.
Related
I am using google in-app subscription I am able to test the using app store.
Now what I want to achieve is I want to start the subscription at a specific date.
For example, Today is 10th of the month and user subscribe and I want to start the subscription form the 15th of the month.
How should I achieve this?
If the delay is always, for example, 5 days you can set a period of free trial > 3 days in the Google Play Console.
You can defer the billing.
I don't think that you can postpone the subscription , because the subscription start at the user validation. However maybe you can display the subscription popup at a specific date, not sure that is compliant with good practice.
Hope it's help.
I have an app in the playstore for my website, that offers a monthly recurring subscription, and on my backend I am both granting that month of premium usage and recording the fact that another payment occurred whenever the expiry time runs out on the last receipt and I re-query the Google subscription to check it is still active using https://developers.google.com/android-publisher/api-ref/purchases/subscriptions
There are other forms of payment on my website and apps, so I found this approach was working best. However recently I noticed my system had recorded too many payments compared to what was reported by Google itself.
It turned out that at renew time when I re-query the subscription, Google was returning that it was still active but expired in 1 day, instead of in ~30 days. My system would record that a payment must have occurred and then check again in 1 day (which this time would give the correct expiry time), and then again record that a payment must have occurred when Google again reported it was still active.
For example:
20th February - Initial purchase on app, app tells server the receipt etc. Expires in 30 days.
21st March - The expiry time is up so server re-checks status and Google says "expires March 22nd".
22nd March - The expiry time is up so server re-checks status and Google says "expires April 21st" (this is what it should have said last time)
21st April - The expiry time is up so server re-checks status and Google AGAIN says it only expires in 1 day, on the 22nd of April
etc
I am at a loss as to why Google is reporting the wrong expiry times once a month. I do not have any free days / trial period set up for my IAP subscription. As long as Google reported the correct expiry times then I would have recorded the payments correctly. But if the expiry time is not reliable, how can I tell if a payment has actually occurred?
The subscriptions resource returned by the above API call does not return the orderId of the most recent payment. I can't find a way to link the receipt I have stored server-side with its purchaseToken to any billing information of subsequent renewal payments.
Is there a way to link a receipt/purchaseToken stored server-side to actual payments that are occurring using a Google API? How can I get the most recent orderIds?
But if the expiry time is not reliable, how can I tell if a payment has actually occurred?
I am working on exactly the same problem and have the same observation.
It seems that even if you have no Grace period, it will behave like you have set grace period to 1 day.
Since you don't have grace period, my suggestion is to check the newly queried expiry time against the previous expiry time (you need to store that somewhere).
If it differs by around 1 month, then you can consider that a successful payment. Otherwise, the difference should be around 1 day and it's Google's grace logic at work (probably).
Take note that the time the expiry time varies (i.e: if you first expiry is on 21st March 12:00:00, the second expiry can be after, like 21st April 13:12:32), so you shouldn't use sharp check (i.e diff == exactly 1 month).
Here is an example from Google merchant history. The Date column is approximately equal to the expiry time.
Is there a way to link a receipt/purchaseToken stored server-side to actual payments that are occurring using a Google API? How can I get the most recent orderIds?
You can get the client to send both orderID and purchaseToken as part of the payload, then link them on server.
That seems to be the only place with knowledge of both, for now.
I'm working on an Android application, where a user can buy a monthly/yearly subscription to unlock content. Since the app is not very dependant on the internet I try to do as less comunication with backend servers as possible. However, I have to check if the user holds a valid subscription.
So my plan is to let the user buy the subscription and set the expiry date to today + 1 month/year.
As long as the current date is before this expiry date, I do not need to check the subscription anymore. But once the current date is after this expiry date, I need to check again if the subscription is still there. If so I need to update the expiry date by another month/year.
But how long is a month/year for Google? A month can be between 28 and 31 days long. A year between 365 and 366 days.
As per the documentation:
Monthly — Google Play bills the customer’s Google Wallet account at the time of purchase and monthly subsequent to the purchase date (exact billing intervals can vary slightly over time).
Annually — Google Play bills the customer's Google Wallet account at the time of purchase and again on the same date in subsequent years.
Seasonal — Google Play bills the customer's Google Wallet account at the beginning of each "season" (you specify the season beginning and end dates). This is intended for annual purchases of seasonal content (such as sports-related content). The subscription runs through the end of the season, and restarts the next year at the start of the season.
So for monthly subscriptions, it renews when the date number matches the purchase date (not sure what it does if you start on the 31st though) and for yearly it just renews on the same day the following year.
I am adding a subscription feature to my app. Is there any way I can know the expiry date of the current subscription?
I searched everywhere and cant seem to find the answer
Thanks you
Getting the expiration date for subscriptions is only available through the Google Play Android Develop HTTP-based API. You can always calculate the expiration date using theAIDL for subscriptions. If you request RESTORE_TRANSACTIONS (assuming you have no previous local data) you'll get the purchase date and the current state of the the subscription and a couple of other data.
I've created a monthly subscription (7 days trial included) on Google Play.
I just bought
it and the callback via onPurchaseStateChange worked perfect. But afterwards i cancelled
the subscription purchase.
I still (after 10 hours) get the info that the subscription is purchased not canceled.
Will it be canceled after the trial period?
Or how will this info be transfered?
And how can i test the cancellation behavior?
Thanks for response in advance.
Regards,
Jochen
Yeah, it's kind of confusing. Here is the documentation that explains why it happens:
When the user cancels a subscription, Google Play does not offer a
refund for the current billing cycle. Instead, it allows the user to
have access to the cancelled subscription until the end of the current
billing cycle, at which time it terminates the subscription. For
example, if a user purchases a monthly subscription and cancels it on
the 15th day of the cycle, Google Play will consider the subscription
valid until the end of the 30th day (or other day, depending on the
month).
So, even if you cancel the subscription, it's still valid until the end of the current cycle.
Will it be canceled after the trial period?
No, if it was canceled by user when trial period ends.
Or how will this info be transfered?
When your subscription expires(or canceled) you will not get any information about it in Inventory. So the size of inventory will be zero and thus you can determine that subscription(any or all) was canceled.
And how can i test the cancellation behavior?
Create a test SKU, set the price to 1 USD, and test it. There is no other way, and it's worth it. Rather then spending hours on searching for no results.